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

["Acee Lindem (acee)" <[e-mail]>]

Hi David, Les, 

I agree with Les that this is way too much protocol machinery for src/dest
routing. With respect to mixed deployments, why couldn¹t an ISIS router
just advertise its node-level capability to support src/dest and state
that any ISIS router supporting this capability must support installation
of src/dest routes in the base topology RIB/FIB? Then in the partial
deployment scenario, a straight forward but naïve implementation would
simply do two SPFs for the base topology (the normal SPF and one excluding
nodes not supporting src/dest routing). It seems that this would meet the
requirements. I admit that I haven¹t thought about this at length so I may
be missing somethingŠ

Thanks,
Acee 


On 11/13/14, 10:04 PM, "Les Ginsberg (ginsberg)" <[e-mail]>
wrote:

>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
>
>_______________________________________________
>Isis-wg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/isis-wg