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

otroan@employees.org Fri, 06 December 2019 08:34 UTC

Return-Path: <otroan@employees.org>
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 970D512022D; Fri, 6 Dec 2019 00:34:53 -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, SPF_HELO_NONE=0.001, SPF_PASS=-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 vZnw6BxO2B3A; Fri, 6 Dec 2019 00:34:52 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F6E12000F; Fri, 6 Dec 2019 00:34:52 -0800 (PST)
Received: from astfgl.hanazo.no (77.16.49.136.tmi.telenormobil.no [77.16.49.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 9016B4E11AC6; Fri, 6 Dec 2019 08:34:50 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id DA4F32519094; Fri, 6 Dec 2019 09:34:46 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: otroan@employees.org
In-Reply-To: <20191205222740.GA9637@ernw.de>
Date: Fri, 06 Dec 2019 09:34:46 +0100
Cc: Fernando Gont <fgont@si6networks.com>, rtg-ads <rtg-ads@ietf.org>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.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>
To: Enno Rey <erey@ernw.de>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/_vdYPBSw_kXIQYrof8GVjs6UerE>
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 08:34:53 -0000

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