[rbridge] per-VLAN instances of IS-IS

[Eastlake III Donald-LDE008]

Hi Anoop,

>From two places. They should see native IGMP/MLD/PIM/MRD from end
stations that are directly attached to them. And, to the extent that
they let any surrounding Rbridges see any PIM/MRD messages, the
Designated Rbridge will send IGMP/MLDs in native form into the bridged
LAN. I should think this would give the bridges enough information to
figure out how to do an optimized forwarding of IP derived multicast
address traffic.

Donald 

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Wednesday, June 20, 2007 2:53 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] per-VLAN instances of IS-IS

Donald,

So then the bridges in the LAN between the
2 rbridges need some information to do their
pruning.   Where do they get it from?

Anoop 

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Tuesday, June 19, 2007 7:16 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Hi Anoop,
> 
> No, it shouldn't get delivered to every end station unless it is
> broadcast or a layer 2 multicast not derived from an IP address.
> 
> If it is an layer 2 multicast address derived from an IP address, then
> Rbridges should prune the distribution tree and the links they
> decapsulate and forward onto to those with listeners for an 
> IP multicast
> address that corresponds to that layer 2 multicast address or 
> with an IP
> multicast router.
> 
> Donald
> 
> PS: All the above is scoped by VLAN as well.
> 
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> Sent: Tuesday, June 19, 2007 7:32 PM
> To: Eastlake III Donald-LDE008
> Cc: rbridge at postel.org; Caitlin Bestler
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> 
> Donald,
> 
> What if there are no IP multicast routers or
> listeners in the bridged LAN between the
> rBridges?  Does that mean a copy of the trill
> frame gets delivered to every station in that
> LAN?
> 
> Anoop 
> 
> > -----Original Message-----
> > From: Eastlake III Donald-LDE008 
> > [mailto:Donald.Eastlake at motorola.com] 
> > Sent: Tuesday, June 19, 2007 12:51 PM
> > To: Anoop Ghanwani
> > Cc: rbridge at postel.org; Caitlin Bestler
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > In addition to what Caitlin says, I would point out that, 
> if there are
> > multicast listeners or IP multicast routers in this bridged 
> LAN (which
> > looks to the Rbridges pretty much like a single multi-access 
> > link), then
> > the Rbridges should have heard about them and the Designated 
> > Rbridge for
> > the VLAN in question for that cloud will also decapsulate 
> appropriate
> > data/multicast-control and send it into the cloud as native 
> > (non-TRILL)
> > frames whose distribution within the cloud the bridges are 
> welcome to
> > try to optimize as much as they like.
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org 
> > [mailto:rbridge-bounces at postel.org] On
> > Behalf Of Caitlin Bestler
> > Sent: Tuesday, June 19, 2007 3:16 PM
> > To: Anoop Ghanwani; Eric Gray (LO/EUS); Silvano Gai
> > Cc: rbridge at postel.org; Radia Perlman
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > rbridge-bounces at postel.org wrote:
> > > Eric,
> > > 
> > > It depends on what we mean by compatibility.
> > > One can always say that if one cares about such and such
> > > compatibility then here's a way to solve it.
> > > 
> > > Even if trill were to impose the constraint you suggest, many
> > > things will break.  For example, if I have a topology with a
> > > bridged cloud between 2 trill devices, then the traffic going
> > > between the trill devices will not be "snoopable" by the
> > > bridges because they won't understand trill encapsulation.
> > > 
> > 
> > Why are these intermediate bridges snooping?
> > 
> > The only service being requested of them is to relay Ethernet
> > frames from the ingress rbridge to the egress rbridge. Is that
> > not implied by their being a cloud *between* 2 trill devices?
> > 
> > How is this different from any tunnel? You have traffic that
> > a middlebox might have optimized had it been untunelled, but
> > that it does not see when tunneled. It cannot provide its service,
> > but it is not being asked to do so.
> > 
> > A non-rbridge bridge forwards packets without understanding that
> > they are rbridge encapsulated frames. I always thought that this
> > was a strength of the proposal, not a weakness. You can't be
> > snoopable and opaque. Opaque is better.
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
>