RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

<> Thu, 27 February 2020 08:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 836793A1544; Thu, 27 Feb 2020 00:41:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r1z3H8YqA-Dc; Thu, 27 Feb 2020 00:41:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B48643A1541; Thu, 27 Feb 2020 00:41:22 -0800 (PST)
Received: from (unknown [xx.xx.xx.71]) by (ESMTP service) with ESMTP id 48SmNd2VThz1ylX; Thu, 27 Feb 2020 09:41:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1582792881; bh=ky5vIDB0wfH/5rrcVMBTxH2bSGDtGYTTxi6Sgmhrp1I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jnzYdrZAhVRwrIFd3vV4Zjt3QFCdTRNa0dVrcAvgEigSybs1m1QudfoERhfwinXbk aDN3u40C2ogie6yyRQhuga1K0d1kzpC/MfkRpyxo5jRlnEfl2pWl+pOe0FA2Iqpugd WxPxCcPGrJpWILyvJCvgJ996CtwCLybESCti4n7O3aaaqjqE/fdhWzDAlPivu8lB2S BE5jXyD4ihX44AQx8+Bb7RMHjeT1K9uNtuiN4JlqdB3C44xgqPJYQR/QVtvY0uysI0 XMUL01zOoLcTsuPjWq02r4Y6frfoL5maW7bWWud7ZyZB4bh+NhGKJaTz4X3x/BVH0U kqKw0riZexZkA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by (ESMTP service) with ESMTP id 48SmNd0hPCzFpWX; Thu, 27 Feb 2020 09:41:21 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 27 Feb 2020 09:41:20 +0100
From: <>
To: Fernando Gont <>, "Eric Vyncke (evyncke)" <>, Warren Kumari <>, "John Leddy" <>
CC: SPRING WG List <>, "" <>, "Bob Hinden" <>, "Zafar Ali (zali)" <>
Subject: RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Topic: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AQHV7Ncwp8+eLLDfG0CKhJJgauqVq6gt2IkAgABUpgD//+XygIAAmzhQ
Date: Thu, 27 Feb 2020 08:41:20 +0000
Message-ID: <10919_1582792881_5E5780B1_10919_216_1_53C29892C857584299CBF5D05346208A48DB590F@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 08:41:25 -0000


> -----Original Message-----
> From: ipv6 [] On Behalf Of Fernando Gont
> Sent: Thursday, February 27, 2020 12:45 AM
> Hello, Eric,
> On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
> > Writing this without any hat,
> >
> > Please note that on the logical side, it still have to be "proven" that this idea is strictly forbidden by RFC 8200.
> Here's the proof part:
> 1) Isn't IPv6 end to end?
> 2) How do core components of IPv6, such as AH and PMTUD work in the
> present of intermediate nodes that can add and/or remove arbitrary
> extension headers?
> It should be clear from the above that EH insertion/deletion is forbidden.

This draft does not propose that intermediate node add extension header. 
 - If this is not clear to you, please read the draft.
 - If it's clear, please let's stick to technical comment on _this_ draft. Bringing irrelevant points to the discussion is really not helping (both the discussion  and the argument).

This draft does not propose that intermediate node add/or remove arbitrary  extension header.

This draft, and more specifically the PSP flavor [1], is about removing the SRH header by an SR EndPoint.
- with regards to PMTUD, can you clarify how reducing the size of the packet break PMTUD? And if there is an impact, let's remember that this is the source of the packet which instruct the SR EndPoint to remove the SRH. 
- with regards to AH, the SRH specification explicitly states that the use of SRH with AH by an SR source node is _not_ defined [2]. I don't think you can break something which is not working/defined. That been said, as an individual contributor, I think the PSP section should explicitly raise that point.


> Since this topic has been brought up again and again, I have submitted
> an errata to RFC8200 which clarifies the intended behaviour:
> *
> (that's what Errata's are for, after all... and it should be clear that
> the EH processing part, overall, needs improvements).

Again, thank you for that, I believe this is useful.
But while this errata is not reviewed and accepted, RFC 8200 stands as is.

> Thanks!
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------


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.