Re: [spring] Non-final destination address (was Re: 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> Thu, 12 December 2019 00:22 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 13F911201DE; Wed, 11 Dec 2019 16:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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] 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 RMWzWVisFP2J; Wed, 11 Dec 2019 16:22:20 -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 E69741200FB; Wed, 11 Dec 2019 16:22:19 -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 2FABB82ABB; Thu, 12 Dec 2019 01:22:15 +0100 (CET)
To: Suresh Krishnan <Suresh@kaloom.com>
Cc: SPRING WG <spring@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.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>, Ole Troan <otroan@employees.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
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> <6bc831ce-326f-3648-6e6f-4c715b2a49ac@si6networks.com> <858E25C2-36FA-4E37-A70C-72D9DEA1BF3D@kaloom.com>
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: <4541b6ff-ce45-5839-32ee-3b52397126e5@si6networks.com>
Date: Wed, 11 Dec 2019 19:22:00 -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: <858E25C2-36FA-4E37-A70C-72D9DEA1BF3D@kaloom.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/h5irB0Tf7bKuMsAxFl8o9v66PhA>
Subject: Re: [spring] Non-final destination address (was Re: 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: Thu, 12 Dec 2019 00:22:23 -0000

On 11/12/19 19:04, Suresh Krishnan wrote:
> Hi Fernando,
>   Answer inline.
> 
>> On Dec 7, 2019, at 9:31 AM, Fernando Gont <fgont@si6networks.com> wrote:
>>
>> On 7/12/19 04:19, Suresh Krishnan wrote:
>>> (responding on spring mailing list)
>>>
>>> Hi Fernando,
>>>
>>>> On Dec 7, 2019, at 11:07 AM, Fernando Gont <fgont@si6networks.com
>>>> <mailto:fgont@si6networks.com>> wrote:
>>>>
>>>> On 6/12/19 23:47, Brian E Carpenter wrote:
>>>>> Again, comment at the end...
>>>>> On 07-Dec-19 14:37, Fernando Gont wrote:
>>>>>> On 6/12/19 22:15, Brian E Carpenter wrote:
>>>>>> [...]
>>>>>>>
>>>>>>>> and if such a thing is required, an update to RFC8200 should be done.
>>>>>>>
>>>>>>> Why does that follow? Alternatively,
>>>>>>> draft-ietf-spring-srv6-network-programming could acknowledge that
>>>>>>> it deviates from RFC8200.
>>>>>>
>>>>>> You can deviate from s "should", not from a "must". This is an outright
>>>>>> violation of a spec, rather than a mere "deviation".
>>>>>>
>>>>>>
>>>>>>> Whether that's acceptable would be a question for the IETF Last
>>>>>>> Call rather than any single WG.
>>>>>>
>>>>>> I would expect that a WG cannot ship a document that is violating an
>>>>>> existing spec, where the wg shipping the document is not in a position
>>>>>> of making decisions regarding the spec being violated.
>>>>>>
>>>>>> That would be like a waste of energy and time for all.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> At the moment, the draft only mentions RFC8200 in a context that
>>>>>>> discusses neither insertion nor removal of extension headers, which
>>>>>>> is beside the point. Like draft-voyer, if it describes a violation
>>>>>>> of RFC8200, shouldn't that be explicit in the text?
>>>>>>>
>>>>>>> There's a lot of jargon in
>>>>>>> draft-ietf-spring-srv6-network-programming. I can't tell from the
>>>>>>> jargon whether "insert" means "insert on the fly" and whether "Pop
>>>>>>> the SRH" means "delete on the fly". Should those terms be clarified
>>>>>>> before the draft advances?
>>>>>>
>>>>>> Well, if it's not clear to you, it would seem to me that the simple
>>>>>> answer would be "yes".
>>>>>
>>>>> But if "insert" refers to the encapsulating node at the SR domain
>>>>> ingress, it's no problem, and if "pop" simply means doing normal
>>>>> routing header processing, it's no problem. It simply isn't clear in
>>>>> the text, at least not clear to me.
>>>>
>>>> The fact that a folk that has been deeply involved with IPv6 cannot
>>>> unequivocally tell what they talking about should be an indication with
>>>> respect to how ready the document is to be shipped.
>>>>
>>>> (pop when you are the destination but SL!=0 is essentially 'in the
>>>> network removal’)
>>>
>>> It is not obvious to me why you think this is a violation of RFC8200
>>> though it is possible that I misread your comment. The relevant text I
>>> am looking at is
>>>
>>> "  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.”
>>>
>>> which seems to permit it. Can you please clarify where there is a
>>> violation?
>>
>> In the context of RFC8200, where the text you have quoted is present,
>> can you tell me which address other than that of the final destination
>> can be in the Destination Address of the packet?
> 
> RFC8200 *clearly* speaks about the possibility of the destination address not being the ultimate recipient in the presence of a Routing Header. This is from Section 3 defining the Destination Address as "128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present).”

Section 4.4 says:
   The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.

(contrasts this to the statement with eh insertion/removal/processing)

While there could have been better use of terms, do you really think
that RFC8200 is allowing EH insertion/removal at waypoints? Or do you
think that, at best, the wording in RFC8200 could have been better?

How would eh insertion at waypoints work with AH, Path-MTU Discovery,
etc., etc.,etc?

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