Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Thu, 05 September 2019 14:42 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 7F90A120915; Thu, 5 Sep 2019 07:42:39 -0700 (PDT)
X-Quarantine-ID: <Hne8boR8_o69>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 Hne8boR8_o69; Thu, 5 Sep 2019 07:42:37 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 299DB12095D; Thu, 5 Sep 2019 07:42:37 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1i5sxs-0000EqC; Thu, 5 Sep 2019 16:42:24 +0200
Message-Id: <m1i5sxs-0000EqC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: Ole Troan <otroan@employees.org>
Cc: "spring@ietf.org" <spring@ietf.org>
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <BYAPR05MB54637FEAE1518F83977D274FAEB80@BYAPR05MB5463.namprd05.prod.outlook.com> <538732E2-915B-4952-A439-F4678FCC21B2@employees.org> <4c6b2456-db05-0771-5b98-bfd9f07b220b@si6networks.com> <34AB9F0F-614B-45C2-BD84-7DD53A1D5188@employees.org> <ea9557e5-9025-db78-8862-18454dd549c3@joelhalpern.com> <5200FFA0-E2F1-4491-8D06-0DC6BF87F77A@employees.org>
In-reply-to: Your message of "Thu, 5 Sep 2019 15:34:49 +0200 ." <5200FFA0-E2F1-4491-8D06-0DC6BF87F77A@employees.org>
Date: Thu, 05 Sep 2019 16:42:13 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/VKK3plTs7UAIvdwDghOnOR8cEAE>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)
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, 05 Sep 2019 14:42:48 -0000

>As far as I know, but I'm trying to stay away from the actual proposals and ar
>gue this generally, no-one is proposing to update the RFC8200 header insertion
> text.
>What people are proposing are for specific domains. And given that, I believe 
>people need to argue the technical merits of those specific proposals.
>As opposed to throwing the "law book" around.

Maybe I missed it somewhere, but why is it so hard to publish an RFC that
updates RFC 8200? Is this a process failure that we cannot update an Internet
Standard?

One thing is that firewalls and other middle boxes routinely violate RFC 8200
by looking beyond the IPv6 header. It is bad to have specs that do not
reflect reality. I'm not aware of wide spread middle boxs that modify IPv6
packets, though there is some amount of NAT66.

In general, inserting new EHs is bad for the various reasons brought up in the
past. However, SR is a special case. And there is no reason we can't make an
exception for a specific situation.

However, somebody reading the IPv6 specs should not have an unexpected
surprise of reading RFC 8200 and then later finding that some nodes violate it
due to a completely unrelated RFC.

It is not that much work to add a section that officially updates RFC 8200.