[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

Donald Eastlake d3e3e3 at gmail.com
Wed Feb 25 18:18:19 PST 2009


Hi Ayan,

It looks like we are essentially in agreement on your first two
points. See below on your third point.

On Wed, Feb 25, 2009 at 1:46 PM, Ayan Banerjee <ayabaner at cisco.com> wrote:
> Donald,
>
> ...
>
> On 2/19/09 7:58 AM, "Donald Eastlake" <d3e3e3 at gmail.com> wrote:
>> Hi Ayan,
>>
>> See below...
>>
>> On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee <ayabaner at cisco.com> wrote:
>>> Radia and Donald,
>>>
>>> ...
>>>
>>> Parallel links between rbridges:
>>> 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.
>>
>> I'm confused by what you say. Assume we have RBridges 1 and 2 such
>> that there is, say, a point to point link between port A on RB1 and
>> port A on RB2 and also between port B on RB1 and port B on RB2. There
>> are two points of view depending on whether you are one of these two
>> RBridges or some other RBridge in the campus:
>>
>> Assume you are some other RBridge, RB3. Do you even see both the A and
>> B adjacencies in the link state? I would think not and that this
>> should be reported as only a single adjacency in the RB1 and RB2 LSPs.
>> If, for some reason, you do see it as two adjacencies, why would you
>> care? As long as you know there is connectivity between RB1 and RB2
>> you can use that in SPF calculations. I suppose you need a way of
>> determining the cost from the two costs you would see but you could
>> just use the minimum of the two or something. And if for some really
>> bizarre reason, even though you are remote from RB1 and RB2 you not
>> only see the two parallel paths in the link state but you actually
>> care which path is taken, there is no space in the LSP TLVs to encode
>> any tie breaking information such as you suggest. So I don't see any
>> need for a tiebreaker here.
>>
>> Assume the other case, that you are either RB1 or RB2. I don't see any
>> difficulty here either. You should accept TRILL traffic on both
>> connections and we should say that as a clarification. (You wouldn't
>> want the Reverse Path Forwarding Check or something causing TRILL
>> frames on one of the parallel connections to be discarded.) And you
>> can send traffic on either connection. Or can do Equal Cost MultiPath
>> on both. But if you send over only one of them then, assuming they are
>> equal cost, it seems like a purely local decision which one and I
>> don't see why we need to specify a tie breaker.
>
> When you have two parallel links and only one of them becomes a member of
> the tree, then RPF as you have pointed out will fail on the other. If the
> parallel links are part of a bundle, we do not need this. However, if the
> user has specifically made them distinct, we need a method to ensure that
> tree is computed along only one of them.

What does it mean when you say "only one of them becomes a member of
the tree"? How does that happen? As I say above, remotely from the
RBridges with these two (or more) between them, I don't think you
should be able to tell that there is more than one connection. And if
you could, you shouldn't care whether one or the other is used or
traffic is split across them. The topology is still the same
regardless of which of these happens. And if you did care, there is no
place in the LSP to add tie breaking info.

And locally (that is, you are one of the two multiply connected
RBridges), it's should just a local choice how to send, and you should
have to be able to receive on any of the parallel links.

Apparently the problem you see is just with the Reverse Path
Forwarding Check at the receiving end of two or more parallel links
between the same pair of RBridges.

I responded above on that point by saying "You should accept TRILL
traffic on both connections and we should say that [in the protocol
specification] as a clarification. (You wouldn't want the Reverse Path
Forwarding Check or something causing TRILL frames on one of the
parallel connections to be discarded.)" Isn't that a satisfactory
answer? (Maybe I shouldn't have said "both" because there could be
more than two...) Why should the local RBridges be forced to tie break
and leave all but one of there parallel point-to-point links idle?

Thanks,
Donald

>>> Thanks,
>>> Ayan
>>>
>>> ...
>>>
>>
>> Thanks,
>> Donald

=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com


More information about the rbridge mailing list