Subject: [rbridge] Doubts about Rbridge

From: Vishwas at sinett.com (Vishwas Manral)
Date: Mon, 29 Aug 2005 02:23:36 -0700

Hi Erik,

One part you may have missed out is the action taken as a result of
seeing the other header. 

As the Outer Ethernet Header is changed, Protocol VLAN too may have
problems which are based on EtherType. Similarly as Source MAC Address
is changed Mac-Based VLAN will not work.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Erik Nordmark
Sent: Saturday, August 27, 2005 4:39 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Doubts about Rbridge

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 29 Aug 2005 07:57:38 -0700

Just like with regular bridges, the first bridge or RBridge will insert 
the VLAN header into the
inner header. So if it's MAC-based, the first bridge or RBridge will do 
that. Then the
outer header is only to carry it between the RBridges. At that point, 
RBridges only look
at VLAN in order to decide whether they can optimize by not forwarding 
it down
a branch of the ingress-RBridge-spanning tree.

The inner header is still available for inspection by RBridges. Bridges 
in the core won't
see the VLAN tag, but they don't need to...they are only forwarding in 
the tiny universe
of the link between two adjacent RBridges.

And finally, the last RBridge removes the outer header and shim, and the 
VLAN tag, before
forwarding onto the last link.

Radia

Vishwas Manral wrote:

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