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

Tony Przygienda <> Fri, 09 December 2016 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F172129512 for <>; Fri, 9 Dec 2016 09:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FYlAFDiadx9b for <>; Fri, 9 Dec 2016 09:12:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE098129417 for <>; Fri, 9 Dec 2016 09:12:58 -0800 (PST)
Received: by with SMTP id c184so14631192wmd.0 for <>; Fri, 09 Dec 2016 09:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oFwr57Z1u2nrB64zn1eQNbRceGTpgN5SiBlhH4RfrVI=; b=pRNeH8q8/NdCluqSMUh6MfLkdWZ+1GXIlrRrJhWiR4XZ0u3OVJ1JJgzGeB/53P3rya eR+qj0b329F7L3wVqcfWHQ8fJfNT6Rm9RPzjqrzjUYKcVoKds/f0fANe3BPzVx90qUJV U1Gft0WREUJ9a3xje41vdvbb5EazgXBZw0y2VzNI9vabAh1iGR6Fy8r8ex2vBSz42BmB Z5mpSB6+BY3DhQQk8pVczs+2JUBMsmKTCGlQLMD0mS/Kq7MvEID/ldMvu3/j3iNnED+M mRW89p/q10DWRl+hhDwfAagRW8+FF3a6yuFUYxE+efqWX837imqmq8UxG3wuHFbzdEbx ZNfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oFwr57Z1u2nrB64zn1eQNbRceGTpgN5SiBlhH4RfrVI=; b=dlOmOEQPSyBTj4Xj7vdhdveIfLafB0A30/q90Y1NsDibjZbhGx1uitrfk16iL2OgCh EvSCCKfAdTqrakX8QcAEKaQM3yiCvM6TfNfB/y0XEsM0hISUE1w0mQ3lmBUPdRnTMRML y9AM/Oy+6HzBApJKIbCuNR17dhbTuMoac4VdZnM7hINko8PtI1+7Kt3jiuqk9seCw6vF 9S7BHbpuqzUaQg5p6wPL/qHnMHRGr/u8ivBxHWGWnthvSiBrBjLBkKF3KsXE5DYpeppv ePNHVzqzb+bav45SSGcg2zb7xiglyzffh0I7jq/E/p8+FZPEaEKZvP6ISXNHoGsAi988 nhvg==
X-Gm-Message-State: AKaTC01pg5zWRISYMjckxWf5Wh0isfnSaDE/y6CQ1HS8fs7TH4LQ2AU+xv7oYNVAxAX5tOH3t/DjbhlXnCEV9g==
X-Received: by with SMTP id y11mr7519152wmg.93.1481303577349; Fri, 09 Dec 2016 09:12:57 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 9 Dec 2016 09:12:16 -0800 (PST)
In-Reply-To: <20161209114441.GI91403@eidolon>
References: <20161018213247.GQ639535@eidolon> <> <20161027141223.GG639535@eidolon> <> <20161209114441.GI91403@eidolon>
From: Tony Przygienda <>
Date: Fri, 9 Dec 2016 09:12:16 -0800
Message-ID: <>
To: David Lamparter <>
Content-Type: multipart/alternative; boundary=001a114b071288661205433cdda2
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 17:13:01 -0000

Either publish or pls drop me the private version with all the corrections.
I'll parse it then with your message. I see right now too many "ooh, yeah,
it works but I didn't write it down yet so you're missing an assumption". I
need all axioms on the table to pick through it again ;-)

Again, I support adoption, correctness is orthogonal (and can be achieved
with the track the draft is on right now)

-- tony

On Fri, Dec 9, 2016 at 3:44 AM, David Lamparter <> wrote:

> 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
> topology.
> 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!
> -David
> 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.

*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky