Subject: [rbridge] per-VLAN instances of IS-IS

From: Radia.Perlman at sun.com ([email-masked])
Date: Sat, 09 Jun 2007 21:02:11 -0700

Expanding on what Silvano said, and agreeing with what I think Anoop was pointing out.

It was an error in the previous version of the spec to say that the IP multicast group membership
information would be announced in the per-VLAN instance, since the core guys would need
to look at membership in VLAN A, even if they are not in VLAN A, in order to prune multicasts
in VLAN A inside the core. So IP group membership is moving to the core instance.

And for now the per-VLAN instance (which would have announced endnode membership) is
going away, though I'd like it to be optional in the future, for letting an RBridge announce
endnodes that have actually enrolled at layer 2, since it's a more secure binding than
just having an endnode transmit a data packet with the source address. But it will be a MUST
to learn from data packets, and, if we define a per-VLAN instance of IS-IS for announcing endnode
memberships, it would be a SHOULD to announce endnodes that have actually enrolled, with
perhaps a metric for how securely they've enrolled (whether it was cryptographic authentication, e.g.).
And it would be a SHOULD to learn from such reports, and a SHOULD to have the IS-IS announcement
be believed when there is a conflict between what is learned from decapsulating a data packet vs
what is announced in IS-IS.

Radia
----- Original Message -----
From: Silvano Gai <sgai at nuovasystems.com>
Date: Saturday, June 9, 2007 10:01 am
Subject: Re: [rbridge] per-VLAN instances of IS-IS

> Anoop,
> 
> The proposal for multicast is to move this information in the core
> inbstance of ISIS.
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org]
> On
> > Behalf Of Anoop Ghanwani
> > Sent: Friday, June 08, 2007 6:25 PM
> > To: Eastlake III Donald-LDE008
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] per-VLAN instances of IS-IS
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > >
> > > See below at @@@
> > >
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org
> > > [rbridge-bounces at postel.org] On
> > > Behalf Of Anoop Ghanwani
> > > Sent: Friday, June 08, 2007 12:59 PM
> > > To: rbridge at postel.org
> > > Subject: [rbridge] per-VLAN instances of IS-IS
> > ..
> > >
> > > Have the scaling issues been considered
> > > at all?  It might actually be better to
> > > just use the core IS-IS instance.
> > >
> > > @@@ These issues have been raised, although the possibility
> > > of using the
> > > core IS-IS instances hasn't been discussed much.  If you do have
> 1,000
> > > VLANs, using the core instance means that every Rbridge in the
> campus
> > > would have to know all end stations, even if that Rbridge is
> > > in an area
> > > of the campus that only uses one or a few VLANs.
> > >
> > > @@@ The WG appears to favor a change so that all Rbridges MUST be
> able
> > > to learn entirely from data, the way IEEE 802.1 bridges do, 
> based on
> > > frames that they encapsulate and decapsulate. There are, however,
> > > advantages to using the per VLAN IS-IS instances, such as improved
> > > security in learning remote end node addresses if those end states
> > > register with their local Rbridge using some layer 2 protocol such
> as
> > > 802.1X and IS-IS security is in use for the IS-IS messages.
> > > So it seems
> > > appropriate at this time to say in the draft that Rbridges
> > > MAY implement
> > > and use the per VLAN IS-IS technique. Of course, it should also be
> > > possible to use a management protocol to configure end station
> > > addresses, configure so as to turn off learning from data, etc.
> > >
> > > @@@ I expect the next version of the protocol specification to
> reflect
> > > this change so that learning only from data is the zero
> configuration
> > > method.
> > 
> > 
> > The learning approach will work for unicast addresses.
> > It will not work for pruning the trees for multicast
> > addresses and flooding to VLANs.  Those addresses
> > and VLAN membership information needs to be sent
> > around to all RBridges in the network.
> > 
> > >
> > > The following statement in Section 3.3.3.2
> > > of the draft appears to be incorrect/incomplete:
> > >
> > > "RBridges with endnodes in VLAN A also
> > > receive and process the frame in their
> > > VLAN-A IS-IS instance."
> > >
> > > The frame also has to be processed by all
> > > RBridges that might be along the path for
> > > reaching the VLANs, otherwise we wouldn't
> > > be able to prune the distribution trees
> > > correctly.
> > >
> > > @@@ Right. It actually says "... all RBridges forward it as
> > > an ordinary
> > > frame in VLAN A ..." in the previous paragraph.
> > 
> > This doesn't work.  See my response to Eric
> > for why it doesn't.
> > 
> > Thanks,
> > Anoop
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>