Re: [spring] Question about SRv6 Insert function

Cameron,

I hear you. SRv6+ will try to limit its ask to the following:

  *   Enough community review to make sure that we aren't doing anything dangerous
  *   Four code points (i.e., two IPv6 Routing types and two IPv6 options)
  *   One registry (i.e., Special purpose SIDs)

Beyond that, we will try to keep the noise to a minimum.

                                          Ron

From: Ca By <cb.list6@gmail.com>
Sent: Monday, September 2, 2019 1:10 PM
To: Suresh Krishnan <suresh.krishnan@gmail.com>
Cc: 6man@ietf.org; Fernando Gont <fernando@gont.com.ar>; Ron Bonica <rbonica@juniper.net>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>; draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>; spring@ietf.org
Subject: Re: Question about SRv6 Insert function

On Mon, Sep 2, 2019 at 9:07 AM Suresh Krishnan <suresh.krishnan@gmail.com<mailto:suresh.krishnan@gmail.com>> wrote:
Hi Fernando,

On Aug 31, 2019, at 10:09 AM, Fernando Gont <fernando@gont.com.ar<mailto:fernando@gont.com.ar>> wrote:

On 30/8/19 20:24, Ron Bonica wrote:
Li,

In the scenarios that you mention, below, SRv6 nodes have the following
options:

1. To prepend and IPv6 header, with its own SRH
2. To insert an SRH, as described below

Option 1 is in keeping with the word and spirit of RFC 8200. As you
point out, Option 2 contradicts RFC 8200.

So, we should probably explore the motivation for Option 2). If the
motivation is not sufficient, we should probably standardize on Option 1.

My argument would be:
Folks would do whatever they please with 1). If somehow they feel the
need to do 2), they should *refrain from even suggesting it*, post an
internet draft that proposes to update RFC8200 to allow for the
insertion of EHs, wait for that to be adopted and published, and only
then suggest to do EH insertion.

I have put down my thoughts on the future of header insertion work in a mail to the 6man list in May 2017. The mail can be found below

https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_ipv6_4MevopH9-5FiQglUizhoT5Rl-2DTjRc&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=d-vzMZODP_ALHfMhubf5WRxJTGOhRzUKJbOtu85Dffk&s=fbmh6fqc8mAnydHmPoIhor-HPFSjlsvhAIwCflKUbSk&e=>

P.S.: Given the amount of discussion there has been on this topic in the
context of RFC8200, I'd like to hope that there's no draft-ietf document
suggesting EH-insertion or, if there is, the relevant ADs and chairs
make sure that's not the case anymore.

Yes. If a draft violates RFC8200 and it hits the IESG for evaluation, I will certainly hold a DISCUSS position until the violations are fixed.

Thanks
Suresh

Thanks. It sounds to me the the SR folks are re-inventing NSH in ipv6.

The internet layer is a narrow waist.

My humble opinion is SR has the same real market traction as  LISP and NSH, meaning very niche, but loud.

They should look at publishing in the experimental track before asking for the world.

Regards,
Cameron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=d-vzMZODP_ALHfMhubf5WRxJTGOhRzUKJbOtu85Dffk&s=CJjpcqScEQwVpIUZyR6cQhyDb5ouN7wH6aIrmCLoIMM&e=>
--------------------------------------------------------------------

Juniper Business Use Only