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

[David Lamparter <[e-mail]>]

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

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?


-David