[rbridge] per-VLAN instances of IS-IS

[Eric Gray (LO/EUS)]

Anoop,

	Two things:

1) From Radia's response, I think this is (again) a case of my
   getting confused by the strange use of "per-VLAN" in this 
   context.  On that score, I agree that there is little point
   in continuing that part of this discussion.  Part of the 
   reason for my confusion on this score is that I was under 
   the impression that the specific scalability concern you
   raised doesn't exist any more.

2) On the issue of scalability - in general - the responses I've
   seen are not sufficient to justify your observation for the
   general issue of scalability.  What I've seen is agreement on
   the specific issues associated with "per-VLAN" announcements
   - which, as Radia indicates, is going away.

	I believe we all need to get on that page (the one where
that particular misnomer doesn't exist).  Otherwise, we're going
to continue to create confusion over the use of IS-IS instances
(in general) and the impact that this has on scalability.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com] 
> Sent: Monday, June 11, 2007 12:58 PM
> To: Eric Gray (LO/EUS)
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> 
> 
> Eric,
> 
> I don't think it's worth continuing this discussion
> since it looks like there is agreement from several
> others that understand the scaling issues and it
> looks like there is consensus that it needs to be
> addressed.  That's all that I was hoping to achieve.
> 
> Thanks,
> Anoop 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
> > Sent: Monday, June 11, 2007 8:55 AM
> > To: Anoop Ghanwani
> > Cc: rbridge at postel.org
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > 
> > Anoop,
> > 
> > 	Thanks for the well thought out reply.  Please see 
> > continuing discussion below...
> > 
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson  
> > 
> > > -----Original Message-----
> > > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > > Sent: Friday, June 08, 2007 9:15 PM
> > > To: Eric Gray (LO/EUS)
> > > Cc: rbridge at postel.org
> > > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > > Importance: High
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > > >
> > > > 	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.
> > > ...
> > > > 
> > > > 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.
> > > 
> > > I'm not quite sure I get it, but I'll look below.
> > > 
> > > > > 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.
> > > 
> > > I understand there will be some complexity in describing 
> > all the VLANs 
> > > and multicast addresses in a single instance, but I think 
> it scales 
> > > better than multiple instances.  Why?  Consider the 
> > following picture:
> > > 
> > >            D
> > >            |
> > > v1 -- A -- B -- C -- v1
> > >            | 
> > >            E
> > > 
> > > A-E are RBridges.
> > > 
> > > In this picture VLAN v1 is configured only on A and C.  B 
> > doesn't have 
> > > v1 configured on it.  Yet B needs to know about VLAN v1's 
> > location in 
> > > order to correctly prune its trees.
> > 
> > Note that this configuration - if A-E were Q-bridges - would 
> > be pathological, resulting in segmenting v1.
> > 
> > I believe you've over-simplified interactions to make a 
> > point, and the result is an example that does not make that point.
> > 
> > In the above scenario, two simple approaches might have been 
> > used that would not share the pathology of the given
> > example:
> > 
> > 1) B might be configured to support v1 (flat model).
> > 2) A and C might be configured to tunnel (e.g. - Q-in-Q)
> >    v1 via B, using a VID for which B is configured
> >    (hierarchical model).
> > 
> > It may be difficult to imagine why the second choice may be 
> > useful, given the over-simplified example, but it is actually 
> > quite likely to be useful in complex secnarios
> > - particularly involving edge bridges with very large numbers 
> > of subscriber-facing ports with large overlap in VLAN 
> > membership among edge bridges.
> > 
> > These same approaches are also useful with RBridges.
> > 
> > > 
> > > 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, in a flat model, this would be true.  With the 
> > alternative approach, only edge RBridges really have to know 
> > about VLANs at the edge.  Pruding in core RBridges occurs as 
> > a consequence of Q-in-Q (or like
> > approach) configuration.
> > 
> > > 
> > > If you have an instance per VLAN we are talking about 
> > maintain up to 
> > > 4K instances in each Rbridge.
> > > And it's not unheard of to configure a 1000 VLANs in 
> regular 802.1Q 
> > > device.
> > > 
> > 
> > Yes.  I believe this essentially makes my point.  It is done 
> > today, with today's bridges, hence scalability is apparently 
> > not a real concern (yet).
> > 
> > > 
> > > > > 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.
> > > 
> > > See above for why this is not true.  Or tell me how I can 
> > do pruning 
> > > without interior RBridges knowing about all VLANs.
> > 
> > Use a hierarchical model model with VID-based tunneling.
> > 
> > This is not a trivially easy configuration for some 
> > real-world deployment scenarios we can all probably imagine.  
> > But it is also not as trivially easy to break, once correctly 
> > configured.
> > 
> > > 
> > > > 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?
> > > 
> > > Not in a bridged network.  But if I recall correctly, and I 
> > may be off 
> > > since the charter may have changed since the beginning, 
> one of the 
> > > goals of rBridges was to be able to build large campuses without 
> > > routers and routing-related configuration.  Has that gone away?
> > > It is not atypical to find a campus with 20K users on 100's 
> > of VLANs 
> > > with ~100 nodes.
> > 
> > That never was a goal.  There are people who might like to 
> > make it one, but that's (IMO) a malignant nightmare.
> > 
> > There is no conceivable way to build devices that do 
> > everything a router does without incorporating all of the 
> > complexity (read
> > "cost") of a router into that device.  If that's what 
> > somebody really wants to do, then I'd like to hear how they 
> > propose to design routing complexity - using a routing 
> > protocol, and putting everything else a router does into it - 
> > without the end product actually being MORE complex (read 
> > "expensive") than anybody's current routing implementation.
> > 
> > > 
> > > > 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.
> > > 
> > > Even with a network of today's bridges there would be 
> > scaling issues 
> > > if you had say 20-30 rBridges all trying to establish adjacencies 
> > > between groups of themselves for a few 100 VLANs.  It is 
> > not atypical 
> > > to have ~1000 VLANs configured in core switches.
> > 
> > So, for IS-IS (or OSPF), issues with "adjacencies" are not 
> > subject to the same sorts of concerns as (for example) BGP.
> > 
> > What maintaining adjacencies really means is keeping up to 
> > date on link state for a peer-set.  What you're pointing out 
> > is that - for many VLANs - the numer of peer-sets for which 
> > link state has to be maintained may be large.
> > 
> > Short of using hierarchical VLANs, this is competely and 
> > absolutely unavoidable - unless we're going to accept the 
> > consequences of specifying incorrect VLAN interactions as a 
> > mechanism for effectively doing the same thing (i.e. - 
> > effectively specifying hierarchy using some other means, or 
> > simply hoping that people can somehow get it right).
> > 
> > If you assume - as I do - that VLAN traffic is only supposed 
> > to traverse links for which that VLAN is configured (either 
> > explicitly or implicity), than not including a VLAN (again, 
> > either explicitly or implicitly) in the configuration for a 
> > specific link means that that VLAN's traffic is not supposed 
> > to traverse that link.  Period.
> > 
> > > 
> > > > 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.
> > > 
> > > They scale just fine because they limit the maximum 
> number of trees 
> > > and have some VLANs share a tree.  They don't try to run one STP 
> > > instance per VLAN.
> > 
> > Right.  Assuming you've gotten your head around the notion of 
> > hierarchical VLANs, how is this different?
> > 
> > >  
> > > > 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.
> > > 
> > > This cannot be compared with routers.  We're talking 
> about bridging 
> > > here.  If we routed, we'd just terminate the MAC domain 
> at the edge 
> > > router and we wouldn't run into any of these issues.  No sense in 
> > > having a VLAN interface on every router in the campus.
> > > (One could design the network that way, but it would be a 
> > really bad 
> > > way to do it.)
> > 
> > The point is that - if you had 1000 (or 4000) VLANs, in a 
> > subnet, you would terminate a large percentage of those on 
> > connected routers.
> > 
> > If you imagine that there are many sch subnets (as seems to 
> > be implied in your earlier comments), then this would also be 
> > true for other physical interfaces on each router.
> > 
> > Also, if you believe that RBridges may be used to replace 
> > routers, then you compound this issue.
> > 
> > >  
> > > > 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.
> > > 
> > > I thought I knew what the charter was but I went back and read it 
> > > again anyway.  I didn't find much there to work with with 
> > respect to 
> > > scalability requirements.
> > > It talks about a "problem statement and applicability"
> > > document.  I'm not sure which of the published documents that is.
> > 
> > It is the one that has that name.  Joe Touch is the main 
> > author/editor (with Radia Perlman).  It apparently has been 
> > allowed to expire.
> > 
> > See: 
> > 
> > https://datatracker.ietf.org/public/idindex.cgi?command=id_det
> ail&id=147
> > 71
> > 
> > for more information.
> > 
> > By the way, it actually did not expire very long ago, so it 
> > is likely that there is a new version in the works.
> > 
> > However, the way that IETF charters typically work is that 
> > they are exclusive, rather than inclusive, by default.  In 
> > other words, the fact that the charter does not explicitly 
> > include increased scalability as a goal CANNOT be read to 
> > mean that it may be a goal because it is not explicitly excluded.
> > 
> > Per the charter, the design goals for the TRILL solution are:
> > 
> > - Minimal or no configuration required
> > - Load-splitting among multiple paths
> > - Routing loop mitigation (possibly through a TTL field)
> > - Support of multiple points of attachment
> > - Support for broadcast and multicast
> > - No significant service delay after attachment
> > - No less secure than existing bridged solutions
> > 
> > There is nothing in these explicitly listed goals that can be 
> > stretched to include the notion of hugely increased scale, or 
> > replacement of routers.
> > 
> > > 
> > > Anoop
> > > 
> > 
>