Subject: Re: [Isis-wg] WG adoption of draft-baker-ipv6-isis-dst-src-routing-06

From: David Lamparter <[email-masked]>
Date: Tue, 18 Jul 2017 11:35:42 +0200

Hello IS-IS folks,

so, I've unfortunately dropped the ball on this (had some health issues,
but really I'm just bad at IETF interactions).  I'd like to apologize
for that and am certainly working to improve.

Having just sat through a v6ops presentation of Microsoft's setup for
their enterprise cloud products relying on multihomed IPv6 setups with
distinct source prefixes pushed to clients, I'm re-motivated that this
is a draft worth pushing to RFC -- this is after similar signaling from
Google.
Hence, question #1:  I strongly believe we have the input there that
this will see deployment in IS-IS in enterprise setups.  Certainly not
all of them, but enough to be significant.  Les, does this address your
concerns on actual deployment?  (Does anyone else have similar
concerns?)

After that, question #2 would be - what state is this draft actually in
now?  Should I ask for WG adoption again?  As far as I can tell
responses were along "support", "support + address feedback" and
"scepticism on whether it'll actually be deployed".  I didn't see any
flat-out disagreement.

And, finally, #3, I (still, gah) have some pending edits addressing some
feedback Tony raised;  correlated with previous question, I'm not sure
whether I should just repost it as individual draft ASAP?  (and/or
how/whether this interacts with the adoption call.

[I guess the latter 2 are questions for the chairs, but I'll happy about
all input ;)]

Thanks for any help,

-David

---

From: David Lamparter <[email-masked]>
Date: Tue, 18 Jul 2017 18:19:13 +0200

> how/whether this interacts with the adoption call.

I finally understood to be less angsty about it and just push things;
the updated version will be up in a minute.  I've included the relevant
diff below for easier reference.

I believe this addresses all feedback provided by both Tony and Chris --
it's significantly more verbose in describing mixed-network behaviour;
other than addressing possibly ambiguous pieces there is no change to
operation.

Cheers,

-David

diff (without procedural changes, e.g. date & xrefs):

@@ -268,15 +268,91 @@
           not support D/S routing will then -undetectably- lead to incorrect
           routing decisions, possibly including loops.</t>
 
-        <t>As this compatibility mechanism is not considered optional, M-ISIS
-          MUST therefore be implemented for supporting the protocol outlined in
-          this document.  Even installations that previously used only MTID 0
-          (i.e. no M-ISIS) would need to start using MTID TBD-MT0.</t>
+        <t>Therefore, all routers participating in D/S routing MUST implement
+          M-ISIS and participate in the appropriate D/S topology per the table
+          above.  Conversely, routers not supporting D/S routing (or not
+          configured to participate) MUST NOT participate in these topologies.
+          Even installations that previously used only MTID 0 (i.e. no M-ISIS)
+          would need to start using M-ISIS on all D/S routers.  This results
+          in correct operation in the face of partial deployment of D/S
+          routing.</t>
+
+        <t>Note it is implied by the separate topology that there is a separate
+          SPF calculation for that topology - using only the participants of
+          that topology - and D/S routes use paths according to the result from
+          that calculation.  This is an aspect of Multi-topology operation
+          itself, not this document.</t>
+
+        <t>Routers MUST NOT advertise non-D/S routing information using a
+          D/S-Routing MTID.  This includes both reachability information
+          with a source prefix TLV with value ::/0, as well as without a
+          source prefix sub-TLV.  On receipt, routers MUST ignore any
+          reachability information in a D/S-Routing MTID that does not have
+          non-default source prefix information.</t>
+
+        <t>To limit complexity, each IPv6 Reachability TLV in a D/S-Routing
+          MTID MUST have exactly one Source Prefix sub-TLV.  Routers MUST NOT
+          advertise TLVs with more than one Source Prefix sub-TLV, and MUST
+          ignore any received TLV with more than one Source Prefix sub-TLV.</t>
 
         <t>Systems that use topology IDs different than the values reserved by
           IANA should apply the considerations from this section
           analogously.</t>
       </section>
+
+      <section title="Migration and partial deployments">
+        <t>The Multi-topology mechanism described in the previous section
+          introduces a distinct, independently operating topology that covers
+          D/S routers.  This easily allows partial and incremental deployments.
+        </t>
+
+        <t>Such deployments then contain one or more D/S "subdomains" of
+          neighboring routers that have D/S routing capability.  Since shortest
+          paths for D/S routes are calculated using a separate topology,
+          traffic routed on D/S routes will be forwarded inside such a
+          subdomain until it reaches the router originating the
+          reachability.</t>
+
+        <t>Routers unaware or not participating in D/S routing will in such a
+          case forward traffic according to only non-D/S routes.  This can
+          produce 2 distinct outcomes:
+          <list style="numbers">
+            <t>Traffic traverses a D/S router, where a more specific D/S route
+              matches (and SPF in the D/S topology has found a valid path).
+              It is then kept inside the D/S subdomain, reaching
+              an originator of the D/S route.</t>
+            <t>Traffic reaches a system originating a non-D/S route or is
+              considered unroutable even without regard to D/S routes.</t>
+          </list>
+        </t>
+
+        <t>Since the latter case provides no guarantee that there is no D/S
+          route in the routing domain that could have matched, operators must
+          pay careful attention to where non-D/S reachabilities are originated
+          when more specific D/S routes are covered by them.</t>
+
+        <t>A very simple configuration that guarantees correct operation is to
+          ensure covering destination-only reachabilities for D/S routes are
+          originated by D/S routers themselves, and only by them.  This results
+          in traffic entering the D/S subdomain and D/S routes applying.</t>
+
+        <t>Lastly, in partial deployments, disconnected D/S subdomains may
+          exist.  Routers in such a subdomain cannot calculate a path for
+          reachabilities in a subdomain they're not in.  In this case a router
+          MAY discard packets matching a D/S reachability for which it was
+          unable to calculate a valid path.  Alternatively, it MAY behave
+          as if the D/S reachability didn't exist to begin with, i.e. routing
+          the packet using the next less specific route (which could be D/S or
+          non-D/S).  It MUST NOT keep stale SPF calculation results that have
+          become invalid as result of the topology partition.</t>
+
+        <t>This can be remediated by the operator adding connectivity between
+          the subdomains, for example using some tunneling interface.  The new
+          link is then used to form an IS-IS adjacency fusing the previously
+          split subdomains.  The link will then be used to forward D/S traffic,
+          possibly incurring some tunnel encapsulation overhead.  To the IS-IS
+          implementation, this link is no different from other links.</t>
+      </section>
     </section>
 
     <section anchor="new-tlvs"
@@ -312,7 +389,11 @@ IPv6 management    5       TBD-MT5
 
             <t hangText="Prefix:">(source prefix length+7)/8 octets of
             prefix</t>
-          </list></t>
+        </list></t>
+        <t>This Sub-TLV MUST occur exactly once in all reachability originated
+          in any of the D/S topologies listed in <xref target="mtids"/>.  A
+          reachability in these topologies with the Sub-TLV either missing or
+          present more than once MUST be ignored in its entirety.</t>
       </section>
     </section>
 
@@ -400,9 +482,10 @@ IPv6 management    5       TBD-MT5
             routers and reach the last hop as intended, or (b) cross a D/S
             router at some point.</t>
           <t>For case (b), the D/S router may (b1) or may not (b2) have a more
-            specific D/S route.  In case (b2), packets will be routed based on
-            the same decisions that a non-D/S system would apply, so they will
-            reach their last hop without any differences.</t>
+            specific D/S route with a valid path.  In case (b2), packets will
+            be routed based on the same decisions that a non-D/S system would
+            apply, so they will reach their last hop without any
+            differences.</t>
           <t>For case (b1), a break in forwarding behaviour happens for packets
             as they hit the first D/S-capable router, possibly after traversing
             some non-D/S systems.  That router will apply D/S routing - which,
@@ -412,20 +495,37 @@ IPv6 management    5       TBD-MT5
             as intended.</t>
           <t>Packets starting out on a D/S-capable router fall into cases (b1)
             or (b2) as if a non-D/S router routed them first.</t>
-          <t>If, for case (b1), the system knows of the existence of a more
-            specific D/S route, but cannot calculate a valid path, it may
-            either apply non-D/S routing (i.e. not install any route) or
-            discard the packet (i.e. install a discard route).  The next hop
-            will either be a non-D/S system, or a D/S system with the same
-            link-state information (and thus again unable to calculate a valid
-            path -- or, more specifically, won't calculate a path that includes
-            the previous router).</t>
+          <t>For both cases (b1) and (b2), a situation where a D/S router
+            is aware (by flooding) of a more specific D/S route, but can't
+            calculate a valid path (because the MT topology is not contiguous),
+            this is for correctness concerns identical to the D/S route not
+            existing to begin with.  Note below on the correctness of this.</t>
       </list></t>
       <t>The compatibility mechanics thus rest on 2 pillars:
         <list>
           <t>D/S routes will match as more specific if applicable</t>
           <t>Packets will transit into D/S routing but not out of it</t>
       </list></t>
+      <t>Note that the latter assumption holds true even if D/S routers fall
+        back to non-D/S paths if they cannot calculate a shortest path towards
+        the advertising system (either because SPF reaches the maximum path
+        metric, or because there are multiple discontiguous D/S subdomains).
+        This is because if a router A receives a packet routed on a D/S path,
+        this implies the previous router B was able to successfully calculate
+        SPF, via A, and that A has a path towards the originating system with a
+        lower path metric than B.  Conversely, if router A is unable to find
+        a valid path, it is safe to assume router B was unable to do so either,
+        and B forwarded the packet on a path calculated on non-D/S
+        information.</t>
+      <t>Lastly, in terms of application use cases, it is also worth pointing
+        out that loops will always result if (for example on a boundary to
+        an upstream) the prefix routed incoming to the IS-IS domain is not
+        fully covered by routes.  Just as in non-D/S routing, this may cause
+        a less specific (default) route to apply and loop packets back onto
+        the same upstream.  With D/S routing, this can now also occur if the
+        incoming prefix is not covered for all sources.  The solution remains
+        the same:  making sure the entire prefix is covered (for all sources),
+        usually with a discard route.  This is not an IS-IS consideration.</t>
     </section>
 
     <section anchor="log" title="Change Log">