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

From: David Lamparter <[email-masked]>
Date: Tue, 18 Oct 2016 23:32:47 +0200

Hello IS-IS wg,

I'd like to request/suggest WG adoption of

  draft-baker-ipv6-isis-dst-src-routing-06

[https://datatracker.ietf.org/doc/draft-baker-ipv6-isis-dst-src-routing/]

which describes the IS-IS bits of source/destination routing and would
also like to head for early-allocation[*] of codepoints and MTID values
(all marked "TBD" in the document).  The rtgwg counterpart,
draft-ietf-rtgwg-dst-src-routing[-02], was adopted by rtgwg a year ago.

I'm also unaware of any IPR related to this draft, responding "no" to
the boilerplate according to RFC 6702 Appendix A.3 :)

The -06 version is identical to -05 except for updating Fred's author
block.  I don't expect significant changes in protocol operation and am
unaware of open feedback in that direction (thus also the
early-allocation request).

As there haven't been any changes I'm unsure whether I should re-present
the document; it'd probably end up being a repeat wasting people's time
but I'd be happy to bring it up...

Cheers,

-David

[*] early-allocation seems to not apply for blocks under "Expert Review"
    procedure, not sure if there is a process there?

---

From: Fred Baker <[email-masked]>
Date: Tue, 18 Oct 2016 14:35:01 -0700

I would similarly favor working group adoption. I do not plan to be in Seoul at this time, but would be happy to engage in mailer discussion.

> On Oct 18, 2016, at 2:32 PM, David Lamparter <[email-masked]> wrote:
> 
> Hello IS-IS wg,
> 
>

---

From: Chris Bowers <[email-masked]>
Date: Thu, 27 Oct 2016 12:51:19 +0000

David,

I have two main comments/questions on this.

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.  

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.  

   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.

It would be good to clarify this statement.  I interpret it to mean that all prefix advertisements
to use TLV#237, so that even routers that are currently using TLV#236 to advertise IPv6 prefixes
would need to start using TLV#237 instead.  But it is not clear what MT-ID a router not supporting
SADR should use when advertising a prefix in TLV#237, since it can't use MT-ID=0.

In any case, it would be good to clarify overall if and how this solution achieves the goal of 
requiring only a subset of routers to be upgraded from a basic non-MT deployment of ISIS.  
As part of this, it would be good to explain how TLV#222 and TLV#229 (the other multi-topology
TLVs) are used in the partial deployment case.

2)  For addressing PA multi-homing for IPv6 w/o NAT in existing enterprises,  I would 
guess that >90% of enterprises running a link-state routing protocol are running 
OSPF as opposed to ISIS.  Is the expectation that enterprises will switch to ISIS 
in order to address this problem?   I would like to better understand what use cases this work 
is targeted at from a practical point of view.

Chris

-----Original Message-----
From: Isis-wg [mailto:[email-masked]] On Behalf Of David Lamparter
Sent: Tuesday, October 18, 2016 4:33 PM
To: [email-masked] list ([email-masked]) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-src-routing-06

Hello IS-IS wg,

which describes the IS-IS bits of source/destination routing and would also like to head for early-allocation[*] of codepoints and MTID values (all marked "TBD" in the document).  The rtgwg counterpart, draft-ietf-rtgwg-dst-src-routing[-02], was adopted by rtgwg a year ago.

I'm also unaware of any IPR related to this draft, responding "no" to the boilerplate according to RFC 6702 Appendix A.3 :)

The -06 version is identical to -05 except for updating Fred's author block.  I don't expect significant changes in protocol operation and am unaware of open feedback in that direction (thus also the early-allocation request).

As there haven't been any changes I'm unsure whether I should re-present the document; it'd probably end up being a repeat wasting people's time but I'd be happy to bring it up...

Cheers,

-David

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: David Lamparter <[email-masked]>
Date: Thu, 27 Oct 2016 16:12:23 +0200

Hi Chris,

> I have two main comments/questions on this.

Useful feedback, Thanks!

> start by upgrading a subset of routers to support SADR, starting at the site egress routers.  

Yes, that's the intent.

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

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

> SADR should use when advertising a prefix in TLV#237, since it can't use MT-ID=0.

No -- all non-SADR routing information stays in MTID 0/TLV 236 (or
2/237, if you're using separate IPv4/IPv6 MT topologies).  There is no
change to non-SADR routes, and by using a separate MTID for SADR, they
will be routed "around" as non-participants in the SADR topology to
ensure proper SADR operation.  (That's the core idea why MT is used
here.)

As a nice side-effect, the operator also has some good control here in
feeding information to non-SADR systems.  For example, they can
advertise non-SADR default routes at one or more selected SADR routers,
so traffic towards the internet flows towards the "SADR subdomain",
where it can then be SADR-routed to the proper exit.

(MT makes sure SADR-routed traffic, once in the "SADR subdomain", will
never be routed back towards non-SADR routers.  They're not in the MT
topology, thus not in SPF, thus not in the shortest path used for SADR
routes.)

> is targeted at from a practical point of view.

There is/was a companion OSPF draft:
https://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing/
which we need to revive I guess.  The OSPF version has the additional
constraint that it is built on another draft in progress:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
which led to (my personal) decision to focus on the IS-IS draft and "fix
OSPF later."  Sorry, OSPF ;)

Updating the doc -- also planning to explain some protocol-agnostic MT
considerations in the rtgwg document -- expect another mail from me
soon (with a diff attached),

-David

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 27 Oct 2016 14:57:56 +0000

David -

> Sent: Thursday, October 27, 2016 7:12 AM
> To: Chris Bowers
> Cc: [email-masked]; [email-masked]; [email-masked]
> list ([email-masked])
> Subject: Re: [Isis-wg] Requesting WG adoption of draft-baker-ipv6-isis-dst-
> src-routing-06
> 
> Hi Chris,
> 
> > 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.
> 
> see any of the SADR routes -- which is exactly the intended goal.  I'll update
> the draft to say this very clearly.
> 
[Les:] For my taste the best way to do this is simply to remove the statement:

" Even installations that previously used only MTID 0
   (i.e.  no M-ISIS) would need to start using MTID TBD-MT0."

You don't need to explain the way MT works because you are making no changes to RFC 5120. Trying to "explain" is only going put you at risk for misinterpretation - and this thread is an existence proof for that. :-)

It is the first sentence of the same paragraph which is important:

" As this compatibility mechanism is not considered optional, M-ISIS
   MUST therefore be implemented for supporting the protocol outlined in
   this document."

(though I would prefer replacing "protocol" with "extensions")

  Les

> 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.
> 
> > It would be good to clarify this statement.  I interpret it to mean
> > that all prefix advertisements to use TLV#237, so that even routers
> > that are currently using TLV#236 to advertise IPv6 prefixes would need
> > to start using TLV#237 instead.  But it is not clear what MT-ID a router not
> supporting SADR should use when advertising a prefix in TLV#237, since it
> can't use MT-ID=0.
> 
> No -- all non-SADR routing information stays in MTID 0/TLV 236 (or 2/237, if
> you're using separate IPv4/IPv6 MT topologies).  There is no change to non-
> SADR routes, and by using a separate MTID for SADR, they will be routed
> "around" as non-participants in the SADR topology to ensure proper SADR
> operation.  (That's the core idea why MT is used
> here.)
> 
> 
> feeding information to non-SADR systems.  For example, they can advertise
> non-SADR default routes at one or more selected SADR routers, so traffic
> towards the internet flows towards the "SADR subdomain", where it can
> then be SADR-routed to the proper exit.
> 
> > In any case, it would be good to clarify overall if and how this
> > solution achieves the goal of requiring only a subset of routers to be
> upgraded from a basic non-MT deployment of ISIS.
> > 2)  For addressing PA multi-homing for IPv6 w/o NAT in existing
> > enterprises,  I would guess that >90% of enterprises running a
> > link-state routing protocol are running OSPF as opposed to ISIS.  Is the
> expectation that enterprises will switch to ISIS
> which led to (my personal) decision to focus on the IS-IS draft and "fix OSPF
> later."  Sorry, OSPF ;)
> 
> 
> considerations in the rtgwg document -- expect another mail from me soon
> (with a diff attached),
> 
> 
> -David
>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 27 Oct 2016 19:02:43 -0700

> 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