Re: updated draft-baker-ipv6-isis-dst-src-routing-07

On Tue, Jul 18, 2017 at 11:35:42AM +0200, David Lamparter wrote:
> 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 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">