Re: [spring] Question about SRv6 Insert function

Ole Troan <otroan@employees.org> Wed, 04 September 2019 06:58 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 C52E0120020; Tue, 3 Sep 2019 23:58:12 -0700 (PDT)
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 0SdIw801uWUZ; Tue, 3 Sep 2019 23:58:11 -0700 (PDT)
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 13EFC1200C4; Tue, 3 Sep 2019 23:58:11 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (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 66F814E11B54; Wed, 4 Sep 2019 06:58:10 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 7D63B1B72F1E; Wed, 4 Sep 2019 08:58:06 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <05b6474b-ecc2-fbf9-ac5e-d81157be8b90@gont.com.ar>
Date: Wed, 04 Sep 2019 08:58:06 +0200
Cc: Suresh Krishnan <suresh.krishnan@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <537C92D5-7355-45B5-8974-C74ED08B0E0F@employees.org>
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <18D85493-5FD4-4D26-B1A1-0931513DC847@gmail.com> <05b6474b-ecc2-fbf9-ac5e-d81157be8b90@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/DkWiHKLNYlt2oKNWDC4N7WtSdCE>
Subject: Re: [spring] 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: Wed, 04 Sep 2019 06:58:13 -0000

Fernando,

>>> Since there have been plenty of attempts to do EH insertion or
>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>> had consensus that EH insertion is not allowed, I think it would be
>>> bad, wastefull, tricky, and even dangerous to let a document go
>>> through the whole publication process, and just rely on the AD to
>>> keep the "DISCUSS" button pressed.
>>> 
>>> Put another way: what'd be the rationale for having a draft-ietf
>>> and have the corresponding wg ship the document with something that
>>> clearly goes against IETF consensus, and that the relevant AD has
>>> declared that wouldn't let pass?
>> 
>> In short, this is not the case. I am *not* the relevant AD for the
>> SRv6 Network Programming draft. If this document was in 6man I would
>> have flagged it much earlier like I did for the SRH draft.
> 
> Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for
> the spec that's being violated".
> 
> i.e., isn't there in the IETF process -- whether formal or informal --
> for this sort of thing to be flagged before documents get too far in the
> publication process?  ("Hey, this document in your area is actually
> breaking a spec of one of my wgs" sort of thing...)

I would prefer that we calmed down a bit on the protocol policing.

We know that header insertion breaks unsuspecting source hosts if done by the network.
It breaks (at least) PMTUD, ICMP errors and AH.

What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.
And some form of "doing on behalf of" is not necessarily problematic.

It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds.

Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.

Ole