Subject: [rbridge] multiple nicknames in an LSP?

From: Radia Perlman <[email-masked]>
Date: Wed, 25 Mar 2009 10:12:20 -0700

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.

Radia

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Ayan Banerjee <[email-masked]>
Date: Wed, 25 Mar 2009 20:36:00 -0700

Radia,

Please see inline. 

Thanks,
Ayan

> the salt, so that the tie-breaker would be different for the N1 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.

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Mar 2009 11:30:28 -0700

The point someone was making is that they want multiple trees rooted at 
the same place (say R1)
where all the trees are shortest path trees from R1, but that they use 
different links. The only way to
do that is to have different tie breakers where there are choices. The 
way the spec is currently,
the tie-breaker would be the same, so all the trees rooted at R1 would 
be identical.

But anyway, for now, should we allow the encoding of the nickname TLV to 
allow asking for multiple
nicknames?

Seems not too hard..given that there is an "L" in the TLV.

Is there anyone who would object to this? Is there anyone who would 
actually want this?

Radia