Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Fernando Gont <fgont@si6networks.com> Tue, 10 December 2019 23: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 BC2D7120255; Tue, 10 Dec 2019 15:22:26 -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=ham 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 5INXFR9P-zRM; Tue, 10 Dec 2019 15:22:23 -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 6AF7D120059; Tue, 10 Dec 2019 15:22:23 -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 014A486261; Wed, 11 Dec 2019 00:16:36 +0100 (CET)
To: bruno.decraene@orange.com, 'SPRING WG List' <spring@ietf.org>
Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <6c674995-8cc7-c024-4181-60b160910f75@si6networks.com> <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@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: <89402a30-129b-314f-90f1-ba6efcdd6a88@si6networks.com>
Date: Tue, 10 Dec 2019 18:16:13 -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: <29345_1576001884_5DEFE15C_29345_229_5_53C29892C857584299CBF5D05346208A48D250B7@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/_pZnTw_P6N6z8VuFxKuTVa2iuXU>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
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:22:27 -0000

Bruno,

On 10/12/19 13:18, bruno.decraene@orange.com wrote:
> Fernando,
> 
> Thank you for spelling out your comment, plus on the WGLC thread.
> More in-line
> 
>> Bruno,
>>
>> On 5/12/19 12:15, bruno.decraene@orange.com wrote:
>> [....]>
>>> This email starts a two weeks Working Group Last Call on
>>> draft-ietf-spring-srv6-network-programming [1].
>>>
>>>  
>>>
>>> Please read this document if you haven't read the most recent version,
>>> and send your comments to the SPRING WG list, no later than December 20.
>>>
>>>  
>>>
>>> You may copy the 6MAN WG for IPv6 related comment, but consider not
>>> duplicating emails on the 6MAN mailing list for the comments which are
>>> only spring specifics.
>>>
>>>  
>>>
>>> If you are raising a point which you expect will be specifically debated
>>> on the mailing list, consider using a specific email/thread for this point.
>>>
>>> This may help avoiding that the thread become specific to this point and
>>> that other points get forgotten (or that the thread get converted into
>>> parallel independent discussions)
>>
>> Penultimate Segment Popping describes/specifies the removal of a SRH at
>> a place other than the final destination of the packet.
>>
>> Such behavior violates RFC8200, which specifies:
>>
>    > 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.
>>
>> Note, of course, that the reference of "Destination Address" in RFC8200
>> is clearly the final destination of the packet -- for instance, RFC8200
> 
> I hear and can understand your reading of RFC8200.

Could you please check RFC8200, and tell me what other possible
interpretation of "Destination Address" you might have, in the context
of RFC8200.

RFC8200 does not even specify any routing header types. SO...where's the
ambiguity?



> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".

No, I argue that there is not. IN fact, I argue that folks have been
following that strategy for way too long, and that's quite frustrating.



> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.

The quoted text is from RFC8200. In the context of RFC8200 the
Destination Address can only contain the ultimate destination of the
packet. Where's the ambiguity?

And let me ask you, as chair, another question, that will lead you to
the same place: is IPv6 and end to end protocol?


The fact that I may claim that RFC8200 contains a receipe for BBQ does
not actually mean that that's the case.



> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

For the record, I think this is a major issue that should be cleared
before it can be claimed that there is consensus to request publication
of this document.



> 
>> does not specify any routing header type, and hence the meaning is
>> unambiguous (there's no destination other than the final destination of
>> the packet).
>>
>> This is of course in line with IPv6 being and end-to-end protocol, and
>> crucial for other related mechanisms to work as expected (such as IPsec
>> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.
>>
>> So, in order to proceed with the document, there are multiple options
>> forward:
>>
>> 1) Just remove the corresponding text/behavior
> 
> That is indeed one option. But as of today, this is not my assumption.
>  
>> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
>> re-encap)
> 
> SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.

It's about SRH removal, which is also forbiden by RFC8200.




>> 3) Do the necessary standards work to update RFC8200, such that it
>> allows this sort of behavior, and only ship the network-programming
>> draft for publication when at least 6man has consensus to proceed on
>> that path.
> 
> Not the preferred path as of today.

Yes, it should be evident that it seems the preferred path has been
(starting with EH insertion at the time) to circumvent existing
specifications.



>  
>> P.S.: I will go through the document once again... but the same
>> reasoning should be applied to any EH-insertion/removal at a place other
>> than the source of the packet or its final destination.
> 
> It looks to me that SRH insertion and SRH removal are to be treated differently. 

I don't see how or why. Both violate the same requirement in RFC8200.


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