Subject: [rbridge] How many spanning trees?

From: Vishwas at sinett.com (Vishwas Manral)
Date: Mon, 8 Aug 2005 05:40:01 -0700

Hi Radia,

I had a few doubts about mixed environments where we want rbridge coexisting properly with normal bridges/ switches.

The rbridge document aims to add a new shim header after the layer-2 header. The draft states that "A packet in transit must look to ordinary bridges like an ordinary layer 2 packet." However switches (in the silicon itself) these days are more intelligent and do deep packet processing (for example for a basic firewall functionality/ IGMP snooping etc). As the new ether Type would be unidentifiable, this would result in a wrong behavior (example a basic filtering for wrong IP header length check would fail here). However the rbridge protocol defined in such a case will not work properly.

I know of existing switches which do both of the above. Do let me know where I am missing the point?

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
Sent: Tuesday, June 28, 2005 10:14 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How many spanning trees?

You are right that paths will not be the same from A to B as from B to A 
with an A-rooted tree (towards B)
vs a B-rooted tree (towards A), at least if we do a straightforward 
calculation of spanning trees. I think trying
to accomplish symmetric routes might
require source/destination pair route computation. So hopefully we won't 
require symmetric routes.

Radia

Guillermo Ib??ez wrote:

>Guillermo Ib??ez wrote:
>This is my feedback on the "how many spanning trees" issue.
>
>
>Radia Perlman wrote:
>
>  
>
>>It would be nice to get opinions on remaining issues, and I think each
>>issue should be in a different email thread, so I'm starting one.
>>
>>How many spanning
>>trees should RBridges compute? Given the link state database, they can 
>>calculate
>>as many as we want without further protocol messages. The possibilities are:
>>
>>a) one spanning tree: This is simplest, obviously. 
>>
>>    
>>
>The poor performance in the core for multicast is an important argument 
>against it. Other possibilities should exist, at least as an option.
>
>  
>
>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>RBridges 
>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>RA, that
>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>calculated
>>with RA as root. THat spanning tree is pruned so that only branches that 
>>reach
>>other VLAN A links survive.
>>
>>Why bother: If only a few links are VLAN A, then this allows more 
>>optimal delivery
>>of multicast/unknown frames within the VLAN A broadcast domain.
>> 
>>
>>    
>>
>
>It seems that with this implementation  compatibility (interoperability) 
>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>excluded.  If bridges running MSTP exist  in the campus network, they 
>must be confined in one or several MST regions with their specific 
>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>RSTP, the trees will end at the region boundary with an rbridge. This 
>means that there could coexist "regions" running MSTP with their own 
>VLANs and multiple spanning trees inside the region, these regions 
>inserted between rbridges that use another type (range or IDs) of VLANs. 
>My understanding is then that the only VLANs capable of traversing the 
>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>would be stopped by Rbridges if they are not known by them. 
>
>c) one per RBridge
>
>  
>
>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>allows
>>optimal delivery from source to the receivers of a particular multicast.
>>
>>Another reason is that it minimizes out of order delivery of packets in the
>>case when S it talking to D, and initially D is unknown by the RBridges 
>>and packets
>>have to be sent over a spanning tree rather than on the shortest path 
>>    
>>
>>from S to D.
>  
>
>> 
>>
>>    
>>
>One tree per bridge is very efficient together with IGMP snooping, 
>assuming a core of rbridges. The plus point is that in this case the 
>multiple trees can also perform routing of unicast traffic, if used 
>together with the MAC address learning mechanism. In other words: 
>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>may be enough to perform all the routing via minimum paths. This 
>requires that the  address learning mechanism works over the trees (the 
>trees coincide in opposite directions A to B and B to A, a tricky issue 
>when path costs can be equal).  So it seems that there is some 
>overlapping or overkillling using multiple spanning trees for 
>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>are  possible.
>
>  
>
>>********
>>I personally don't have strong opinions on this. If only a miniscule 
>>amount of
>>the traffic is multicast/unknown, then one spanning tree seems good 
>>enough. If
>>there's high volume IP-derived multicast applications, then perhaps one per
>>RBridge would be worth it.
>>
>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>ingress RBridge.
>>
>>And if we did one per ingress RBridge, would it be worth computing all 
>>those trees
>>in advance just in case, or only computing one when necessary?
>>
>>Radia
>>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 08 Aug 2005 09:28:29 -0700

Re: Vishwas's question about encapsulation hiding the true nature of 
packets from possible intervening
bridges (since the subject line would be otherwise misleading).

Are all these things written down someplace? I find it frustrating to 
design around undocumented
proprietary behavior (such as NATs). But anyway...

I'd think firewalling wouldn't be that much of a problem. We wouldn't 
need a basic bridge in the core
to be doing firewall...that could/should be done by an RBridge. Except 
if there were a basic bridge between
the endnodes and the first RBridge, which is a natural place to
put a firewall---then the basic bridge would see packets exactly as 
today and
be able to do the same firewalling with no problem.

As for IGMP...it would be the RBridges doing the IGMP snooping. For a 
basic bridge in the
core, it would indeed not recognize an IGMP packet, but that's the 
behavior we want. It would
just think it was forwarding vanilla multicast...it would be the 
RBridges deciding what IP multicast
packets should be forwarded across which links, and intervening bridges 
should just forward.

Can think of any other bridge idiosyncrasies we should think about?

Thanks,

Radia

Vishwas Manral wrote:

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 08 Aug 2005 18:18:06 -0700

Vishwas Manral wrote:
> Hi Radia,
> 
> I had a few doubts about mixed environments where we want rbridge
coexisting properly with normal bridges/ switches.
> 
> The rbridge document aims to add a new shim header after the layer-2
> header. The draft states that "A packet in transit must look to ordinary
> bridges like an ordinary layer 2 packet." However switches (in the
> silicon itself) these days are more intelligent and do deep packet
> processing (for example for a basic firewall functionality/ IGMP
> snooping etc). As the new ether Type would be unidentifiable, this would
> result in a wrong behavior (example a basic filtering for wrong IP
> header length check would fail here). However the rbridge protocol
> defined in such a case will not work properly.

Bridges should continue to bridge ethertypes that they do not know how
to parse a-priori, otherwise they are not ethernet bridge devices.

The rest of what you're describing are optional optimizations, which
indeed will not occur for rbridge'd packets inside the campus.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050808/fda0377d/signature.bin