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

Fernando Gont <fgont@si6networks.com> Thu, 27 February 2020 22:01 UTC

Return-Path: <fgont@si6networks.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 1E2313A0CFB; Thu, 27 Feb 2020 14:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 w9ghCdHtKvKb; Thu, 27 Feb 2020 14:01:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAA83A0D01; Thu, 27 Feb 2020 14:01:12 -0800 (PST)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8B17680CD2; Thu, 27 Feb 2020 23:01:09 +0100 (CET)
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 神明達哉 <jinmei@wide.ad.jp>, Fernando Gont <fernando@gont.com.ar>
Cc: 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>
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9364A1C2@DGGEMM532-MBX.china.huawei.com> <4038_1582727829_5E568295_4038_168_1_53C29892C857584299CBF5D05346208A48DB381A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <8ca30058-b8cf-cba4-524d-99b34e2b01d6@gont.com.ar> <CAJE_bqebPnJUoSL0KYCabh9tY5iMSFmq_Cg=7oxy4xsrOjs9Zg@mail.gmail.com> <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <b8747668-8086-150b-7992-b5e92b498591@si6networks.com>
Date: Thu, 27 Feb 2020 18:57:29 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/1MYYDOhjGj75USTV5_sBAUxrmo4>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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, 27 Feb 2020 22:01:15 -0000

On 27/2/20 18:29, Ron Bonica wrote:
> Jinmei,
> 
> The current discussion is about Penultimate Segment Popping (PSP) (Section 4.16). Normally, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node decrements Segments Left and forwards the packet, with the Routing header intact. In PSP, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node removes the Routing header and forwards the packet, without the Routing header.
> 
> The question is whether PSP violates the following clause from Section 4 of RFC 8200:
> 
> "Extension headers (except for the Hop-by-Hop Options header) are not
>     processed, inserted, or deleted by any node along a packet's delivery
>     path, until the packet reaches the node (or each of the set of nodes,
>     in the case of multicast) identified in the Destination Address field
>     of the IPv6 header."
> 
> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet arrives at a segment endpoint, one of its addresses appears in the IPv6 Destination Address field.
> 
> At least one RFC contradicts this literal reading. Section 3.3.3.1.1.2 of RFC 4302 says that the payload length and next header fields of the IPv6 header are immutable. PSP would change both of these and break AH processing.

The intent is grasped in Appendix B of RFC8200:

    o  Clarified that extension headers (except for the Hop-by-Hop
       Options header) are not processed, inserted, or deleted by any
       node along a packet's delivery path.

We might have done a poor job polishing the text. That doesn't change 
anything. And that's what Errata's are for.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492