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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:53:23 +0000

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. 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. 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??)

And of course, none of this is a perfect solution to partial deployment since it is still possible to partition the topology.

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.

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

I suggest you abandon this work.

   Les

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of David
> Lamparter
> Sent: Monday, October 20, 2014 2:41 PM
> To: [email-masked]
> Cc: Hannes Gredler; Chris Hopps
> Subject: [Isis-wg] IS-IS Critical Sub-TLV & Dst/Src-Routing drafts
> 
> Hi isis WG,
> 
> 
> TL;DR: new Reachability TLVs with "critical bit" on Sub-TLVs, and
> refreshed version on baker-ipv6-isis-dst-src.
> 
> 
> submitted to the I-D archive for your consideration are:
> https://datatracker.ietf.org/doc/draft-lamparter-isis-reachability-critical-
> subtlvs/?include_text=1
> https://datatracker.ietf.org/doc/draft-baker-ipv6-isis-dst-src-
> routing/?include_text=1
> (I've submitted the update to Fred's draft just a few minutes ago, it'll
> show up as soon as he clicks "OK".  I'll drop another mail when it's
> visible.)
> 
> These drafts mesh with 2 rtgwg drafts:
> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-
> qualifiers/?include_text=1
> https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-
> routing/?include_text=1
> 
> reachability-critical-subtlvs creates Reachability TLVs with "critical"
> Sub-TLVs.  The idea here is that we really don't want non-SADR routers
> to process the Reachability, discarding the source restriction.  This
> can lead to persistent loops:
> 
>  R1 - R2* - R3 - R4
>  |               |
>  |               2001:db8::/32, src 2001:db8:1234::/48
>  |
>  2001:db8::/32, src ::/0
> 
> R2* doesn't support SADR, R1/3/4 do.
> Inject packet from 2001:db8:1234::1 to 2001:db8::1.  R1 correctly routes
> to R2.  R2 routes back to R1 because it only sees two Reachabilities for
> 2001:db8::/32 without the source spec.  Loop ensues.
> 
> There are alternate solutions to this;  the draft above is the generic
> variant.  As the draft's introduction states, it can be used for all
> kinds of mandatory information, covering destination specification
> amendments like the source prefix restriction, and possibly
> encapsulations (if the originating router requires them to perform
> correct routing).
> 
> Alternate solutions would be:
> - specifically create a Reachability TLV for SADR routes.  Achieves
>   hiding the SADR routes from non-SADR routers, without the generic
>   approach.
> - use a different M-ISIS topology.  However, this implies we're starting
>   to use MT IDs as feature indicators, possibly leading to a cartesian
>   expansion of MT IDs, and it turns M-ISIS into a dependency.
> - only become adjacent to routers supporting SADR.  Poor interop, but a
>   valid approach.
> - ignore the problem.  I've gotten feedback suggesting this is going too
>   far to prevent the admin from shooting itself in the foot by mixing
>   SADR and non-SADR systems.  Personally, I disagree, because I don't
>   think usage scenarios are cleanly separable on the internet, but I'd
>   appreciate feedback on this as well.
> 
> I'd expect the question to come up:  we have _not_ implemented this yet
> in the homenet IS-IS demo.  Right now it's expecting a homogenous
> homenet environment without any checks, and it _will_ persistently loop
> if you put a non-homenet box in the middle and fudge it right.
> 
> There are also things that can be changed about the draft as it is now,
> namely I'm expecting feedback on:
> - TLV encoding.  It's two separate Sub-TLV areas right now.
>   Alternatively, it could be:
>   - some bit indicating "critical"
>   - nested Sub-TLVs for critical/optional
>   - or, a "end of mandatory TLVs" marker TLV
> 
>   Note there's a requirement for a non-empty critical TLV draft in the
>   block, since if it is in fact empty the router is supposed to
>   originate the "normal" Reachability TLVs.
> 
> - SPF requirements.  Right now the draft only specifies the "full"
>   approach of effectively doing MT based on capabilities.  It might be
>   useful to have a simplified "fail to unreachable".  The router would
>   calculate its SPF without looking at capabilities, and then just
>   turn it into an unreachable if a router along the way doesn't support
>   SADR.
> 
> 
> Then, finally, Fred's dst-src draft is updated for MT considerations.
> The draft now suggests Source Prefix Sub-TLVs are applicable to MT IDs
> 0 (default/non-MT), 2 (IPv6 unicast), and 5 (IPv6 management).  It
> notably does not apply to #4 (IPv6 multicast) because there's no source
> address on Multicast RPF lookups.  There's currently a lot of overlap
> still in isis-dst-src;  if I don't get negative feedback on the other
> drafts (lamparter-rtgwg-*) I'll be trimming that.
> 
> 
> And, finally, I'd like to present these in Hawaii - could I get a slot
> on the schedule please?
> 
> Thanks in advance for any feedback,
> 
> 
> -David
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: David Lamparter <[email-masked]>
Date: Fri, 14 Nov 2014 04:54:55 +0100

(response inline)

On Fri, Nov 14, 2014 at 12:53:23AM +0000, Les Ginsberg (ginsberg) wrote:
> 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:
> 

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Nov 2014 08:04:44 +0000

David -

> From: David Lamparter [mailto:[email-masked]]
> Sent: Thursday, November 13, 2014 7:55 PM
> To: Les Ginsberg (ginsberg)
> Cc: David Lamparter; [email-masked]; Hannes Gredler; Chris Hopps; Fred
> Baker (fred)
> Subject: Re: [Isis-wg] IS-IS Critical Sub-TLV & Dst/Src-Routing drafts
> 
> (response inline)
> 

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.

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

LES: Abandon this  draft is what I mean.

   Les

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 14 Nov 2014 16:15:26 +0000

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)" <[email-masked]>
wrote:

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