Re: [Isis-wg] updated draft-baker-ipv6-isis-dst-src-routing-07
David Lamparter <equinox@diac24.net> Tue, 18 July 2017 16:19 UTC
Return-Path: <equinox@diac24.net>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1AA131535 for <isis-wg@ietfa.amsl.com>; Tue, 18 Jul 2017 09:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GbOMV5ObeNB for <isis-wg@ietfa.amsl.com>; Tue, 18 Jul 2017 09:19:16 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA53128C81 for <isis-wg@ietf.org>; Tue, 18 Jul 2017 09:19:16 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from <equinox@diac24.net>) id 1dXVDN-0002SV-JO; Tue, 18 Jul 2017 18:19:14 +0200
Date: Tue, 18 Jul 2017 18:19:13 +0200
From: David Lamparter <equinox@diac24.net>
To: "isis-wg@ietf.org" <isis-wg@ietf.org>
Message-ID: <20170718161913.GP773745@eidolon>
References: <87d1i34dgr.fsf@chopps.org> <20170718093542.GL773745@eidolon>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20170718093542.GL773745@eidolon>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Ks10yLs2cSZm4_-N8HsLNw8sATA>
Subject: Re: [Isis-wg] updated draft-baker-ipv6-isis-dst-src-routing-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jul 2017 16:19:19 -0000
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">
- [Isis-wg] WG adoption of draft-baker-ipv6-isis-ds… chopps
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… David Lamparter
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Fred Baker
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Mikael Abrahamsson
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Tony Przygienda
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Alia Atlas
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Alia Atlas
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Les Ginsberg (ginsberg)
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… David Lamparter
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Mikael Abrahamsson
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… David Lamparter
- Re: [Isis-wg] updated draft-baker-ipv6-isis-dst-s… David Lamparter
- Re: [Isis-wg] WG adoption of draft-baker-ipv6-isi… Tony Przygienda