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

[David Lamparter <[e-mail]>]

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