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.li...@gmail.com> Sent: Monday, September 2, 2019 1:10 PM To: Suresh Krishnan <suresh.krish...@gmail.com> Cc: 6...@ietf.org; Fernando Gont <ferna...@gont.com.ar>; Ron Bonica <rbon...@juniper.net>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org>; draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insert...@ietf.org>; spr...@ietf..org Subject: Re: Question about SRv6 Insert function On Mon, Sep 2, 2019 at 9:07 AM Suresh Krishnan <suresh.krish...@gmail.com<mailto:suresh.krish...@gmail.com>> wrote: Hi Fernando, On Aug 31, 2019, at 10:09 AM, Fernando Gont <ferna...@gont.com.ar<mailto:ferna...@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 i...@ietf.org<mailto:i...@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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring