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

<bruno.decraene@orange.com> Thu, 27 February 2020 11:53 UTC

Return-Path: <bruno.decraene@orange.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 869CD3A0A0A; Thu, 27 Feb 2020 03:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 Rifo-W7iZTft; Thu, 27 Feb 2020 03:53:27 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9552D3A0A08; Thu, 27 Feb 2020 03:53:27 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 48SrfG1bGzz8t8n; Thu, 27 Feb 2020 12:53:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582804406; bh=o1WHTi3nIBbjOs/vr4joL2dH3uFlPT26i9n/8x+dNu4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=XO+5A82G5k8TqOXqsZYwbaz58CV2Yp0xPmfdH/RnnOP41Lc2xkh6R5zEIm3pR9ohd 4VjiZJi6bJp8Bp9DlMHWbsjbC1tUZo/nDFDel7s0li529olPP3tvQ498FqAeALgMHW Z1T8LMCm43ETvLdL9WmXvTEr1n6Vr0lxL0mhMGh6363Bzgp/PltC6I9Vh+lZNjUVEH VGYSFkEXyn5XNw+TPmZE2yOcrqCiiY3ACxR6mbq7j1Bl2IY0iCCSLkETX+sM1Pm1Dk ctq2usO2IQMC3n+0jOpAM7IIf9NGE6EGLq/Wv5TDjPAlVMsX8TMd/QwzQ1awxVQ4Lx 62ite0VMoA27w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48SrfF6skwzCqkZ; Thu, 27 Feb 2020 12:53:25 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 27 Feb 2020 12:53:25 +0100
From: <bruno.decraene@orange.com>
To: Fernando Gont <fgont@si6networks.com>, "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>, Warren Kumari <warren@kumari.net>, "John Leddy" <john@leddy.net>
CC: SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "Bob Hinden" <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
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: AQHV7U1NZ+bRbaP7BEi4D3jb6AgA/qgu5PFQ
Date: Thu, 27 Feb 2020 11:53:24 +0000
Message-ID: <32422_1582804406_5E57ADB5_32422_326_1_53C29892C857584299CBF5D05346208A48DB6132@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <F88E3F76-DD4B-4807-A458-85FABFF20D96@gmail.com> <5D218BFB-0D6F-4F7D-858F-B571A67DC47F@leddy.net> <CAHw9_iJ_ipEvU0NUx44XbK0_DrLe_GRw6G=m+chK4wZcRP8BMg@mail.gmail.com> <ACA082A4-BC78-4C63-9F91-5C9A44F47642@cisco.com> <8abfd5a1-e806-3598-c389-8214b3d09447@si6networks.com> <10919_1582792881_5E5780B1_10919_216_1_53C29892C857584299CBF5D05346208A48DB590F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <d37ff964-aa4f-388b-5199-66428d49336c@si6networks.com>
In-Reply-To: <d37ff964-aa4f-388b-5199-66428d49336c@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/QYhLV3VfJVOLDzBN_rZUvIRpJ40>
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: Thu, 27 Feb 2020 11:53:30 -0000

Fernando,
 
> From: Fernando Gont [mailto:fgont@si6networks.com] 
> 
> Bruno,
> 
> On 27/2/20 05:41, bruno.decraene@orange.com wrote:
> > Fernando,
> > 
> >> -----Original Message-----
> >> From: ipv6 [mailto:ipv6-bounces@ietf.org] 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.
> 
> What is this:????

This is _removal_ not _addition_.
 
> 4.16.1.  PSP: Penultimate Segment Pop of the SRH
> 
    > The SRH processing of the End, End.X and End.T behaviors are
    > modified: after the instruction "S14.  Update IPv6 DA with Segment
    > List[Segments Left]" is executed, the following instructions must be
    > executed as well:
> 
>   S14.1.   If (Segments Left == 0) {
  > S14.2.      Update the Next Header field in the preceding header to the
                 > Next Header value of the SRH
  > S14.3.      Decrease the IPv6 header Payload Length by the Hdr Ext Len
                 > value of the SRH
  > S14.4.      Remove the SRH from the IPv6 extension header chain
  > S14.5.   }
> 
> 
> Isn't this having the penultimate segment fo a packet removing an 
> extension header for a packet whose Destination Address is not even it's 
> own?

 So you seem to agree that this is _removal_ not _addition_
The Destination Address is its own. This is even your summary in your below sentence "the router was the DA of the packet"
 
> Doesn't this read a bit as "the router was the DA of the packet, after 
> you change the DA to that of the next waypoint, if you realize Segments 
> Left == 0, remove the SRH"?
> 
> (which does not even comply with the now infamous "interpretation" of 
> RFC8200 that if you are the DA, you can add/remove EHs.

It's clear that there are different interpretations of RFC 8200. I really wish there were not. One option is to ask the IESG to review that point and make the call. 
 
 
> >   - 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.
> 
> Seriously?

? Please be more specific.

I thought that:
a) this email thread is about PSP
b) in the draft, PSP is about removing the SRH header by an SR End Point

Please clarify on which point we are not in sync


> 
> > - 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.

I note that you do not clarify that point.

> > - 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]. 
> 
> Do you understand that AH should be usable for all IPv6 traffic?

My sentence was purposely written as a quote of  https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-24#section-7.5

"   The use of SRH with AH by an SR source node, and processing at a SR
   segment endpoint node is not defined in this document.  Future
   documents may define use of SRH with AH and its processing."

That draft, hence above text, has been approved by the 6MAN WG and the IESG.
It you have an issue with it, please raise it on the 6MAN WG in a relevant thread.

As of today, we are discussing draft-ietf-spring-srv6-network-programming


> 
> 
> [....]
> >> (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.
> 
> The errata is a clarification, not a change.

That is the claim of the author of the errata.
My understanding of the errata process is that point remains to be decided:

" Status: Reported"
https://www.rfc-editor.org/errata/eid5933

" Reported 	The erratum has been reported but is unverified."
https://www.rfc-editor.org/errata-definitions/

--Bruno

> Of course RFC8200 stands: 
> EHs are not deleted or added en route to destination.
> 
> 
> 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.