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

[David Lamparter <[e-mail]>]

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.