[rbridge] dist tree parallel links - proposed solution

[jeff pickering]

Ayan,

Thanks much for all the help, but I still think there is a problem. I'll 
try to rearticulate:

Scenario: RB-B is computing dist tree spf and has neighbor RB-A towards 
root.
RB-A has multiple ptpt links to RB-B (ptpt critical to issue) and those 
links are UNEQUAL COST.
RB-B must choose RB-A's lowest cost link (RB-Bs links costs are irrelevant.)
RB-A announces in its LSP only the links to RB-B and their costs. 
(unlike a bcast subnet
where pnode ID would also be included).  It does not include any info 
that might enable
RB-B to identify which link the announced cost is associated with. 
Likewise, the 3way hello
contains nothing that allows mapping remote cost to adjacency. 
Tiebreaking rules based on
circuit ID dont apply because there is no tie.

(note that the wide metric tlv contains only system ID in its 7 octet 
link info).

RB-B could make a choice based on its own link costs, but that would be 
a problem for RPF.
So its seems additional information is needed. I see two options:

1) add some ciruict ID info to the subtlv of the wide metric ISN link.
2) add cost info to the new link capability tlv.
3) enforce some relationship between circuit ID and cost such that 
higher cost
    means less preferred circuit ID. Could then use circuit ID for a 
decision.

3) seems kink of hokey to me.
and since the issue is purely local to RB-A and RB-B, I would prefer 
option 2.

Of course if Im out to lunch, I'd love to hear why.

Regards,
Jeff

Ayan Banerjee wrote:
> Jeff,
>
> At nodes RB-A and RB-B, where this information is necessary during the SPF
> run, LSP link information, adjacency information, metric information etc all
> values are present.
>
> Agree that other nodes do not have the complete information, however, they
> only care about the cost of the link between RB-A and RB-B. The link (among
> the parallel links) to be used  between RB-A and RB-B is needed locally and
> complete information is present at those two nodes.
>
> Thanks,
> Ayan
>
> On 6/22/09 1:09 PM, "jeff pickering" <jpickering at nc.rr.com> wrote:
>
>   
>> Ayan,
>>
>> How? There is no cost info in the 3way hello/handshake and no 3way cid
>> related info
>> in the LSP ISN link (wide narrow or otherwise).
>>
>> Thanks,
>> Jeff
>>
>>
>>
>> Ayan Banerjee wrote:
>>     
>>> Jeff, 
>>>
>>> Agreed. However, from the adjacency state machine (since 3-way is mandatory
>>> in TRILL) one can figure this information.
>>>
>>> Thanks,
>>> Ayan
>>>
>>>
>>> On 6/22/09 12:34 PM, "jeff pickering" <jpickering at nc.rr.com> wrote:
>>>
>>>   
>>>       
>>>> For the local matter of RB-B making its adjacency set, it has 2
>>>> adjcacencies to RB-A and it
>>>> must choose one. The one it must choose is that represented by the
>>>> lowest cost of link of
>>>> the upstream node (RB-A). But for a ptpt link, there is nothing in the
>>>> LSP that would allow
>>>> RB-B to determine which one of its adjacencies corresponded/mapped to
>>>> that link.
>>>>
>>>> Thanks,
>>>> Jeff
>>>>
>>>>
>>>>
>>>> Ayan Banerjee wrote:
>>>>     
>>>>         
>>>>> Jeff,
>>>>>
>>>>> On re-reading your email, I see that you have unequal costs. The costs from
>>>>> the upstream node will be honored for the bi-directional tree.
>>>>>
>>>>> On a separate note, for equal cost multi-path, the link that needs to be
>>>>> used between nodes RB-A and RB-B are a local matter. Other nodes will just
>>>>> "view" the tree as being connected between RB-A and RB-B. I was trying to
>>>>> state how the "local" algorithm is made deterministic.
>>>>>
>>>>> Thanks,
>>>>> Ayan
>>>>>
>>>>>
>>>>> On 6/22/09 11:49 AM, "jeff pickering" <jpickering at nc.rr.com> wrote:
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> Im sorry if Im being obtuse. This is a non-equal cost issue. RB-A will
>>>>>> advertise in its
>>>>>> LSP ISN entry a link to RB-B and its associated cost, but no (ext/cid
>>>>>> for ptpt) info
>>>>>> which allows RB-B on the other end to determine which one of its
>>>>>> adjacencies (and therefore
>>>>>> ports) the advertised link corresponds to. I understand for bcast, you
>>>>>> can determine this
>>>>>> from the pnode id part on the ISN link, but dont see what info you have
>>>>>> have for ptpt.
>>>>>> (unless I misread the wide metrics spec 5305).
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>> Ayan Banerjee wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Jeff,
>>>>>>>
>>>>>>> In TRILL 3-way handshake is mandatory for P2P links. Hence, each node
>>>>>>> will
>>>>>>> get an unique extended circuit identifier after adjacency formation. On
>>>>>>> LAN
>>>>>>> links, the source mac can be used an identifier for uniqueness of each
>>>>>>> link.
>>>>>>>
>>>>>>> I believe that P2P links are preferred over LAN links. Among the set, in
>>>>>>> the
>>>>>>> event there are multiple "identifiers" then the highest (or lowest - I
>>>>>>> remember that there was some discussion on the list about highest/lowest,
>>>>>>> do
>>>>>>> not recall what we ended up with) one will be chosen for the tree.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ayan
>>>>>>>
>>>>>>> On 6/22/09 8:55 AM, "jeff pickering" <jpickering at nc.rr.com> wrote:
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> I have a distribution tree parallel links question I was hoping someone
>>>>>>>> could clarify
>>>>>>>> for me.
>>>>>>>>
>>>>>>>> Let's say you have 2 RBs downstream from the root, with parallel links
>>>>>>>> between them.
>>>>>>>>
>>>>>>>> RB-A has cost 10 on link 1, cost 20 on link 2.
>>>>>>>> RB-B has cost 20 on link 1, cost 10 on link 2.
>>>>>>>>
>>>>>>>> Lets say RB-B is downstream from RB-A. When computing its paths, RB-A
>>>>>>>> will clearly
>>>>>>>> use link 1. Whether it shows 1 or 2 links in its LSPs is irrelevant,
>>>>>>>> RB-B still needs to know
>>>>>>>> somehow to choose its adjacency over link 1 for its path to the root.
>>>>>>>> But in the asymetric cost
>>>>>>>> case, I dont see how its can do this. Is there something new in either
>>>>>>>> the LSP or hello that
>>>>>>>> would resolve this?
>>>>>>>>
>>>>>>>> Or should RB-B use its lower cost and if so how does the RPF issue get
>>>>>>>> addressed?
>>>>>>>>
>>>>>>>> Thanks to anyone who can enlighten me.
>>>>>>>>
>>>>>>>> Jeff
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> rbridge mailing list
>>>>>>>> rbridge at postel.org
>>>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>>>     
>>>>>>>>         
>>>>>>>>            
>>>>>>>>                 
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>   
>>>>>       
>>>>>           
>>>
>>>   
>>>       
>
>
>
>