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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 28 February 2020 01:47 UTC

Return-Path: <brian.e.carpenter@gmail.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 0D3523A0BC1; Thu, 27 Feb 2020 17:47:36 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 4aXo-lznq_Hs; Thu, 27 Feb 2020 17:47:34 -0800 (PST)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6532B3A0BBC; Thu, 27 Feb 2020 17:47:34 -0800 (PST)
Received: by mail-pg1-x536.google.com with SMTP id a14so623277pgb.11; Thu, 27 Feb 2020 17:47:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bkt6xi40asfVKI1SCb97+L0MWxAq+CmTQ8KrBhfMZqg=; b=B8Yh0Z7NMnStNxJPG9ySJZDr6/5uCF3By92GJlQza0q1DI84Hnb9OhULx1r4EFftdV iswYW5ljj+p97GI3a3yzWTeBC4e8F5y5BvrpNagniBq1+DvAukOMxKpxptwGMKBkKiFs uwYw9uwTVF5AXWRsB54eoQnfJgALb+vJLf3uIlhIySXXTs13q91DP5Nxggq9SM8pUVgc bC8FMVhB4IsoUybUQfx4cynpi0JwIBlA1oxCvTinWVI4eKALkpJ83P7kou0vUw+RqhLm bkd5TdTBHkb0VaKQNOQMLQd8z2z5mUcWjeHS/TaVf/6VXbGNpiy7R3L7r2rqRW+05Lkg 9Vqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bkt6xi40asfVKI1SCb97+L0MWxAq+CmTQ8KrBhfMZqg=; b=Q5RXNZQfU+Xa3RJrMwUtW9y6gBMZ/t9snzyN+mmaI5DZdV4t4EHD8OLFMAsNlexXCk uVQ5Yk/NlIDi14TCr33Cbw2iHDvQZUZQV8L9VJBqk/obgmrbHLTfSeg/mlCNIuVEo4ig hL7XHBWcLsWSjPjhEqtlhJvqEZH/FdVSqPp2dJNjpGuHqyZdzdHhyAWTqTwpTuf/Vgi0 n/if069d5Ihku7jvz+wdxZC1PoSGICqRx6oCmUOjzd6XtpI+jBGBahMVjQlaDxLQGbcT JZiYYt5gC85tYX6yPWTUsq492U8JVCA2/zd2TKpOc9TV9F3YfmYBTxdwGdBHVrA4iVdT c3Wg==
X-Gm-Message-State: APjAAAXv3ZEoFEBkuV94q86gUqmR2O7w7RDs1QJvPSRtfS8oMZcCiN93 3Yu8MAcbBb7iNett1HlQ+ho=
X-Google-Smtp-Source: APXvYqzOcH6mtsDkxM/srcbkje1vS68fiWU+Ho8zAWqf8Lrdws0sADGqGh6mkZI38BEM5IJwwk7hDw==
X-Received: by 2002:a63:b347:: with SMTP id x7mr2154288pgt.275.1582854453728; Thu, 27 Feb 2020 17:47:33 -0800 (PST)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id q66sm8949606pfq.27.2020.02.27.17.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 17:47:33 -0800 (PST)
Subject: "penultimate segment" [Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming]
To: Stefano Salsano <stefano.salsano@uniroma2.it>, "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>
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> <b693c244-95f9-473e-de21-166393280d18@gmail.com> <8a20c0e2-e651-0294-03c2-4b89c44549cc@uniroma2.it> <53226b1c-6ac5-24b0-4787-a7ccfd9723af@gmail.com> <ca499b84-70fa-febf-df99-b5d6cadbd493@uniroma2.it>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <aab4665c-b737-f5fa-f780-07432bb78c33@gmail.com>
Date: Fri, 28 Feb 2020 14:47:28 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <ca499b84-70fa-febf-df99-b5d6cadbd493@uniroma2.it>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Yo2Zo6O1k_-OwtzeVGNP9yd1LaY>
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, 28 Feb 2020 01:47:36 -0000

Stefano,

The problem is that the draft simply doesn't explain (or refer to an explanation) of what this "penultimate segment" is. There are at least three hypotheses which I suspect different people are using, leading to this endless dialogue:

1) It's a forwarding node, a.k.a. a router, that blindly follows the PSP instructions by removing an IPv6 header before forwarding the packet, completely against the text of RFC 8200.

2) It's a node that receives and terminates the packet, and then makes a new one with its own address as source and a new (ultimate) destination address, which doesn't happen to contain an SRH header at all.

3) It's an offload processor in the destination node, that removes some crud (the SRH header) before passing the packet up to the IPv6 stack in the host.

At the moment, a reader of the draft who is not familiar with the details of at least one SRH implmentation cannot decide which of these hypotheses is correct.

Despite numerous requests, and several new versions, the draft still leaves this mystery intact, and is therefore simply not ready for the IESG.

So I repeat my request for the draft to explain what it means by "pop" and by "penultimate segment". If it turns out that we are in case 2) or 3) above, problem solved.

Regards
   Brian Carpenter

On 28-Feb-20 00:42, Stefano Salsano wrote:
> Brian,
> 
> Il 2020-02-27 03:29, Brian E Carpenter ha scritto:
>> Stefano,
>> On 27-Feb-20 14:42, Stefano Salsano wrote:
>>> Il 2020-02-27 02:14, Brian E Carpenter ha scritto:
>>>> Eric,
>>>>
>>>> On 27-Feb-20 12: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.
>>>>
>>>> The draft uses an undefined term ("pop") but it does *explicitly* state in a section called "Penultimate Segment Pop of the SRH":
>>>>
>>>>>> S14.4.      Remove the SRH from the IPv6 extension header chain
>>>>
>>>> If the word "penultimate" means what it means in every dictionary, this is in-flight removal of a header, and that is explicitly against RFC 8200, section 4, first paragraph below the diagram.
>>>
>>> Brian,
>>>
>>> "penultimate segment" means what it means in every dictionary, but this
>>> is not in-fligth removal of a header.
>>>
>>> When the packet has reached the "penultimate segment", it has reached a
>>> node "identified in the Destination Address field of the IPv6 header" as
>>> stated in RFC 8200, section 4, first paragraph below the diagram
>>
>> So in what sense is it penultimate (i.e. next to last)? If it has reached
>> the destination address, 
> 
> if the segment list is [S1, S2, S3] (where S1 is the first segment and 
> S3 the final destination)
> 
> S2 is the penultimate segment and the packet is received by S2 with 
> Destination Address = S2, I repeat that at the very end of section 3 of 
> RFC 8200 the "Destination address" is defined as "address of the 
> intended recipient of the packet (possibly not the ultimate recipient, 
> if a Routing header is present)"
> 
>> what happens next?
> 
> next the packet needs to be forwarded to S3
> 
>> I understand this for the following case, Ultimate Segment Pop, where the
>> text refers to processing the packet inside the receiving node. But the
>> text is completely lacking an explanation of the "penultimate" case,
>> and I found nothing about it in other SRH documents either.
>>
>> If I was writing code for this, I would have no idea how to generate a
>> test case.
>>
>> It's also obscure in the text how the node receiving a packet knows
>> which of "PSP, USP and USD flavors" applies. They don't seem to be marked
>> in the packet in any way.
> 
> it is not marked in the packet, likewise it is not marked in the packet 
> which SRv6 behavior is associated with a SID
> 
> Stefano
> 
>>
>> It seems to me that there is something blindingly obvious to SRH specialists
>> that is not stated at all in the draft, so the rest of us simply can't make
>> sense of it. It may or may not be a gap in the protocol, but there is
>> definitely a gap in the description.
>>
>>      Brian
>>
>>>
>>> Please note that at the very end of section 3 the "Destination address"
>>> is defined as "address of the intended recipient of the packet (possibly
>>> not the ultimate recipient, if a Routing header is present)"
>>>
>>> Stefano
>>>
>>>>
>>>> It's possible that "penultimate" means something else, e.g. "ultimate". I don't know. I've been puzzling over this language for months and it doesn't change. Maybe someone can finally post an explanation, but until they do, I don't see how any WG Chair could assert rough consensus. An obviously organised +1+1+1+1 campaign is not consensus. I don't know about you, but when I see a message whose only content is "+1" I just delete it.
>>>>
>>>>      Brian
>>>>
>>>>> Moreover, this 'proof' can technically wait until the IETF last call or even until the IESG ballot. I see little point in postponing the closing of the WGLC and advancing the document (of course, the document shepherd will need to carefully write the section about the rough WG consensus).
>>>>>
>>>>> Finally, as far as I know, at the IETF we have no religion... else we would still be running NCP or IPv4 :-)
>>>>>
>>>>> -éric
>>>>>
>>>>> -----Original Message-----
>>>>> From: ipv6 <ipv6-bounces@ietf.org> on behalf of Warren Kumari <warren@kumari.net>
>>>>>
>>>>> ...%<...%<....
>>>>>       
>>>>>       It doesn't really matter how many people say +1 for moving it forwards
>>>>>       -- if there are valid technical objections these have to be dealt with
>>>>>       - and I think that the relationship with RFC8200 falling into this
>>>>>       category...
>>>>>       
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>
>>>
>>
> 
>