Re: [spring] Question about SRv6 Insert function

Ole Troan <otroan@employees.org> Sat, 07 September 2019 21:32 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 EF547120164; Sat, 7 Sep 2019 14:32:57 -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=unavailable 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 Vt6QCtvbRMkZ; Sat, 7 Sep 2019 14:32:56 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::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 21AC31200C3; Sat, 7 Sep 2019 14:32:56 -0700 (PDT)
Received: from astfgl.hanazo.no (unknown [IPv6:2a02:20c8:5921:100:95ad:b8b7:eed4:559e]) (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 809E74E11A78; Sat, 7 Sep 2019 21:32:55 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5AF221BC69D3; Sat, 7 Sep 2019 23:32:52 +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: <1f697fd6-dc77-b8dd-15fb-be23b3c296a4@si6networks.com>
Date: Sat, 7 Sep 2019 23:32:51 +0200
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C6D1E3F-5271-4516-94E6-F08974501DD0@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> <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>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/D3vSlFMMrr2lh7u3kyr6vfTyh0I>
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 21:32:58 -0000

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.

Ole