RE: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

James Guichard <james.n.guichard@futurewei.com> Fri, 06 March 2020 14:31 UTC

Return-Path: <james.n.guichard@futurewei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F93A07CB; Fri, 6 Mar 2020 06:31:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 e75vWj5ckGlp; Fri, 6 Mar 2020 06:31:55 -0800 (PST)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2109.outbound.protection.outlook.com [40.107.244.109]) (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 68C9B3A07C0; Fri, 6 Mar 2020 06:31:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nXqqAzIXY/R/IU0gDvER/cBh+KMcJ+31IucOU0VoOeptopC9+bWG3P8Y9hsua5dAo0hbJ7QkQIzyC0mwRiw91q6vkqVpuLvf/KTx4in2FWf+DyHM6OmW8HYfcJ2+mWMCi9KGwoNHjLZzUGpeeJ/aQ/ZlHPKQFfxHzsYgnGV6+VtncUs3osh3siqlGjiaz+gstTknoYZsfRxAkv9HzXxCD2VdsxQ22BbVeLVN3sH0t1eltNk68/eogMKyO5GsQrX8gZZBv6QEA8s0zQAlk6GrBi7SYdR5mBFydEuusKgrFTylOIu9dMG8dciOJH2LqezdG3elYQXSsY1iHY0IgUCcJA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=hiwiGLjDuo+Kl2+thuM5qDjayCcxWAv/5mGh1QmA9fs=; b=bTQpL0yFBKhgTb6DFnQTRuPHjFytxSAEVWNJJGZ/M6AmhH/XJuL2D5YLTqSeYGMAVTwap4mW2+9I0MrmMU3bo500+5u7EQYTNc82xw6+tqWe5M93fdePht7YoHjwpp3DGu9nivv1o6be+wsnZNcuLtH2WgnBZKIhlKV/jtDiOqMxdoexQ3HuTTJ8JkGq8b5M/vNA6HalkBRGZRjaedB4TcmvfK0VeeOA21HIfgxx5hTYCgpVsgjoQEBqbi/MQR3PwogwEoC+RXssyHbABgf2hdKTFJM5ilQwv8PLwgkn6Ce4rpFjtu0MtRQqyHRJNXZfQAbpQMc7VHESIWBbVYVmvQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=hiwiGLjDuo+Kl2+thuM5qDjayCcxWAv/5mGh1QmA9fs=; b=MJsyRWAzPiYs2zO5eSoMQ1xQFgy95DcWP4NrII56MmLcubaaH8tRp3YOz2LZ1aT5OyurIDVbEfggVYxfrPmnl1zNbW8Zz8sOm82IAq8BEawqg42KMQLpj1kejw1PFfjlxpPsFGj2QCo6MytoPMpiV3BU3I8SPIUmq2ZsSGKu3Ao=
Received: from DM6PR13MB3066.namprd13.prod.outlook.com (2603:10b6:5:19d::18) by DM6PR13MB3113.namprd13.prod.outlook.com (2603:10b6:5:193::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11; Fri, 6 Mar 2020 14:31:53 +0000
Received: from DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::14f3:6cb8:b9da:446]) by DM6PR13MB3066.namprd13.prod.outlook.com ([fe80::14f3:6cb8:b9da:446%5]) with mapi id 15.20.2814.007; Fri, 6 Mar 2020 14:31:53 +0000
From: James Guichard <james.n.guichard@futurewei.com>
To: Mark Smith <markzzzsmith@gmail.com>, "bruno.decraene" <bruno.decraene@orange.com>
CC: Fernando Gont <fgont@si6networks.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: RE: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
Thread-Topic: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)
Thread-Index: AQHV84EFrIxZe3oAMUq/ub5U4AX3Kqg7mzRw
Date: Fri, 06 Mar 2020 14:31:53 +0000
Message-ID: <DM6PR13MB306658D283C3FEFC95CCE5A1D2E30@DM6PR13MB3066.namprd13.prod.outlook.com>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup><6c674995-8cc7-c024-4181-60b160910f75@si6networks.com> <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@OPEXCAUBM43.corporate.adroot.infra.ftgroup><89402a30-129b-314f-90f1-ba6efcdd6a88@si6networks.com> <16536_1576089460_5DF13774_16536_366_1_53C29892C857584299CBF5D05346208A48D273AD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAO42Z2z2s92yitCC0eLrNO3dXe_EarRSUZq8GmJ=QRdZ59d0ag@mail.gmail.com>
In-Reply-To: <CAO42Z2z2s92yitCC0eLrNO3dXe_EarRSUZq8GmJ=QRdZ59d0ag@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=james.n.guichard@futurewei.com;
x-originating-ip: [107.77.223.195]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d4cedbab-8a3e-40fa-f820-08d7c1db1dbc
x-ms-traffictypediagnostic: DM6PR13MB3113:
x-microsoft-antispam-prvs: <DM6PR13MB31131327D07335DF1514A2F8D2E30@DM6PR13MB3113.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0334223192
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(39850400004)(376002)(346002)(366004)(396003)(136003)(199004)(189003)(81166006)(81156014)(33656002)(110136005)(45080400002)(8676002)(55016002)(9686003)(86362001)(54906003)(8936002)(64756008)(66946007)(71200400001)(66556008)(6506007)(53546011)(186003)(52536014)(5660300002)(66446008)(66476007)(316002)(76116006)(2906002)(7696005)(26005)(478600001)(4326008)(966005)(66574012); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR13MB3113; H:DM6PR13MB3066.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ANotjSyO8dzUy20tlguXjHS+HRibXXP3iCZ89mmvt/kb61LrqLHTE3DaxOTHxa+y/k9RPMfS4fPvItxPHpSv/TQ3nh/mswQ8jy6zMC023RfUD6b8O13SvW6QUPfwwjyky5oiuPF/FK/bV43maCLo4bvP0n8nLNqFinhMfa9PcNudyfMrI7DSm24MKHkZwQUsRaP1u5w2XqTy2BmD4aPVCf83EslmXC6RpMRfSFD+Rinv/0MEP4/S62rtfgt3PXeG8oHxUchNIUMoJYUt+EumIRMr+oWHueeMp/3I3unHKxjDjKwuAFKm2FB4kKB9dwHyyjiPU4SDn1ZffG6v5CqKm3B5zSRBtK/R/IiKxOpcRo8Hqn7XWPwf2Cq39/su4dwpiCWehVS501/ZRZrPJtlfAIwEKpkbe0DcF4cshfNRki4JOINQJaARbMNxCE3x3sjMvAdjFtflrHiN7MqRkGNe7HTDdDSHJpQSgELMmNdw+EPClU7Xyv8WBqek8sv6NfWDH/J3VGYRG9EkDk658A3o/25qjGcMmEL2Uzub7CEmkBwEThdjCgH9b0SZvUXgmIJSDcwZU35Fhz1F+KvB8GZ9pGFAghdOq1h1Z+ssnT+HfoZtl3SGBoW3PzeNzKBzeXpF
x-ms-exchange-antispam-messagedata: R2efkQ4oqJE7OgqFQgQ8lgxeg01lIPUkJSSl183vExmn4iyaKq2n/6+dnPg9Txm1dH+XDOqeCn+/kldmvYZM0S+4w4s5zQ/KBE+vaEd7wYsy3j129n0Gw4nMWk0Hcogc1BpakjxD5o4zVfkI8ns/PA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d4cedbab-8a3e-40fa-f820-08d7c1db1dbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 14:31:53.6497 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tTXH4fknI3elsqxdwOZnIvZJg/SMmbh6FiGJmQ+kqhwiyOrBb4eCm53ITEKvzcYJtJgILHRcIlB7v0PpRPjbLA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3113
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/eUtEW2yyrJpKZ10jLhXudpn4SAU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 14:31:58 -0000

Hi Mark,

With all due respect, from what I have read, I do not see how SPRING, or the authors of the network programming draft are interpreting the "intent" of the text in RFC8200. The text as written is very clear; there is no interpretation needed other than reading the plain English which clearly says the node identified in the Destination Address field of the IPv6 header may process, insert, or delete Extension headers (other than Hop-by-Hop Options header). It seems to me to set a very bad precedence if we now expect non-authors of an original Internet standard to have to interpret the intent of the original authors rather than simply read the text as published, especially in the case of an Internet standard.

Respectfully,

Jim
-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mark Smith
Sent: Friday, March 06, 2020 1:32 AM
To: bruno.decraene <bruno.decraene@orange.com>
Cc: Fernando Gont <fgont@si6networks.com>; SPRING WG List <spring@ietf.org>; 6man@ietf.org; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Who is the design ultimate authority over IPv6? (Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming)

On Thu, 12 Dec 2019 at 05:37, <bruno.decraene@orange.com> wrote:
>
> Fernando,
<snip>
>
> - Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others.  And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated.

The final interpretation and intent of text in RFC8200 should be up to 6man, not SPRING, when there is ambiguity and dispute, as 6man is the ultimate design authority for IPv6.

RFC5704, "Uncoordinated Protocol Development Considered Harmful":

" In particular, the
   IAB considers it an essential principle of the protocol development
   process that only one SDO maintains design authority for a given
   protocol, with that SDO having ultimate authority over the allocation
   of protocol parameter code-points and over defining the intended
   semantics, interpretation, and actions associated with those code-
   points."

IETF WGs would qualify as standards development organisations.

Those of us in 6man during the clarifications in this area of RFC8200 know the intent. It was specifically about modification of the EH chain, and was in response to the 'draft-voyer-6man-extension-header-insertion' Internet Draft.






> - Why have _you_ filled an errata against RFC 8200, in order to change 
> the technical content of this section, if you don't agree that one may 
> red " Destination Address field of the IPv6 header" as the IPv6 
> address present in the Destination Address field of the IPv6 header 
> been received by the End node (or even sent by the source node)
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> rfc-editor.org%2Ferrata%2Feid5933&amp;data=02%7C01%7Cjames.n.guichard%
> 40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=bybICm4YFIPalNf
> qYea%2FEGXVl5sYj6cRSd0VXZsnpww%3D&amp;reserved=0
>
> > > At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".
> >
> > No, I argue that there is not.IN fact, I argue that folks have been 
> > following that strategy for way too long, and that's quite frustrating.
> >
> >
> >
> > > Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.
> >
> > The quoted text is from RFC8200. In the context of RFC8200 the 
> > Destination Address can only contain the ultimate destination of the 
> > packet. Where's the ambiguity?
> >
> > And let me ask you, as chair, another question, that will lead you 
> > to the same place: is IPv6 and end to end protocol?
>
> That's not a question for a spring chair to answer.
> I'm reading the sentence in RFC8200. If we can't agree on the meaning of this explicit sentence, I don't think that discussing philosophical r religious question is going to help.
>
> > The fact that I may claim that RFC8200 contains a receipe for BBQ 
> > does not actually mean that that's the case.
>
> You do realize that your above sentence also applies to yourself? So how is this helping to progress?
> Can we please focus on the RFC8200 sentence?  I'm really trying to understand your point.
> Let's stick to the texts of documents.
>
>
> >
> > > I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.
> >
> > For the record, I think this is a major issue that should be cleared 
> > before it can be claimed that there is consensus to request 
> > publication of this document.
>
> OK, this is recorded.
> >
> >
> > >
> > >> does not specify any routing header type, and hence the meaning 
> > >> is unambiguous (there's no destination other than the final 
> > >> destination of the packet).
> > >>
> > >> This is of course in line with IPv6 being and end-to-end 
> > >> protocol, and crucial for other related mechanisms to work as 
> > >> expected (such as IPsec AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.
> > >>
> > >> So, in order to proceed with the document, there are multiple 
> > >> options
> > >> forward:
> > >>
> > >> 1) Just remove the corresponding text/behavior
> > >
> > > That is indeed one option. But as of today, this is not my assumption.
> > >
> > >> 2) Implement a similar mechanism in an RFC8200-compliant manner 
> > >> (e.g.,
> > >> re-encap)
> > >
> > > SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
> > > We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.
> >
> > It's about SRH removal, which is also forbiden by RFC8200.
> >
> >
> >
> >
> > >> 3) Do the necessary standards work to update RFC8200, such that 
> > >> it allows this sort of behavior, and only ship the 
> > >> network-programming draft for publication when at least 6man has 
> > >> consensus to proceed on that path.
> > >
> > > Not the preferred path as of today.
> >
> > Yes, it should be evident that it seems the preferred path has been 
> > (starting with EH insertion at the time) to circumvent existing 
> > specifications.
> >
> >
> >
> > >
> > >> P.S.: I will go through the document once again... but the same 
> > >> reasoning should be applied to any EH-insertion/removal at a 
> > >> place other than the source of the packet or its final destination.
> > >
> > > It looks to me that SRH insertion and SRH removal are to be treated differently.
> >
> > I don't see how or why.
>
> SRH insertion is done by a node, on the path, which is not the destination of the IPv6 addresses.
> SRH removal is done by a node which is receiving the packet because it's IPv6 address is in the destination of the IPv6 packet.
>
> > Both violate the same requirement in RFC8200.
>
> We are not having a conversation, so let's not repeats the same point again and again.
>
> Your opinion has been noted. So does opinions on this same point expressed by other wg participants.
>
> >
> >
> >
> > 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.
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fspring&amp;data=02%7C01%7Cjames.n.guic
> hard%40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=scW9s5WS7z
> 1ndZyX3iYNT4ktjv9HcmXOQzuS47rQCWY%3D&amp;reserved=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C3a9e583a99324ab04a0708d7c19825be%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637190731541021508&amp;sdata=YfIWJd%2FvZpVd1c%2BNukB4O5YmBVZrx2oAmW1wv7JE9PE%3D&amp;reserved=0
--------------------------------------------------------------------