Re: [Isis-wg] IS-IS Critical Sub-TLV & Dst/Src-Routing drafts

["Les Ginsberg (ginsberg)" <[e-mail]>]

David -

> -----Original Message-----
> From: David Lamparter [mailto:[e-mail]]
> Sent: Thursday, November 13, 2014 7:55 PM
> To: Les Ginsberg (ginsberg)
> Cc: David Lamparter; [e-mail]; Hannes Gredler; Chris Hopps; Fred
> Baker (fred)
> Subject: Re: [Isis-wg] IS-IS Critical Sub-TLV & Dst/Src-Routing drafts
> 
> (response inline)
> 
> On Fri, Nov 14, 2014 at 12:53:23AM +0000, Les Ginsberg (ginsberg) wrote:
> > David -
> >
> > I have read this draft twice now.
> > The first time I hated it.
> > The second time I merely disliked it.
> > If you take that as encouragement - don't. :-)
> >
> > After two readings I have a better appreciation of your motivations,
> > but I still think the proposal is undesirable and unnecessary.
> >
> > Hopefully we can agree that what you are attempting to create are
> > "topologies" - where the "identifier" for a given topology is both a
> > set of "critical sub-TLVs"  and the MTID.
> 
> Yes, this is essentially MT, with MTIDs extended by capability
> indications.
> 
> > However if you want to support more than one topology you need more
> > than just consensus in the control plane as to what features are
> > supported. You also need multiple FIBs and the ability to mark and
> > classify packets so that forwarding is performed using the appropriate
> > FIB.
> 
> No - and this is quite essential.
> 

LES: You have misinterpreted my remarks.
I fully understand what SADR requires - that is NOT what I am commenting about.

You are proposing to reinvent the way prefixes are advertised and the way topology participation is defined and the way unknown code points are handled by the protocol. You certainly don't need to do that for SADR (a point you agree with below) - so if the benefit of the protocol changes is solely to support a single topology then your use case is extremely weak. The only way to justify this is because it provides added value in the general case of MT - and my point is that it does not.

We can disagree - but let's at least understand what it is we are disagreeing about.


> We have one FIB, which is capable of dst-src routing, which happens to
> be backward compatible with dst routing by filling src as ::/0.
> 
> (You haven't drawn the comparison, but for the merit of everyone on list
> let me delineate this against MT policy routing based on source
> addresses:  we're _not_ running one topology per source prefix.  The
> scenario is a lot of intradomain reachability, communicated classically
> without src prefix, and then a handful of dst-src prefixes for external
> connectivity, maybe a VPN or IPTV service.)
> 
> Yes we can use MT instead of this capability-based delineation.  This
> would mean installing routes from two MTIDs into one FIB.
> 
> > And of course a way of agreeing on consistent classification
> > throughout the topology. This then introduces a large set on
> > constraints as to whether the routing protocol should advertise
> > whether it supports or does not support a particular critical sub-TLV.
> > It is not enough to know whether the protocol code itself understands
> > the code point. Issues such as:
> >
> > Does the forwarding plane support the forwarding paradigm?
> > Is the associated QOS policy supported?
> > Is the support consistemt across all possible forwarding engines with
> which the control may be integrated?
> > If a particular sub-TLV includes multiple capabilities (e.g. using flag bits)
> how do we indicate what subset of the functionality a particular code point
> might advertise we support? (Oh sure - we'll just forbid flags in critical sub-
> TLVs in favor of more code points and less efficient encoding??)
> 
> Right, this all boils down to the capability signaling mechanism
> currently in the draft being too simple.  This -00 is only designed
> to get dst-src interoperable with non-dst-src routers.  For that,
> there's only one bit to care about: "is dst-src supported down from
> IS-IS into the FIB?" - so that's what it communciates.
> 
> > And of course, none of this is a perfect solution to partial
> > deployment since it is still possible to partition the topology.
> 
> Yes, if you have two dst-src islands connected by dst-only routers,
> that's not going to work.  That's not a solvable problem within our
> constraints (= no tunneling.)
> 
> > If we are going to reinvent a significant portion of the protocol I
> > would want a much higher ROI than I see in this proposal.
> 
> Reinventing a significant portion of the protocol refers to the
> suggestion to calculate the topology based on the capability indication,
> I assume?  If the feedback is to not mess with the topology and go
> install a blackhole instead, that's useful input.
> 
> FWIW, I don't agree that it's reinventing a significant portion of
> IS-IS.  In the end, it boils down to running the MT calculations with
> the ID conveyed not as a number but by a TLV set.
> 
> > You don't need this to solve the initial problem which motivated you
> > to write this (SADR partial deployment). Existing RFC 5120 support and
> > using a reserved MTID for SADR would do just as well (though this
> > should not be interpreted as me recommending that you do that).
> 
> That's one of the fallback options.  Another is to go for a new "main"
> TLV type non-generically for a dst-src only.  Yet another (the worst
> one, IMHO) is to signal capability in IIHs and not become adjacent with
> IS that don't have dst-src capability.
> 
> > I suggest you abandon this work.
> 
> All of it, or just the implicit MT, or something else?
> 

LES: Abandon this  draft is what I mean.

   Les

> 
> -David