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

David Lamparter <> Fri, 09 December 2016 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6711A12A50F for <>; Fri, 9 Dec 2016 03:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32xuVsvUNkGp for <>; Fri, 9 Dec 2016 03:53:21 -0800 (PST)
Received: from ( [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AEC212A51E for <>; Fri, 9 Dec 2016 03:44:46 -0800 (PST)
Received: from equinox by with local (Exim 4.87) (envelope-from <>) id 1cFJbV-000d22-QS; Fri, 09 Dec 2016 12:44:42 +0100
Date: Fri, 09 Dec 2016 12:44:41 +0100
From: David Lamparter <>
To: Tony Przygienda <>
Message-ID: <20161209114441.GI91403@eidolon>
References: <20161018213247.GQ639535@eidolon> <> <20161027141223.GG639535@eidolon> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Cc: "" <>, " list (" <>
Subject: Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Dec 2016 11:53:23 -0000

Hi Tony,

sorry - this got slightly lost in the IETF Seoul haze at my end :( -
more inline.

On Thu, Oct 27, 2016 at 07:02:43PM -0700, Tony Przygienda wrote:
> My first comment a good while ago on the mike when you were showing
> your first proposals was that you'll on a slippery slope to redo MT in
> topology #0 ;-)  Stupid is too strong a word, it's simply one of those
> problems that looks like a "small addition" needed initially until it
> sucks you treacherously underwater.

Yep, let's call that a fun excursion, but now we're on the serious track

> I favor adoption as well as an elegant application of MT with the
> following necessary fixes ;-)

> a) you prescribe 2 different things in the draft ;-)
>    a.1  you want to forklift all the routers in section 2.3. In fact,
>         MT-ISIS has been proposed to prevent such fork-lifting need.
>         Forklifting is sufficient but not necessary as you observe
>         later in the "correctness considerations".

That's not my intention to express, as you say MT's purpose is to avoid
a need to forklift.  I'm not sure where I worded this as forklifting, do
you mean "Therefore, all routers participating in D/S routing MUST
implement M-ISIS and participate in the appropriate D/S topology [...]"?

If so, I need to reword that to make more clear that you *can* mix D/S
and non-D/S routers, but all D/S routers need to consistently implement
MT.  (That's what I tried to say with "participating", I guess that's a
poor choice of words...)

>    a.2  in "correctness considerations" you allow to mix the routers which
>         is correct but the logical chain doesn't hold completely.
>         First "axiom" is clear (i.e. forwarding lookup). The second
>         "pilar"  is confused by

Oh - I'm missing a step there.

So, the unwritten assumption that I need to write out there is:  there
are continuous "subdomains" of D/S routing.  Normally, I would hope
there is only a single such subdomain of D/S routers, and ideally this
is your entire IS-IS domain if every router supports dst-src.

If you lose connectivity and this subdomain splits into two, the case
described there can occur - D/S reachabilities for which no path inside
the MT topology can be found, even though there is non-D/S connectivity.

*However* this is a transitive property.  If a router A can't find a
path for a D/S reachability, neither can its direct neighbors.  To be
completely correct and account for max-metric too, "neither can its
direct neighbors who are farther away".

What the proof really relies on is:  "if your SPF calculation found a
path for D/S reachability (D,S) via IS-IS adjacency N, then N will also
find a path for (D,S) [with a lower path metric]".

>       *"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)."*
>       That seems to contradict *"**Packets will transit into D/S
> routing but not out of it"*

It shouldn't; see below.  If the packet is forwarded on D-only, it
hasn't entered D/S routing yet, even if a D/S router forwarded it.

Once a D/S router forwards it using D/S information, it's safe to assume
(and neccessary for correctness) that the next router will be a D/S
router that also successfully applies D/S forwarding.

>       In short, with your axiom (prefer routes with source match over
>       0/0 source entry) you have two choices for the 2nd axiom (both
>       lead to correct routing but exclude each other). The reason is
>       that you either "enter semantically richer topology and never
>       leave" _OR_ "exit semantically richer semantics and never enter
>       it again". Less formally that translates into
>       Either
>       a) a packet may enter from non D/S into D/S and any D/S MUST NOT
>          forward it to a non D/S next-hop, i.e. you can't install
>          default topology entries into FIB as "union". This holds EVEN
>          when you received the packet from a D/S neighbor since the
>          packet MUST NOT jump out into the non-D/S topo again (it may
>          have came from here upstream).  Otherwise you'll find looping
>          scenarios

(Let me add:
"If you are able to calculate a D/S path, you MUST install and use it.")

>       or
>       b) a packet may exit from D/S into non-D/S, i.e. no source-specific
>          FIB match is found and you match on 0/0 source (topology #0).
>          Once it's out in the non-DS world, it MUST stay there, i.e.
>          you must not as D/S router advertise topology #0 information
>          since a non-DS router may use that to jump into the D/S again
>          not understanding it's doing it.

NB:  the edits I have pending for Chris' comments also clarify that the
D/S topology is NOT intended to contain duplicates of topology #0
information; in fact it should not contain any reachability with S=0/0
(meaning both implicit [no Sub-TLV] or explicit [Sub-TLV with S=0/0]).

>       Again, in short you either enter D/S once and only once and
>       never leave D/S or you exit D/S once and only once and never
>       enter D/S again.

This still holds true:  once a system is forwarding a packet based on a
successful SPF calculation in the D/S topology, it can be assumed that
the next router can also make that successful SPF calculation in the D/S

In reverse, if a D/S system is unable to calculate a path in the D/S
topology, it can assume that the system it received the packet from
wasn't able to do so either.  It may have been a non-D/S router or a D/S
router with no SPF result, but either way the packet has /not/ entered a
D/S forwarding path yet.

(The exception on this, of course, are microloops while information is
being flooded, but that's a generic problem, not dst-src...)

> b) section 3.1: I would explain what is the multiplicity of this TLV and I
>    expect it to be 1 and only 1. Omitting it will collide with MTID#0
>    and having two has no semantics (unless specified).

Right -- this is an open "existence" question where my assumption was
that it'd always be "exactly 1" but I'd left it to wait and see if
someone sees a use for it that I don't :)

(It could be "more than 1" which could signal more than one D/S route
with same D but different S in a single TLV, but I think that's a
counterproductive micro-optimisation that has significant negative
complexity impact.)

I've received no other input and will change it to "MUST ==1".

--Thanks for your extensive input!


P.S.: meta-question - this is still running in WG adoption call; should
I push a new draft anyway or wait?  I also have some edits queued to
adress Chris' comments...  though I wouldn't say any of these edits are
"substantial" changes to the idea.