Subject: [rbridge] parallel links

From: Radia Perlman <[email-masked]>
Date: Mon, 02 Mar 2009 22:46:20 -0800

A discussion of how to compute trees when there are parallel links 
between R1 and R2 appeared, but
could have been missed by people because it was included in a thread 
with a somewhat generic
subject line (WG last call on draft-trill-rbridge-protocol-10.txt), and 
the thread was discussing
several issues.

The issue is that if R1 and R2 have, say, k parallel links between them, 
and they are all reported in
the link state protocol, then it would be bad for R1 and R2 to disagree 
about which link should be
in the tree. The result would not be a loop (I'm pretty sure), but 
instead, packets would be dropped
because if R1 is sending on a link and R2 doesn't think that link is in 
the tree, R2 will drop the packet.

Now, as Don pointed out -- this issue does not affect some other 
RBridge, say R3. It only affects
the RBridges attached to the link.

Ayan suggested that we put in a tie breaker so that R1 and R2 agree on 
which link should be used.

That seems harmless. First of course, the link with lowest cost should 
be used (it wouldn't be a tie
otherwise, so this doesn't need to be clarified). Then, we can use what 
Ayan suggested, namely:

 >>We need information in the draft that states that we break ties using 
(a)
 >>extended circuit id on P2P links (makes 3-way handshake mandatory) 
and (b)
 >>in a LAN, use lan circuit id.

Don might be correct that as long as R2 is "liberal in what it 
receives", and is willing to accept
multicast traffic from R1 on either of those links, that there wouldn't 
be a problem, but it seems
safer to do a tiebreaker.

Now for load-splitting fans, who might want to see both of those links 
used: I think that should
be a feature between R1 and R2, perhaps even something we put into the 
spec (or some add-on spec).
R1 and R2, noticing that there are multiple parallel links between them, 
can treat them like one
"fat pipe", only reporting a single link, and making sure that packets 
going over the multiple links
don't cause packets from the same flow to get out of order. This can be 
done by hashing and making
sure that the same flow goes over the same link, or it could be done by 
using a protocol between R1
and R2 where the packets are numbered and put back in order (that way 
even packets from
the same flow can use multiple links).

I suspect some IS-IS implementations already have this feature. I 
vaguely remember it being discussed
years ago, for instance, even when I was at Digital a hundred years ago 
or so. So I'm not sure we
need to put it into the TRILL spec now. But we could...

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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 05 Mar 2009 21:51:29 -0800

So, is it obvious what can be used for a tie-breaker?  Ayan's suggestion 
of "circuit ID on a LAN" is
probably the pseudonode ID. But in the case where R1 (the DRB) decides 
to suppress the psueonode,
this might not work.

Can we have a flag in the Hello that says "don't bother with a 
pseuodonode" (instead of noting
no pseudonode by using 0 for the pseudonode ID)? Then the DRB will 
always put in a unique
pseudonode ID, but just set a flag saying "just report this as a 
pt-to-pt links". And the link
will have a unique pseuonode ID for R1 and R2 to use as a tie-breaker.
This pseuodnode ID will not be visible outside the link -- just visible 
to R1 and R2.

Radia