[rbridge] per-VLAN instances of IS-IS

[Anoop Ghanwani]

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
> > 
>