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

[Tony Przygienda <[e-mail]>]

On Thu, Oct 27, 2016 at 7:12 AM, David Lamparter <[e-mail]> wrote:

> Hi Chris,
>
> On Thu, Oct 27, 2016 at 12:51:19PM +0000, Chris Bowers wrote:
> > I have two main comments/questions on this.
>
> Useful feedback, Thanks!
>
> > 1)  If I understand correctly, one reason to use existing multi-topology
> routing mechanisms for
> > this is the requirement to support deployments where only a partial
> subset of
> > routers support source address dependent routing.  Ideally, this would
> allow an enterprise site to
> > start by upgrading a subset of routers to support SADR, starting at the
> site egress routers.
>
> Yes, that's the intent.
>
> > However, this statement from section 2.3 seems to imply that all of the
> routers in the enterprise network
> > would need to support multi-topology even if they don't support SADR.
>
> No, non-MT routers would be ignorant of the MT information and would not
> see any of the SADR routes -- which is exactly the intended goal.  I'll
> update the draft to say this very clearly.
>
> >    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.
>
> Ah, I see where I misworded that.  It needs to say "need to start using
> MTID TBD-MT0 *for transporting SADR routes*".
>
> Sidenote:  at some point, the draft allowed non-usage of MT for
> greenfield setups (all routers with SADR support and everything in zero
> MTID / no M-ISIS used at all), with homenet in mind for that.  I'm now
> thinking that was a stupid idea.  However, there might be leftover weird
> wording in the draft from that.
>


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.

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".
   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

      *"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"*


      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

      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.

      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.


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).


--- tony