[rbridge] per-VLAN instances of IS-IS

[Eastlake III Donald-LDE008]

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
>