Subject: [rbridge] Doubts about Rbridge

From: Vishwas at sinett.com (Vishwas Manral)
Date: Mon, 8 Aug 2005 22:19:15 -0700

Hi Radia,

(PS: I am changing the subject line) 
The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.

A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.

Maybe I am missing the point altogether.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
Sent: Monday, August 08, 2005 9:58 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] How many spanning trees?

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:

>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: touch at ISI.EDU (Joe Touch)
Date: Tue, 09 Aug 2005 09:30:16 -0700

> The existing bridges (switches) already do IGMP snooping, to limit multicast traffic. That scenario would break.

The inside of the rbridge would limit multicast in other ways, e.g.,
using different trees for each mcast group and limiting tree
participation at the ingress/egress nodes. Inside the rbridge, however,
there would be no IGMP header to examine anymore, because it's not
necessary.

> A lot of existing layer-2 devices do firewall functionality. Firewall functionality in the silicon may not work with Rbridges coming in.

Definitely. Anyone putting a firewall inside an rbridge campus would
have problems - but that seems correct.

> Maybe I am missing the point altogether.

Two concepts may help:

	1) IMO, an rbridge campus should act like a single bridge device
	to the outside world

	2) an rbridge campus should be more efficient than replacing it
	with a set of conventional bridges

Most of your questions are answered, IMO, by considering #1 rather than #2.

Joe

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

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri, 26 Aug 2005 16:09:01 -0700

Vishwas Manral wrote:
> Hi Radia,
> 
> (PS: I am changing the subject line) The existing bridges (switches)
> already do IGMP snooping, to limit multicast traffic. That scenario
> would break.
> 
> A lot of existing layer-2 devices do firewall functionality. Firewall
> functionality in the silicon may not work with Rbridges coming in.

Sorry for the late response.

It seems like there are two places that are interesting to look at for 
both of these issues:
1. Between the hosts/routers and the first rbridge
2. The path between rbridges

At #1, the packets remain unmodified, this any bridge functionality that 
peeks into higher-layer headers would work just as it does today.
So I don't see how anything could break there.

At #2, the packets are encapsulated in an rbridge header. Thus any 
bridges between the rbridges that look for higher level headers will not 
find them unless they are taught to skip the rbridge headers. (The same 
issues presumably apply for other encapsulations, be it mac-in-mac, 
q-in-q, or something else.)

At #2 IGMP/MLD snooping might not be critical; assuming that the 
rbridges do IGMP/MLD snooping the result would be to limit the flooding 
of multicast packets.

    Erik