Re: [spring] Question about SRv6 Insert function

Fernando Gont <fgont@si6networks.com> Sat, 07 September 2019 22:02 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 3586E1201C6; Sat, 7 Sep 2019 15:02:35 -0700 (PDT)
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 KsyC7ppyjfPa; Sat, 7 Sep 2019 15:02:33 -0700 (PDT)
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 9E12412018D; Sat, 7 Sep 2019 15:02:32 -0700 (PDT)
Received: from [192.168.1.14] (ppp-94-69-228-20.home.otenet.gr [94.69.228.20]) (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 54FBC86389; Sun, 8 Sep 2019 00:02:29 +0200 (CEST)
To: Ole Troan <otroan@employees.org>
Cc: "Darren Dukes (ddukes)" <ddukes@cisco.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>, Suresh Krishnan <suresh.krishnan@gmail.com>, Fernando Gont <fernando@gont.com.ar>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.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> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <b83a7060-0517-c6ad-f6b0-bc9e61e4667f@si6networks.com> <01D79129-8CAC-49C3-A7EC-C37F935B11B1@cisco.com> <eb05ad28-4fb1-c438-4655-6c5a0455b029@si6networks.com> <BB439981-F078-4833-98BF-7779E1D03930@cisco.com> <f27d975b-b48d-377b-9a7d-aba63b5c77e7@si6networks.com> <DM6PR11MB260302DC79D7E7BF6367B74AC8BA0@DM6PR11MB2603.namprd11.prod.outlook.com> <1f697fd6-dc77-b8dd-15fb-be23b3c296a4@si6networks.com> <2C6D1E3F-5271-4516-94E6-F08974501DD0@employees.org>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <0ac79226-906b-6c11-5c6b-7cb7b8bcc336@si6networks.com>
Date: Sun, 8 Sep 2019 01:00:41 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <2C6D1E3F-5271-4516-94E6-F08974501DD0@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/OCUgpUcShKx9AAH62l1Fq9-X4es>
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: Sat, 07 Sep 2019 22:02:35 -0000

On 8/9/19 00:32, Ole Troan wrote:
> Fernando,
> 
>>> The takeaway I attempted to highlight is that there is in fact
>>> agreement between 6man and spring on how to proceed, and we are
>>> proceeding as agreed to work on the relevant documents.
>> 
>> I don't really know what the agreement is, other than the implicit 
>> agreement that if you're considering violating an IPv6 standard,
>> you should come to 6man and do a Std Track document that updates
>> the relevant standard...
> 
> if there ever is a corner case were header insertion can be done
> safely, and the issues it creates mitigated, then that should
> certainly not result in an update to the general rule in 8200.

1) As noted in the discussion, there's nothing that you can do with
EH-insertion that you cannot do with encap/decap. I don't see enough
motivation for an update of this sort -- other than "we want to save 40
bytes". In any case, I repeat what many others have already said: It's
on us to find problems on EH-insertion for it to not move forward. There
should first be a strong argument made in favor of it.

2) You cannot "mitigate" the implications of EH-insertion at the
protocol level (attribution of error messages, MTU issues...). The only
possible mitigations are operational, and those quite often fail.

3) While RFC8200 does not employ RFC2119 language (chair's call, not
mine), the statement in RFC8200 is pretty much a MUST. You do need to
update RFC8200. A reader of RFC8200 should now that there are scenarios
in which EH insertion is indeed allowed. Otherwise you end up with two
specs (IPv6 and SRv6) that contradict with each other.

4) I expect that, as co-chair, you'd agree with me that allowing EH
insertion in IPv6 is a major modification/addition. According to our
charter, we don't seem allowed to do that:
The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications.

I'm quite surprised that a few years ago many of you guys wanted to
essentially freeze most work on IPv6, and now you're so open to such a
major and fundamental change.

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