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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 06 December 2019 15:09 UTC

Return-Path: <jmh@joelhalpern.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 586E61200B1; Fri, 6 Dec 2019 07:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 vOkGUcIrJPJo; Fri, 6 Dec 2019 07:09:32 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92781120020; Fri, 6 Dec 2019 07:09:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 47Twwr3lvVz6G8W0; Fri, 6 Dec 2019 07:09:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1575644972; bh=8h+7Cs82YCdJWyWBCSHMpzJBUd597NpOyNk75zvR+DA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qNscsvyREr23ppNidpiC/gN2uEYy1klDhxcTSS2aqLlEOvjvkFZ8/uePIP/BvXjxE oHE/AIS6ltGOSiYX02m9TiQ+06OSCW+NfCYu86R76TDtejsP14EcOzZiD6ULW4VVGr Og6IO+nFhk7SyZVv5KtvDr/rCSSiiX9UkBgu+GDQ=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [172.20.3.198] (unknown [45.225.71.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 47Twwq4jMZz6G8Vy; Fri, 6 Dec 2019 07:09:31 -0800 (PST)
To: otroan@employees.org
Cc: SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com> <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org> <bb3be82d-8ea7-6c29-ad0a-61b491ee997d@si6networks.com> <8A9BC46E-A018-41C0-BE47-4BABC30EFE79@employees.org> <20191205222740.GA9637@ernw.de> <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <430da027-07a7-42f9-60d0-bbb3f3306222@joelhalpern.com>
Date: Fri, 6 Dec 2019 10:09:29 -0500
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: <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/VNQRQRXTVB5lrrglWKMzRrX7kT8>
Subject: Re: [spring] 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: Fri, 06 Dec 2019 15:09:34 -0000

Ole, there is no IETF accepted definition of "limited domain".
There is no IETF rough consensus that it is sensible for us to 
standardize things for "limtied domains".
While there are standards that are designed for specific deployments, 
they do not to date use that as an excuse to violate existing RFCs.

Hence, as far as I can tell, the assertion that SRv6 is for limited 
domains does not justify or excuse violating RFC 8200.  And "I want to 
save some bytes", while very nice, is not a sufficient reason to violate 
an approved RFC, must less a Full Standard.

Yours,
Joel

On 12/6/2019 3:34 AM, otroan@employees.org wrote:
> Enno,
> 
>>>> comply with it. The onus is on them, not on us asking folks to comply
>>>> with existing standards.
>>>
>>> Yes, we have heard your position on this now.
>>> There is of course a lot more nuance to this argument.
>>
>> could you please explain said 'nuance' in more detail?
> 
> I could try, although I fear it will be a rehash of what has already been said many times already in this debate.
> 
> The IETF and the Internet architecture has a pugnacious relationship with packet mangling in the network.
> Steve embodied the Internet architeure principles in the IPv6 protocol suite.
> The IPv6 architecture consists only of routers and hosts (no middleboxes).
> Ensuring that routers would not need to process further into the packet than the IPv6 header, and ensure that extension header chains were expensive to parse in hardware. As well as requiring all implementations to support IPsec. Knowing that encryption was the only way to guarantee end to end transparency.
> 
> Now, contrast that with the "real world", I challenge you to find a service on the Internet where the packet isn't mangled in some way between the two end-points. Be that IPv4 or IPv6.
> 
> The problems with header insertion on the open Internet are well understood.
> 
> That's not what is being discussed here though.
> What is discussed here is what is acceptable to do within a limited domain.
> To packets that _you_ own, i.e. originate and terminate within a domain where you control all devices.
> 
> If I own and manage three routers, R1 -- R2 -- R3.
> You are saying that if R1 sends a packet to R3, it is not allowed to off-load some functions to R2?
> Going to be difficult to do stuff like service chaining then.
> 
> When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discussing now.
> 
> Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate.
> 
> My suspicion is that the header insertion argument is a straw-man.
> 
> Best regards,
> Ole
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>