Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Fernando Gont <fgont@si6networks.com> Tue, 10 December 2019 23:25 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 94274120255; Tue, 10 Dec 2019 15:25:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 0hO_v6iZxJj7; Tue, 10 Dec 2019 15:25:46 -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 95681120220; Tue, 10 Dec 2019 15:25:46 -0800 (PST)
Received: from [192.168.1.7] (unknown [181.113.152.47]) (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 78B0C85F93; Wed, 11 Dec 2019 00:25:41 +0100 (CET)
To: bruno.decraene@orange.com
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, rtg-ads <rtg-ads@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, Suresh Krishnan <Suresh@kaloom.com>, Robert Raszuk <robert@raszuk.net>
References: <f2a0ad13-0eba-6f5a-1d3c-e45e2780f201@si6networks.com> <D666EA6E-E8E9-439A-9CDE-20857F03CB65@employees.org> <4255AD3B-379C-45BF-96E1-D3D9141A684F@liquidtelecom.com> <d59de54e-c7f8-be67-1e77-b051735d40a6@gmail.com> <3bce7b18-ea45-d29f-5dfb-1d3258b07d1e@si6networks.com> <c6e1f690-b0bf-9f45-8fa7-92ed182c5b04@gmail.com> <a2cc5cbd-ac06-e193-307c-3ffe5b21b0b1@si6networks.com> <80A78F48-9802-4DA9-B264-1A8920C1DDF9@kaloom.com> <c727fb5e-015d-90e2-9860-6c48ce021ac4@si6networks.com> <CAOj+MMEyMDHULL7Pr=QmucTJy9b=3ph9TgTZ7koi9BBLkFCJ6g@mail.gmail.com> <bb767aff-8737-a749-2f99-ac350f66def5@si6networks.com> <CAOj+MMEjzxrEbmKbUn11EsTSnVOZC0cKZhAeXapV2vW++g0ZdA@mail.gmail.com> <885c9ad6-ddd2-392a-7e9f-722509753e2d@si6networks.com> <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Fernando Gont <fgont@si6networks.com>
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <5b0f37d2-56a3-5f7f-ab29-7d6ebc2367d5@si6networks.com>
Date: Tue, 10 Dec 2019 18:25:21 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <27448_1575983799_5DEF9AB7_27448_30_1_53C29892C857584299CBF5D05346208A48D245CD@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/yspxW_SZbr7-GsJaAW3dadux3j8>
Subject: Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))
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: Tue, 10 Dec 2019 23:25:48 -0000

On 10/12/19 08:16, bruno.decraene@orange.com wrote:
> Fernando,
> 
>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
>> Sent: Sunday, December 8, 2019 1:55 AM
>>
>> On 7/12/19 15:40, Robert Raszuk wrote:
>>> Hi Fernando,
>>>  
>>>
>>>     The online possible instantiation of "Destination Address" as in RFC8200
>>>     is the final destination of the packet.
>>>
>>>
>>> No. That is incorrect. 
>>>
>>> Hint: Please read carefully RFC2473. 
>>
>> If you think a document on tunnels rules how IPv6 operates, and its
>> end-to-endianness, then you have a huge problem reading specs.
>>
>> So I will not enter that game, because it would be accepting to be
>> mocked at.
>>
>> I'll wait for a few days for our INT AD's response (Suresh), a response
>> from the spring chairs (if any), and a response from the RTG AD(s).
> 
> I'm not sure what response to what question you expect from spring chairs.

A number og wg participants are letting the chairs and ADs aware that a
wg document contains an outright violation of an Internet Standard that
spring is not in a position of changing.

I deem that as a major issue, and I'm curious how you might possible
ignore it, declare consensus, and ship and request publication of this
document.


> 
>>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Fernando Gont
>>> Sent: Saturday, December 7, 2019 6:43 PM
>>>  The online possible instantiation of "Destination Address" as in RFC8200 is the final destination of the packet.
> 
> It appears to me that, at minimum, multiple opinions have been expressed on this point, including from Suresh. So, assuming that by "online" you meant "only", the statement "only possible" seems excessive to me.

I ask again: please read RFC8200, and in the context of RFC8200, please
tell me what can be in the Destination Address other than the ultimate
destination of the packet.


Then, if you cannot come up with a good answer, then you might need to
accept that "Destination Address", in the context of RFC8200, is the
ultimate destination of a packet.

And, since we are at it, please let me know if IPv6 is and end to end
protocol. And, if it is, how does that e2e-ness work with inserting and
removing EHs on the path to the ultimate destination of a packet.

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