Re: [spring] Question about SRv6 Insert function

<> Thu, 05 September 2019 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9A411201CE; Thu, 5 Sep 2019 09:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KGK5jQ2vfgEp; Thu, 5 Sep 2019 09:25:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76F6D120112; Thu, 5 Sep 2019 09:25:14 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id 46PQyc6S22z1yVL; Thu, 5 Sep 2019 18:25:12 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by (ESMTP service) with ESMTP id 46PQyc5f4NzDq7X; Thu, 5 Sep 2019 18:25:12 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM6D.corporate.adroot.infra.ftgroup ([fe80::4c24:f1ba:2b1:e490%21]) with mapi id 14.03.0468.000; Thu, 5 Sep 2019 18:25:12 +0200
From: <>
To: Fernando Gont <>, Fernando Gont <>
CC: Ron Bonica <>, "" <>, "" <>, Suresh Krishnan <>, draft-voyer-6man-extension-header-insertion <>, draft-ietf-spring-srv6-network-programming <>, li zhenqiang <>
Thread-Topic: [spring] Question about SRv6 Insert function
Thread-Index: AQHVY/n8O8tIIT2x+0CySPahm/UmEacdNKpA
Date: Thu, 5 Sep 2019 16:25:12 +0000
Message-ID: <17120_1567700712_5D7136E8_17120_341_1_53C29892C857584299CBF5D05346208A48BFAEF1@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [spring] Question about SRv6 Insert function
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 16:25:18 -0000

> From: Fernando Gont [] 
> Sent: Thursday, September 5, 2019 4:56 PM
> On 5/9/19 17:46, wrote:
> > Fernando,
> > 
> >  
> >> From: spring [] On Behalf Of Fernando Gont
> >> Sent: Tuesday, September 3, 2019 1:18 PM
> >>
> >> Hello, Suresh,
> >>
> >> On 2/9/19 19:07, Suresh Krishnan wrote:
> >> [....]
> >>>>> 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
> >>>
> >>>
> >>
> >> This seems e bit misleading. What I would expect is that before any work
> >> is published on EH-insertion, the IPv6 standard is updated to allow for
> >> EH insertion. (plese see bellow)
> >>
> >>
> >>
> >>
> >>>> 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.
> >>
> >> Since there have been plenty of attempts to do EH insertion or leave the
> >> IPv6 standard ambiguous in this respect, and the IETF has had consensus
> >> that EH insertion is not allowed, I think it would be bad, wastefull,
> >> tricky, and even dangerous to let a document go through the whole
> >> publication process, and just rely on the AD to keep the "DISCUSS"
> >> button pressed.
> > 
> > draft-ietf-spring-srv6-network-programming has a normative reference to [I-D.voyer-6man-extension-header-insertion]
> >
> > 
> > As such, from a process standpoint, it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be itself published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG. So I don't think that we can say that it "just rely on the AD to keep the "DISCUSS" button pressed."
> > 
> > In my mind, this should also be a clear indication that the question of header insertion is (to be) within the control of the 6MAN WG. But you may have a different opinion.
> Maybe my mental algorithm has a bug, but: what's the point of spring
> working on a document that relies on something that 6man has so far
> rejected?

I take your point that 6MAN has rejected, in the past, general header insertion. (under the control of the 6MAN WG as I feel some nuances depending on the speakers)
I don't know about the future 6MAN position with regards to SRH insertion specifically for SRv6, possibly restricted to a specific usage (e.g. TI-LFA) or context (e.g. source, transit and destinations nodes are within a single control domain). As of today, I'm expecting [I-D.voyer-6man-extension-header-insertion] to reflect this and I'm using it as a coordination and gating tooling between 2 IETF WGs. I'm open to considering others tools. But if your point is that the SPRING WG cannot discuss, envisage and document the usage of SRH insertion in the SPRING context, that is not my reading of the SPRING charter. As part of this discussion, you are very welcome to contribute.

Finally, let me remind that draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, and is NOT meant to  update RFC8200. This has been explicitly stated "this document is not intended to update RFC 8200. If a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in the 6MAN WG and normatively referenced."

> You spend energy on the document and then... just sit on the I-D to see
> if 6man adopts voyer-6man-extension-header-insertion? Ship the document
> to the IESG for them to review? -- I'm lost, sorry.

draft-ietf-spring-srv6-network-programming is not primarily about header insertion. Its scope is much wider.
So SPRING WG is working on the whole text of draft-ietf-spring-srv6-network-programming. If at some point the normative reference to [I-D.voyer-6man-extension-header-insertion] is holding the progression of the document, as of today I could see two paths: wait some more time/forever (i.e. never publish that document as RFC); remove the text blocking the progression. Personally, I would assume the latter. There could be others options, but I'd rather consider this when/if we face the problem. In the meantime, would you have an issue with any of those two/three hypothetic paths (wait, never publish, remove SRH insertion)?

Thank you.
> -- 
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.