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

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

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:[e-mail]] On Behalf Of David
> Lamparter
> Sent: Monday, October 20, 2014 2:41 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg