Subject: [rbridge] Doubts about Rbridge

From: Vishwas at sinett.com (Vishwas Manral)
Date: Tue, 9 Aug 2005 23:14:14 -0700

Hi Joe,

I miss the point regarding the "Type" field not required. "EtherType" field in the Ethernet header is used to tell the type of packet above Ethernet.

When traversing an rbridge we loose the information of the packet above, because we replace the etherType by the rbridge type. How will we know what is the etherType when a packet inner header (after the shim header) needs to be looked into (L3 switching needs to be done). 

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
Sent: Tuesday, August 09, 2005 9:54 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Doubts about Rbridge

Vishwas Manral wrote:
> Hi Radia,
> 
> Would "Protocol VLAN's" work with rbridges? With the etherType
> pointing to the Rbridge and not the protocol above I think it would not.\

The different VLANs would need to be identified at the rbridge ingress,
and mapped to different rbridge egress IDs, which would then map to
different forwarding tables accordingly.

Inside the rbridge, the rbridge forwarding takes over. Keep in mind that
looking inside an rbridge is (and should be) like looking inside a
bridge. Bridges inside the campus would no longer see the protocol vlan
tags or any other vlan tags per se - they'd just see the rbridge tags,
which is all they should see.

Note that protocol vlans or other vlans can work inside the campus
between other bridges, but aren't really participating in the rbridge
internal forwarding structure.

> Besides is there a reason to not have a "type" field in the shim header?

The only reason to have it is because it's needed; the only reason to
need it would be if rbridges would forward differently on their basis,
or expect bridges inside the campus to to so. However, as per above, the
rbridge replaces the vlan/protocol ID structure with its own set of
addresses which are sufficient for its forwarding.

Joe

> 
> Thanks,
> Vishwas
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral
> Sent: Tuesday, August 09, 2005 10:49 AM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Doubts about Rbridge
> 
> 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: Wed, 10 Aug 2005 06:19:17 -0700

Vishwas,

Inside the rbridge, for traffic entering the rbridge via ingress/egress,
the only switching decisions being made are between rbridge ingress and
egress.

As a result, the only 'ethertype' that is relevant is the rbridge shim.

Inside the rbridge, there is no need for L2-style 'peeking' into L3
headers to do optimizations; that would be done at the ingress to direct
traffic to different egresses or multicast trees.

Joe

Vishwas Manral wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Vishwas Manral wrote:
> 
>>Hi Radia,
>>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

-------------- 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/20050810/f0175730/signature-0001.bin