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

"Chengli (Cheng Li)" <chengli13@huawei.com> Fri, 06 September 2019 15:32 UTC

Return-Path: <chengli13@huawei.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 3612D120D86; Fri, 6 Sep 2019 08:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 CrW09kkHWWO4; Fri, 6 Sep 2019 08:32:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FF0120D56; Fri, 6 Sep 2019 08:32:17 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8C23A17892079A34D65C; Fri, 6 Sep 2019 16:32:15 +0100 (IST)
Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 6 Sep 2019 16:32:15 +0100
Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 6 Sep 2019 16:32:14 +0100
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 6 Sep 2019 16:32:14 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.23]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Fri, 6 Sep 2019 23:32:11 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: "bruno.decraene" <bruno.decraene@orange.com>, 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 <spring@ietf.org>, 6man <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 <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: AQHVZMhAd4tFtob25kWhKu5fOoZ7zA==
Date: Fri, 06 Sep 2019 15:32:10 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB026B769F@dggeml529-mbx.china.huawei.com>
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>, <17262_1567694774_5D711FB6_17262_144_1_53C29892C857584299CBF5D05346208A48BFA9FB@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <17262_1567694774_5D711FB6_17262_144_1_53C29892C857584299CBF5D05346208A48BFA9FB@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB026B769Fdggeml529mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/OOnzbNDuoyh3fbnqu_5LtjJ8x1M>
X-Mailman-Approved-At: Sun, 08 Sep 2019 23:56:10 -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: Fri, 06 Sep 2019 15:32:27 -0000

Hi Bruno,

Agree. I am very curious that why so many emails everyday? And I saw the POVs again and again in different format. I think you have explained very clear.

It looks to me like SRv6 NP draft is going to be published as a RFC. But actually it is a WG item only,and a normative reference to eh insertion draft is in there. Everything is going in the right process.

But I have a question:

Why do these kind of arguments emerge right now instead of 5 years ago? We left the “problem “ for 5 years? And suddenly we notice them? How interesting.


________________________________
Cheng Li
Email: chengli13@huawei.com<mailto:chengli13@huawei.com>



From: bruno.decraene<bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>
To: Fernando Gont<fgont@si6networks.com<mailto:fgont@si6networks.com>>;Ron Bonica<rbonica@juniper.net<mailto:rbonica@juniper.net>>;li zhenqiang<li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>>;Ole Troan<otroan@employees.org<mailto:otroan@employees.org>>;Fernando Gont<fernando@gont.com.ar<mailto:fernando@gont.com.ar>>
Cc: spring<spring@ietf.org<mailto:spring@ietf.org>>;6man<6man@ietf.org<mailto:6man@ietf.org>>;Suresh Krishnan<suresh.krishnan@gmail.com<mailto:suresh.krishnan@gmail.com>>;draft-voyer-6man-extension-header-insertion<draft-voyer-6man-extension-header-insertion@ietf.org<mailto:draft-voyer-6man-extension-header-insertion@ietf.org>>;rtg-ads<rtg-ads@tools.ietf.org<mailto:rtg-ads@tools.ietf.org>>;draft-ietf-spring-srv6-network-programming<draft-ietf-spring-srv6-network-programming@ietf.org<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>>
Subject: RE: IPv6 EH-insertion (Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function))
Time: 2019-09-05 22:47:44

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.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------