[rbridge] per-VLAN instances of IS-IS

[Anoop Ghanwani]

Caitlin,

All of your points are valid.  All I'm trying to
point out is that things as defined break how
bridges currently operate.  They still work, just
not as well as they do without RBridges.

What is likely, what is not likely, what can
be optimized, etc. are all valid points/concerns.
We just have to be clear that regardless of
what we do, we can't pretend that the effect
of using RBridges in a network will not have
an impact on operation of existing bridges.

Anoop 

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Thursday, June 21, 2007 10:32 AM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> rbridge-bounces at postel.org wrote:
> > Hi Anoop,
> > 
> > See below at @@@
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > Sent: Wednesday, June 20, 2007 5:55 PM
> > To: Eastlake III Donald-LDE008
> > Cc: rbridge at postel.org
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > This thread was started because of the assertion that the current 
> > rbridge proposal is "opaque" and is completely compatible with 
> > bridges.
> > 
> > @@@ Of course, that depends on what "completely compatible"
> > means. The protocol specification just says "compatible", not 
> > "completely compatible" :-)
> > 
> > I pointed out that it breaks snooping once the frames are trill 
> > encap'ed and this snooping is required if you have 2 rbridges 
> > interconnected by a regular LAN that doesn't have any end 
> nodes that 
> > are interested in seeing that multicast.
> > 
> > @@@ You may have found a problem, but I really don't think 
> it is the 
> > problem you believe it is, as I will try to explain below. 
> > Furthermore, I can't see why the bridges in the bridged LAN need to 
> > snoop if there are no multicast listeners or IP multicast routers 
> > inside the bridged LAN.
> > 
> > To which Donald responded saying that the DRB for the bridged LAN 
> > would be sending a decap'ed version of the control packets 
> to the LAN 
> > anyway, and so snooping would continue to work.
> > 
> > @@@ Well, I was trying to say something more like the DRB 
> would send 
> > in any traffic that nodes inside the bridged LAN had indicated any 
> > interest in.
> > 
> > I still don't think it works.  Consider the following network.
> > 
> > 
> >   Multicast router
> >    |
> >    Rb1 (DRB for the LAN)
> >    |
> >  bridged LAN with 10 bridges and hosts  in some random configuration
> >    |
> >    Rb2
> >    |
> >    B
> > 
> > In the above example, B is the only
> > participant in a multicast.  No one
> > on the intermediate LAN is interested
> > in receiving the multicast.
> > 
> > When B sends a join, it gets trill encap'ed by Rb2 and forwarded to 
> > Rb1.  The bridges in the LAN can't snoop that because they don't 
> > understand the trill etype.
> > 
> > @@@ Right, stuff with a TRILL Header is opaque to boxes which don't 
> > understand how to parse it. So boxes that are not Rbridges, 
> including 
> > the bridges on this bridged LAN, will be in the dark.
> > 
> > When multicast data are forwarded from Rb1 to Rb2 it is encap'ed as 
> > trill and sent to the all-rbridges address.  The bridges on the LAN 
> > (all 10 of them) will see this frame and copy it to all stations on 
> > that LAN.
> > 
> > @@@ That is correct with the current protocol spec. But I 
> would point 
> > out that at the expense of slightly more complex conditionals, the 
> > protocol could notice that there is only one IS-IS 
> adjacency on that 
> > link out of RB1 and unicast the TRILL data frames even if the 
> > encapsulated frame had a multicast destination. (Of course, 
> it would 
> > want to keep multicasting the TRILL IS-IS frames in case another 
> > Rbridge shows up.) There is nothing peculiar about a unicast TRILL 
> > data frame.
> > If there is unicast data being forwarded from RB1 to RB2, 
> it would be 
> > unicast. But I am digressing.
> > 
> 
> I would actually consider that a local implementation optimization.
> If there is any language that might seem to forbid this it 
> would be nice to rephrase it.
> 
> So the "missed optimization" here is when:
> 
> a) there is a single cloud that connects multiple RBridges.
> b) More than one of these RBridges should receive an encapsulated
>    multicast frame, but the remaining RBridges have no use for it.
> c) Because it will be multicast to "all rbridges" some rbridges
>    will receive the frame, and then determine that they have no
>    local target, and the won't deliver it.
> d) because of encapsulation, a non-RBRidge bridge that did
>    transparent IGMP snooping would not be able to optimize
>    the forwarding of this message through the cloud.
> 
> Aren't *all* of the following scenarios far more common?
> 
> - There is snooping Bridge in the cloud.
> - The traffic is relevant to *all* RBridges attached to the cloud,
>   especially when "all" is really "both".
> - The traffic is relevant only to a single RBridge.
> 
> Further, aren't RBridges capable of providing this 
> optimization themselves rather than relying on the snooping bridges?
>