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

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Thu, 20 Oct 2005 08:46:19 -0700

Radia,

OK, after I replied and re-read your reply, I realized that you must
have been answering a different question.  That part made sense.

I don't understand why it would be zero if the RBridge broadcast
distribution tree from RB1 used the new link I added to between RB1 and
RB2.  It still needs to get to RB3 and RB4.  In this case, does the
frame get multicast onto the Bridged link and discarded by RB2 due to
some type of RPF check, or is it multicast to a "RB3 and RB4" address,
or does it get unicast twice to RB3 and RB4 respectively?  I'm just
trying to understand how many times the same frame goes across the
Bridged network.  It seems like a minimum of once (just from A) if the
RB's have less cost path reachability than the Bridged network, or up to
3 in the example I just gave.

It seems like a good model for these links may be to model them as a
single access link (iff a RB is the DR for the link) plus a tunnel link
to every other RB on the link.

Since Rbridges don't look at STP BPDUs, the RBs may use these tunnel
links across any size of Bridged network, which would be sub-optimal.
Manual configuration would be needed to raise the link cost so that the
RBridges would prefer links that were actually links, and not Bridged
networks.  If they peaked into the BPDUs, they could probably figure
this out themselves.

 - 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 9:10 PM
To: Developing a hybrid router/bridge.
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
> 
> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at Sun.COM]
> Sent: Wednesday, October 19, 2005 4:24 PM
> To: Larry Kreeger (kreeger)
> Subject: Re: [rbridge] FW: Time to summarize "forward or block" BPDU 
> thread
> 
> 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
>>
>>-----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
>>>
>>>-----Original Message-----
>>>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 mailing list
>>>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
> 
> _______________________________________________
> rbridge mailing list
> 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: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu, 20 Oct 2005 11:06:35 -0700

In the picture, it's clear it would have to go encapsulated over
the bridged link. However, if that was just a subset of the topology,
it might be the case that there is some other path to RB3 and
RB4.

It is possible that the shortest path tree to RB2 would be over the direct
link, and the shortest path to RB3 and RB4 over the bridged link.

In that case, RB1 would send it encapsulated over the bridged link,
and RB3 and RB4 would receive it, but RB2 would not, since that
port of RB2 is not in the "ingress RB1 spanning tree".

Radia