[rbridge] multiple nicknames in an LSP?

[Ayan Banerjee]

Radia,

Please see inline. 

Thanks,
Ayan


On 3/25/09 10:12 AM, "Radia Perlman" <Radia.Perlman at sun.com> wrote:

> Someone asked me about whether it would be possible for an RBridge to
> request more
> than one nickname for itself. We could, I suppose, put in the encoding
> into the Hello, perhaps
> by changing the format of the TLV for "nickname", or just inherently
> from the length of the TLV,
> allowing a list of nicknames.
> 
> So...the question is -- why might we want multiple nicknames?
> 
> Some reasons people have mentioned to me I'm not sure I understand, so
> people can add them.
> Other layer 2-ish protocols play tricks with having multiple destination
> addresses, I think for
> allowing multiple routes to the same destination. I'm not sure those
> apply to TRILL
> 
> One reason I do understand, but am not sure I understand how to
> accomplish it, is to allow
> multiple trees rooted at the same node R1, with the hope that the two
> trees can look different (for load
> sharing) and yet both be shortest paths from R1. If we had two nicknames
> for R1 then R1 can
> request some multicast packets travel on each of the trees.
> 
> It's harder than just having the nicknames, because the way the spec
> reads today, exactly the same
> tree would be computed.
> 
> I'd have to go thinking about this some more, and I think it would be an
> excellent research problem for
> a student -- how to calculate, without configuration, maximally load
> sharing'ness of trees rooted at the same
> place, or choosing which nodes to root trees on, etc.
> 
> But here's a quick suggestion, just to show it's somewhat possible:
> 
> Use the root nickname (or root ID, or some other field we can add to the
> LSP as a modifier
> of the nickname) as a way of doing the tie-breaker.
> 
> so for instance, R1 can say "I want nicknames N1 and N2. I'd like the
> tiebreaker salt to be x for N1
> and y for N2".
> 
> Then when the tree rooted at N1 is being computed (by any RBridge),
> rather than choosing the
> ID of the parent as the tie-breaker (as it is today I think), use some
> sort of function of
> the salt, so that the tie-breaker would be different for the N1 tree
> than the N2 tree.
> 

[AB] It seems to me that given we have roots tied to graph-ids, we could
associate N1 to a graph-id and that makes it "visible" only on that
graph-id. Hence, other nodes computing their SPFs will see N1 only in
graph-1 and N2 only in graph-2. I am guessing that you are essentially
saying the same above, though I do not quite follow the tie-breaker. If it
is explicit, node R1 can enforce multicast packets on trees that it desires.


> Radia
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge