[rbridge] per-VLAN instances of IS-IS

[Anoop Ghanwani]

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Thursday, June 14, 2007 9:54 PM
> To: Anoop Ghanwani
> Cc: Eric Gray (LO/EUS); rbridge at postel.org
> Subject: Re: [rbridge] per-VLAN instances of IS-IS
> 
> I'm catching up after travelling, so if someone else answered this, 
> sorry about that.
> 
> Anoop Ghanwani wrote:
> >
> > What I'm getting at is that all RBridges in the 
> > network need to know about all VLANs so that they
> > can prune their trees for each VLAN correctly.
> 
> Yes--all the intermediate RBridges need to know which edge 
> RBridges (where
> an "edge RBridge is one that is acting as a Designated 
> RBridge on a link)
> are attached to which VLANs.
> 
> But an RBridge that is not an edge RBridge does *not* need to 
> know about
> any endnodes. And an RBridge that is not the DR for a link in 
> VLAN A does
> *not* need to know about endnodes in VLAN A.

That is correct.  However, even in that scenario, I
don't think it makes sense to have a per-VLAN 
IS-IS instance - maintaining the adjacencies
for a given instance won't scale to large
numbers of VLANs.  I would probably be better
to just use the single instance and encode
the information in such a way that the receiver
can quickly determine what it needs to care
about.  

However, as you point out below, I think
it makes more sense to solve this problem using
learning at the edge RBridges.  But that doesn't
solve the problem for multicasts so those will
have to be advertised anyway, and they will
have to be sent to all Rbridges in the
network.

> So...mostly I'm confused (and I think others are) about what 
> is meant by
> "a per-VLAN instance of IS-IS". When I was using the phrase I meant
> the piece of IS-IS that announced VLAN A endnodes, and that 
> information
> only would have to go to RBridges that are Designated RBridge 
> for a link 
> in VLAN A.
> 
> But, as Donald said, we are switching to having the default 
> case being 
> that the
> mapping between (ingress RBridge, source endnode) is learned 
> by the egress
> RBridge that decapsulates a data packet onto its link. That way only 
> Designated
> RBridges learn endnode locations, and only learn endnode 
> locations that are
> talking to endnodes on that RBridge's link.
> 
> We are also allowing optional advertisement of attached 
> endnodes in VLAN A,
> and optional learning from these, in a "per-VLAN IS-IS 
> instance", which does
> nothing but advertise the location of endnodes, and is 
> broadcast only to
> Designated RBridges attached to that VLAN. The intention is 
> that endnodes
> announced in this way would be endnodes that are definitively learned 
> through
> some sort of layer 2 enrollment protocol.

If you absolutely had to have multiple IS-IS
instances, it might make sense to have some
number 'n' and then define a mapping of VLANs
to each instance.  Having 4K instances of IS-IS
running in an RBridge won't scale.

Anoop