Re: [spring] IPv6 EH-insertion (Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function))

<bruno.decraene@orange.com> Thu, 05 September 2019 14:46 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F8012011B; Thu, 5 Sep 2019 07:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XCpWyG6Y4kv; Thu, 5 Sep 2019 07:46:16 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9131200F9; Thu, 5 Sep 2019 07:46:16 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 46PNmQ6t5hz2081; Thu, 5 Sep 2019 16:46:14 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 46PNmQ4d6zzDq7r; Thu, 5 Sep 2019 16:46:14 +0200 (CEST)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 5 Sep 2019 16:46:14 +0200
From: bruno.decraene@orange.com
To: Fernando Gont <fgont@si6networks.com>, Ron Bonica <rbonica@juniper.net>, li zhenqiang <li_zhenqiang@hotmail.com>, Ole Troan <otroan@employees.org>, Fernando Gont <fernando@gont.com.ar>
CC: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Thread-Topic: IPv6 EH-insertion (Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function))
Thread-Index: AQHVY5nKlGeAV4OrFUmd/rZB2nnrg6cdHmwA
Date: Thu, 05 Sep 2019 14:46:13 +0000
Message-ID: <17262_1567694774_5D711FB6_17262_144_1_53C29892C857584299CBF5D05346208A48BFA9FB@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <BYAPR05MB54637FEAE1518F83977D274FAEB80@BYAPR05MB5463.namprd05.prod.outlook.com> <0d3df64e-d596-1cac-eb3d-e08a6e1151ea@si6networks.com> <HK0PR03MB3970EB9B1326CDD4609A6CB4FCBB0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BL0PR05MB54580DA411A332701090B5A6AEBB0@BL0PR05MB5458.namprd05.prod.outlook.com> <66f1195d-3e71-71d8-9304-1b5e76211c5b@si6networks.com>
In-Reply-To: <66f1195d-3e71-71d8-9304-1b5e76211c5b@si6networks.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UGKx1uPAp9wmaock1RIASk-lLuI>
X-Mailman-Approved-At: Thu, 05 Sep 2019 09:35:01 -0700
Subject: Re: [spring] IPv6 EH-insertion (Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function))
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 14:46:20 -0000

Fernando,

> Ron,
> 
> On 5/9/19 06:01, Ron Bonica wrote:
> > Fernando, Zhenqiang,
> > 
> > You both have valid points. Maybe I am becoming too tolerant of
> > deviations from the specification.
> 
> This is not a deviation in the spec. It's an outright violation of the spec.
> 
> This topic has a rich history in 6man, which I will summarize as follows:
> 
> 1) Folks proposed the segment routing header I-D with the argument that
> it wasn't clear whether EH-insertion was allowed in RFC2460 or not --
> when it was clear to virtually everyone else that it was forbidden
> 
> 2) The segment-routing header I-D was adopted on the condition that all
> text related to EH insertion should be removed.
> 
> 3) Since we were in the process of doing rfc2460bis, we had the
> discussion to make the text crystal-clear that EH-insertion was
> forbidden. -- in fact, it already was. But based on 1) we discussed to
> make it 200% clear.
> 
> 4) Some folks argued not to add text on the topic, leaving, from their
> pov, the spec ambiguous. This "version" of rfc2460bis was shipped from
> the wg.
> 
> 5) During IETF LC of rfc2460bis, the issue was raised again, and there
> was finally consensus to add very explicit text noting that EH insertion
> is forbidden. And this became RFC8200.
> 
> 
> My question to the spring wg chairs and routing area ADs therefore is:
> how come the wg adopted a document (e.g.:
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01)
> when it contains outright violations of specs (RFC8200) that are not in
> the charter of spring wg to update? (as far as I understand).

1) 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's clear that it would not going to be published before [I-D.voyer-6man-extension-header-insertion] be published as RFC. And from its name, the latter is intended to be discussed and within control of the 6MAN WG.

2) When writing a specification (i.e. changing the standard), there is the question of whether we directly define the new behavior, or whether we need to motivate the change from a usage perspective. Aka do we need use cases documents or is this a waste of IETF time? When the point is difficult or subject to debate, the proposed change is easily dismissed based on the absence of a written need for that change.
Hence it looks to me reasonable that the SPRING WG explicitly states that SRH insertion would be useful, rather than some individual brings this to the 6MAN WG, individually claiming that it's useful for SR. If you are fine with this, AFAIK, this is done with a WG adoption.
Again, draft-ietf-spring-srv6-network-programming has a normative reference that would automatically block RFC publication. I'm not sure what additional safety you would want?
The SPRING WG is not to be point of asking publication of draft-ietf-spring-srv6-network-programming. It's in a WG for discussion. If your point is that you don't want the spring WG to discuss the usage of EH insertion, then you are welcome to contribute to the SPRING WG. And thank you for doing that.

--Bruno

> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> 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.