Subject: [rbridge] Time to summarize "forward or block" BPDU thread

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Tue, 18 Oct 2005 17:47:51 -0400

Well if you need help with the drafts I do have a bit of bandwidth
at the moment and would be happy to help out if I can.

Peter

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Gray, Eric
> Sent: Tuesday, October 18, 2005 4:05 PM
> To: 'Developing a hybrid router/bridge.'
> Subject: Re: [rbridge] Time to summarize "forward or block" 
> BPDU thread
> 
> 
> Joe,
> 
> 	I am deeply concerned that there seems to be some 
> differences in opinion between those that are working on the 
> draft(s?) and a lot of the rest of the working group.
> 
> 	More-over, I am not sure that the differences are 
> entirely in terminology.  But I guess we'll just have to wait 
> and see...
> 
> --
> Eric
> 
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org]On
> --> Behalf Of Joe Touch
> --> Sent: Monday, October 17, 2005 10:27 AM
> --> To: Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] Time to summarize "forward or block" 
> --> BPDU thread
> --> 
> --> 
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
> --> 
> 
> Earlier you wrote (and by the way I wish I didn't have to do it 
> this way, but your E-Mail is broken :-):
> 
> 
> 
> Harald Tveit Alvestrand wrote:
> > 
> > 
> > --On 17. oktober 2005 05:17 -0700 Joe Touch <touch at ISI.EDU> wrote:
> > 
> >> WHEN (note the use of 'when', not 'if', since there's 
> *nothing* that 
> >> can be done to enforce this) this isn't the case, the following 
> >> problems
> >> arise:
> >>
> >>     a) there is no way to detect the error
> >>
> >>     b) loops *will* occur
> > 
> > 
> > You know, I really can't tell whether this is true or not without 
> > looking at the protocol specification that says how the RBridges 
> > detect each other.
> > 
> > Should this discussion wait for the drafts to come out?
> 
> As someone trying to write the drafts, I'm trying to 
> understand the terminology that will determine this.
> 
> I have a MUCH better idea of how to explain things now - 
> whether I agree with them at all levels or not, so this 
> discussion IS helping, FWIW.
> 
> Joe
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
> 
>

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Wed, 19 Oct 2005 10:36:24 -0400

>>Now you can have an rbridge and an sbridge in the same L2 (how do you
>>know you don't?). They form an undetectable, uncorrectable loop.
>>
>>
>>[Saikat] I do not see how this happens. First I am assuming that if
>>"sbridges" are connected by physical links, then they know how to avoid
>>packet loops by some mechanism they choose to implement. Now, as far as
>>"sbridges" are concerned, the network consisting of RBridges, STP-running
>>bridges, physical links etc., is simply a "link". In other words, the
> 
> entire
> 
>>network (consisting of RBridges, STP-running bridges, physical links etc.)
>>could be replaced by a physical link. Thus even in this case, there would
> 
> be
> 
>>no packet loop in the steady state.
>>
>>Another way of looking at this argument is the following. Suppose you
> 
> remove
> 
>>all the RBridges from the network. sBridges and legacy bridges are left,
> 
> and
> 
>>the assumption is that in that case, at least, a loop-free network
> 
> results.
> 
>>Then when you add RBridges (in their original position), the rest of the
>>network is simply one or more "link"s, and RBridges would ensure that
> 
> there
> 
>>would be no loops.
> 
> 
> Except that the rbridges add a 'link' between themselves - that's the
> extra 'link' that can cause the loop.
> 
> Joe
> 
> [Saikat] We discussed this possibility before (Radia and I exchanged a
> couple of emails). When RBbridges add a "link" between themselves
(actually
> you need to consider only the scenario when "designated" RBridges add a
> "link" between themselves), there will be a temporary loop. Then the
> designated RBridges will start seeing each others' hello messages, and
they
> will know that there is a loop. In that case, all but one designated
> RBridges (who are connected to themselves by a single "link") will
> "de-designate" themselves. Thus in the steady state there would be no
loop.
> 
> Thinking more about the problem of "Lateral compatibility"---i.e. when
there
> is a third protocol (the one your imaginary "sBridge" implements) that do
> not know about RBridges and vice versa---I am quite convinced that *if*
all
> the protocols jointly converge to a steady state, there will be no loop in
> the system. This basically follows from the fact that in the steady state,
> each given protocol can view the rest of the network as one or more
"links".
> However, in the presence of 3 or more protocols, it is not clear to me
> whether joint convergence to a steady state is guaranteed in all cases (I
> posted a message regarding this before). I tend to believe that in
> "ordinary" cases it should, but there may exist special cases...

If all this is true, why not do this for ordinary bridges?

Joe

[Saikat] I just sent an email yesterday to the list regarding the situation
if ordinary bridges simply choose an arbitrary "designated" bridge per LAN
without regard to its distance from a given bridge (the "root"). Probably
you missed it. You can check it here.

http://www.postel.org/pipermail/rbridge/2005-October/000744.html

Basically, loops are avoided, but the network may end up disconnected! This
does not happen in RBridges because RBridges send *encapsulated* packets
without any restriction, which preserve connectivity. In other words, if you
allow ordinary bridges to encapsulate packets and send them without any
topological restriction, then you could as well use an arbitrary designated
bridge per LAN, but then ordinary bridges would simply become RBridges! In
other words, the critical difference between the ordinary bridge and RBridge
(in my mind, at least) is that ordinary bridges are not allowed to modify
the data packets in any way, but RBridges are.

---

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Wed, 19 Oct 2005 16:17:33 -0700

Radia,

In Step 6, is the frame sent onto the link between RB1 and B1 once or 3
times?  If once, what is the Ethernet DA? 

Thanks, Larry

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Wednesday, October 19, 2005 3:57 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU
thread

Step 1: The bridges create a single broadcast domain, as seen by the
RBridges. So the RBridges see the following picture:

  B    C    D    E
  |    |    |    |
 RB1  RB2  RB3  RB4
  |    |    |    |
 ---------------------
                 |
                 A

Step 2: RB1 is elected DR, so it is the only one that will encapsulate
or decapsulate to/from that link.

Step 3: A transmits a broadcast or multicast packet

Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since they
are not allowed to process native (non-encapsulated) packets

Step 5: RB1 encapsulates it to be sent over spanning tree "ingress RB1"

Step 6: RB1 forwards the encapsulated packet onto the link, with an
outer header with a multicast address "all RBridges"

Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it in
order to send to their upward link (to C, D, and E, respectively).

Step 8: (which could certainly happen after 5 or 6...doesn't have to be
in order). RB1 decapsulates the packet and sends it to B.

************
Hope that helps...

Radia

Larry Kreeger (kreeger) wrote On 10/19/05 15:25,:
> Radia,
> 
> I think I now understand now that the DR election happens only between

> RBridges on a single shared link - and does not require usage of any 
> RBridge topology information.  It would help clarify the data flow for

> me (and hopefully others) if, given the network diagram below, you 
> could please give a step by step description of how a broadcast frame 
> sent by host A gets through each Bridge and RBridge in this network in

> order to be received by hosts B,C,D,E if we assume that RB1 is the 
> Designated RBridge on the "link" created by the Bridged network formed

> by Bridges B1,B2,B3,B4.
>   B    C    D    E
>   |    |    |    |
>  RB1  RB2  RB3  RB4
>   |    |    |    |
>   B1---B2---B3---B4
>                  |
>                  A
> Thanks, Larry
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] 
> On Behalf Of Radia Perlman
> Sent: Wednesday, October 19, 2005 9:57 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> The IS-IS Hello protocol is for electing a single unique switch per 
> link. It doesn't matter which one it is.
> 
> On the other hand, the spanning tree protocol is picking a special 
> single unique bridge per link...the one that is closest to the root.
> 
> The spanning tree algorithm is choosing a tree of shortest paths from 
> the root.
> 
> IS-IS is not trying to do that. It is just electing one guy on a link 
> to do special link-specific things.
> 
> Radia
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

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

---

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Thu, 20 Oct 2005 17:45:39 -0700

Are multicasts also carried over edge rbridge's
per-rbridge-spanning-tree ..? 

If so, assuming all entities (RBx, host A & F) are interested in a
particular multicast group G1, what outer address is used  (for the same
topology discussed in this thread) for multicast originating from host A
..? As I understand multicasts also go on a per-rbridge-spanning-tree.
What outer address would be used by RB1 such that RB3 & RB4 understand
it's a TRILL encpasulated packet, and is a multicast, but at the same
time, such a packet should be thrown away by host F. 

Also, if an IGMP packet seen by any designated rbridge, is sent as a
broadcast to other rbridges, over that rbridge's spanning tree, then I
don't think *traditional* IGMP snooping would work to form the {S,G}
multicast state. (where S == source rbridge). 

-Sanjay

>[mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
>Sent: Wednesday, October 19, 2005 9:10 PM
>Subject: Re: [rbridge] FW: Time to summarize "forward or 
>block" BPDU thread
>
>When I say "it is sent twice", I mean that the first time it 
>is sent by A, natively. RB1 does not send it natively, just 
>encapsulated. So perhaps I misparsed your question. I was 
>answering "how many times does the packet get sent on that 
>link" and from this question I guess you were asking "how many 
>times does RB1 transmit the packet on the link."
>
>The answer to THAT question is "once", and it will be encapsulated.
>
>Though with you extra link that you added now, it might be 
>zero, depending on whether the spanning tree the RBridges 
>calculated from the link state database, for ingress RBridge 
>RB1, includes that link or not.
>
>So, for your first question:
>
>> Why does RB1 send it onto the Bridged link with a "native" 
>DA Broadcast?
>> If, as you said, F will receive the frame directly from A, then 
>> wouldn't this cause F to get two copies?
>>
>
>No. RB1 does not send the packet natively. If it did, then F 
>will receive two copies. But it doesn't. This misunderstanding 
>is that I was answering a different question than you were 
>asking, apparently.
>
>
>For your second question:
>
>> Now, the broadcast distribution tree may be (and would probably be
>> better) calculated to use the direct link between RB1--RB2 
>instead of 
>> through the Bridged network.  Unfortunately, RB1 probably 
>cannot tell 
>> the difference between a direct connection and a Bridged network 
>> connection, but let's say it chooses this link.  Now, 
>wouldn't RB2 get 
>> two copies of the broadcast...or is there more to this - 
>such as some 
>> kind of RPF check that is needed.
>
>The RBridges use the link state database to calculate a tree 
>of shortest paths from RB1. So packets only arrive once.
>
>Radia
>
>
>
>
>Larry Kreeger (kreeger) wrote On 10/19/05 17:53,:
>> Radia,
>> 
>> Why does RB1 send it onto the Bridged link with a "native" 
>DA Broadcast?
>> If, as you said, F will receive the frame directly from A, then 
>> wouldn't this cause F to get two copies?
>> 
>> Also, I'm not sure if using an "all RBridges" DA would work if the 
>> RBridges had other connectivity.  For example, if I add a 
>link in the 
>> topology between RB1 and RB2,
>> 
>>  
>>   B    C    D    E
>>   |    |    |    |
>>  RB1--RB2  RB3  RB4
>>   |    |    |    |
>>  ---------------------
>>       |           |
>>       F           A
>> 
>> Now, the broadcast distribution tree may be (and would probably be
>> better) calculated to use the direct link between RB1--RB2 
>instead of 
>> through the Bridged network.  Unfortunately, RB1 probably 
>cannot tell 
>> the difference between a direct connection and a Bridged network 
>> connection, but let's say it chooses this link.  Now, 
>wouldn't RB2 get 
>> two copies of the broadcast...or is there more to this - 
>such as some 
>> kind of RPF check that is needed.
>> 
>>  - Larry
>> 
>> From: Radia Perlman [mailto:Radia.Perlman at Sun.COM]
>> Sent: Wednesday, October 19, 2005 4:24 PM
>> To: Larry Kreeger (kreeger)
>> It is sent twice.
>> The first time it is "native", with DA=broadcast
>> 
>> The second time is encapsulated by RB1, so the packet has 
>outer header 
>> DA="all RBridges", a shim header with "ingress=RB1", and the inner 
>> packet being exactly as transmitted by A.
>> 
>> Onto other links though...RB1 will transmit it to B unencapsulated, 
>> i.e., exactly as A transmitted it. Likewise, RB2 to C, RB3 to D, and 
>> RB4 to E.
>> 
>> And just a note...in case there were other endnodes on the bridged 
>> link, the RBridges don't worry about it...those endnodes receive the 
>> packet directly from A.
>> 
>> So, for instance, F below will receive the packet when A 
>transmitted it.
>> 
>>   B    C    D    E
>>   |    |    |    |
>>  RB1  RB2  RB3  RB4
>>   |    |    |    |
>>  ---------------------
>>       |           |
>>       F           A
>> 
>> 
>> 
>> Radia
>> 
>> 
>> 
>> 
>> 
>> Larry Kreeger (kreeger) wrote On 10/19/05 16:17,:
>> 
>>>Radia,
>>>
>>>In Step 6, is the frame sent onto the link between RB1 and B1 once or
>>>3 times?  If once, what is the Ethernet DA?
>>>
>>>Thanks, Larry
>>>
>>>Step 4: RB1 receives it (RB2, RB3, and RB4 all throw it away since 
>>>they are not allowed to process native (non-encapsulated) packets
>>>
>>>Step 5: RB1 encapsulates it to be sent over spanning tree "ingress
>> 
>> RB1"
>> 
>>>Step 7: RB2, RB3, and RB4 all receive the packet, and decapsulate it 
>>>in order to send to their upward link (to C, D, and E, respectively).
>>>
>>>Step 8: (which could certainly happen after 5 or 6...doesn't have to 
>>>be in order). RB1 decapsulates the packet and sends it to B.
>>>
>>>************
>>>Hope that helps...
>>>
>>>Radia
>>>
>>>
>>>
>>>

---

From: michsmit at cisco.com (Michael Smith (michsmit))
Date: Fri, 21 Oct 2005 08:34:02 -0700

> And I can't resist pointing out interesting technical 
> tidbits...with the bridge spanning tree, the packets go on 
> all the links, even if no other bridges will be picking up 
> the packet. Whereas with RBridges, if the link-state-computed 
> tree indicates no downstream receivers, then the packet is 
> not sent onto that port.

Interesting, are you referring only to the encapsulated packets ?  I
would think that every link in the link-state-computed spanning tree
would still need to see the unencapsulated packet.  We may know that
there are no rbridge receivers but we don't necessarily know about
non-rbridge receivers.  For any links that have peer rbridges downstream
from the view of the spanning tree, there would end up being 2 packets
transmitted.

Michael