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:44 UTC

Return-Path: <fgont@si6networks.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 C7A923A0E5F; Thu, 27 Feb 2020 14:44:15 -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=unavailable 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 7yluStZMnPql; Thu, 27 Feb 2020 14:44: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 C35693A0E5A; Thu, 27 Feb 2020 14:44: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 3011780A41; Thu, 27 Feb 2020 23:44:08 +0100 (CET)
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Suresh Krishnan <suresh.krishnan@gmail.com>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>, 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> <CAJE_bqf8EBWxkkgtJj5RrKPR_z4GsZV888cUfZ_iigVXy+7nHw@mail.gmail.com> <D7107A83-42A7-4F14-B62E-E45EB78F680F@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <10c1f886-7c77-478a-ed3d-eb2cdc3cd2db@si6networks.com>
Date: Thu, 27 Feb 2020 19:43:25 -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: <D7107A83-42A7-4F14-B62E-E45EB78F680F@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IAhe-tpEqFRfOHYQu48psEI7owo>
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 22:44:23 -0000

On 27/2/20 19:34, Suresh Krishnan wrote:
> Hi Jinmei,
> 
>> On Feb 27, 2020, at 5:18 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>
>> At Thu, 27 Feb 2020 21:29:24 +0000,
>> Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
>>
>>> 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.
>>
>> Please see my response to my own message.  Yes, purely "literally", it
>> could read that way (it's amazing human-written text can be always
>> ambiguous to some extent, no matter how hard we try to clarify it),
> 
> Yes, this is unfortunate. We ended up strengthening some constraints while leaving some others open. While I would (and do) interpret things exactly as you did, it is impossible to determine after the fact if a different text formulation would have gotten consensus. What we have is the text of RFC8200.

That's why we have erratas. The intent of RFC8200 is very clear. And I'm 
not sure how, having being involved in such discussion, you question the 
intent.

And if you don't, what would be your argument to process the errata I've 
submitted in any other way than "Verified".



>> We should have known this change
>> would make the SRv6-style insertion/deletion a violation of the RFC
>> even more clearly than RFC2460 at that time, and that's why we needed
>> that discussion.
> 
> Just so we are clear, SRv6 is defined in draft-ietf-6man-segment-routing-header-26 and it does not have anything about header insertion. Some earlier versions of the draft did and I was clear that it needed to be removed for it to progress from 6man. The authors removed the insertion mode from the draft.

No, we are not clear: PSP does extension header removal.


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