[rbridge] per-VLAN instances of IS-IS

[Eric Gray (LO/EUS)]

Anoop,

	Having per-VLAN instances of IS-IS helps to simplify 
interactions - thus increasing the likelihood of correct 
specification leading to interoperable implementations.

	This is accomplished at some cost in extremely complex
deployment scenarios - such as the one you cite as an example
- but the cost is not nearly as high as you make it sound.

	Please see in-line comments below for further details.

Thanks!
--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto: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
> 
> 
> Section 3.3.3.2 of the rBridge base spec 
> talks about the per VLAN instance of IS-IS.
> 
> I can see why that would be useful.
> However, if looks like there could be
> problems scaling.  

I am not convinced that you do.  Having a per-VLAN IS-IS
instance greatly simplifies interactions, and allows us 
to effectively define RBridges in a single VLAN context
- leaving implementers free to implement inter-VLAN as 
already implemented in 802.1Q (and related) implementation.

This is more than just "useful."  See below for further
clarification.

> If an end rBridge 
> participates in 1000 VLANs, it will have
> to maintain 1000 adjacencies. 

This is effectively true if we postulate only a single IS-IS
instance for all VLANs, because you have to scope routing
activities, link-state, etc. - on a per-VLAN basis even if
that is the case.

What you accomplish by using a single instance is to make it
far more difficult to describe, understand and correctly
implement RBridge routing protocol behaviors.
 
> 
> Plus, it looks like for the per-VLAN IS-IS
> instance, the RBridge network operates
> as single LAN segment.  That would mean
> having to go through DR/BDR election for
> each instance. 

And this would be correct behavior.  An RBridge should only
be eligible for ingress and egress to a local VLAN is it is
configured to participate in that local VLAN.  Hence, it may
only participate in DR election for VLANs on a local bridged
LAN if it participates in those VLANs.

This is central to one of the issues with specifying - and
correctly implementing - RBridge functionality.

There are optimizations we may consider at a later date that
will reduce - for example - messaging overhead, and there are
already existing optimizations to reduce the actual state
maintenance overhead to roughly the same as would be the case
with a single IS-IS instance.
 
> 
> Operating 100's of routers on a single 
> LAN segment would poses its own set of 
> scaling issues.  Having per VLAN instances
> exacerbates the problem.

Are there deployment scenarios in today's bridging community
where we support this kind of network as a bidged network?

If there are not, then please recall that sclability of the
current solution is targetted only for routghly the same
size networks as can be established with bridging today.

You make it sound as if we're expected to solve problems 
with RBridges for which solutions have never been specified
for routing.

As for complicating the problem with VLAN instances, think
about how complicated this scenario would be already with 
802.1Q VLANs running any of today's spanning tree protocols.

Also, note that in this same situation with routers in place
of RBridges, each router would most likely be required to 
have a logical interface in each VLAN on every link to which
it is connected.

In other words, this situation is just plain complicated -
irrespective of what you're trying to do to deal with it.

> 
> Have the scaling issues been considered
> at all?  It might actually be better to
> just use the core IS-IS instance.

Scaling has been considered.  Large increases in scalability 
are not a primary goal - relative to existing bridging, for
example.

RTFC!  Increased scalability over existing bridging was 
explicitly NOT included in the charter as a goal.

> 
> 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.
> 
> Anoop
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>