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

Brian E Carpenter <> Thu, 27 February 2020 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2753A0EA5; Wed, 26 Feb 2020 18:30:04 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GBFCti5_gF_H; Wed, 26 Feb 2020 18:30:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CC293A0EA2; Wed, 26 Feb 2020 18:30:03 -0800 (PST)
Received: by with SMTP id b185so787354pfb.7; Wed, 26 Feb 2020 18:30:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PHCiXw80WBcmkzdbANPxSWIV83LPJYD52kR08cKp6tU=; b=YE+B61Uq6amh3gNYRtkucT2cRxnkhBF9xkDYui19Q0Zk7T7NjXFQTx8j1lk4ThIncs FQ/zp12PJVWK++4njrn3nxKbJ9BalmduJhQer8p5GW0JS/fDVKAyT+qQC/YSFyVfhJmJ acNflYgoHgzEytNf17zbVMuvo8UFc/bMxVbNUBwrZko/opxn0hHx2dwYzBMbIsPu/iuo 5wSGIZ0PkNnsEegNzPh2+uEvorkqzXkp+OT168Qzj7UZAuAFnbamW9w8AgPG7rcuyJpP TJZKOJd3I0NgPydKJjEYJgmz/oHb1TGb50S8Za4ErigrRcSqxcJpXdjzXylbjpqNf94F CxCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=PHCiXw80WBcmkzdbANPxSWIV83LPJYD52kR08cKp6tU=; b=UDVPk4v66GgkOZ0LN5C/VhExGsEJUhlQasJoRsWCWkPunsLIOyP57MnSF8qrTc9LkD dhAa/vQA7CIBR4124IA/bNfRCEVCAtAw2dewoV4gRKgI7wpLogmdg0J/8yolWupata2S /ZGzp4XpHUWgzSHmMJpsp3b6R8km6cNPcdG8dVDtGkwLZXBE+P77KGWuWhN16uJGjxPA AKSXBBTaaPUDrC8hREr8A1xi5/Lbo9azmZddF1Gd+xiuA1szhvS/7A+NU3EOkpJoD40c cNbsNhkddIEcrgUJzmHrfaFyH/bRMk5q6JbVawy2RBCpi3dTPArvQODTXCyX6IBx/txr jEtg==
X-Gm-Message-State: APjAAAW7FjpfZh0zDngFMMkKYrQFQdlif5g65Ax91BqaigpAuxzt0Gou DZOZn4zDWwue6Rs4MBIDfXQ=
X-Google-Smtp-Source: APXvYqyIHlLadq2uE/2HGr7A9FgiyA1sV3MLjOk0ZMDctK/sSizOH+bsCTgxDchDiA3CgdQaZ/B3SA==
X-Received: by 2002:a62:1883:: with SMTP id 125mr1736743pfy.166.1582770602374; Wed, 26 Feb 2020 18:30:02 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id u1sm4389065pfn.133.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 18:30:01 -0800 (PST)
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Stefano Salsano <>, "Eric Vyncke (evyncke)" <>, Warren Kumari <>, John Leddy <>
Cc: SPRING WG List <>, "" <>, Bob Hinden <>, "Zafar Ali (zali)" <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 27 Feb 2020 15:29:56 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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 02:30:05 -0000

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, what happens next? 

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


> 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 <> on behalf of Warren Kumari <>
>>> ...%<...%<....
>>>      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
>>> Administrative Requests:
>>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> Administrative Requests:
>> --------------------------------------------------------------------