Re: [spring] Question about SRv6 Insert function

Fernando Gont <> Thu, 05 September 2019 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B449B120B31; Thu, 5 Sep 2019 13:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OpT2Wp2l8oib; Thu, 5 Sep 2019 13:47:05 -0700 (PDT)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94E16120271; Thu, 5 Sep 2019 13:47:04 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B38508627F; Thu, 5 Sep 2019 22:46:57 +0200 (CEST)
To: "Darren Dukes (ddukes)" <>
Cc: "" <>, Fernando Gont <>, Ron Bonica <>, "" <>, "" <>, Suresh Krishnan <>, draft-voyer-6man-extension-header-insertion <>, li zhenqiang <>, draft-ietf-spring-srv6-network-programming <>
References: <> <> <> <> <> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Thu, 5 Sep 2019 23:42:32 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Approved-At: Thu, 05 Sep 2019 19:06:41 -0700
Subject: Re: [spring] Question about SRv6 Insert function
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 20:47:08 -0000

On 5/9/19 23:26, Darren Dukes (ddukes) wrote:
> inline.
>> On Sep 5, 2019, at 4:01 PM, Fernando Gont <> wrote:
>> On 5/9/19 22:52, Darren Dukes (ddukes) wrote:
>>> Hey Fernando, since you’re lost, here are some more waypoints to help
>>> you find your way ;)
>>> - draft-ietf-spring-srv6-network-programming mentions SRH insertion in
>>> only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and
>>> all insert variants have an encapsulation variant defined.
>> I don't see how this changes the discussion here.
> Perhaps you should read the whole document Fernando.

I'm arguing that there is a document that relies on stuff that 6man
never even wanted to adopt as wg item. You respond "but the document has
other stuff". And I repeat: the document still assumes EH insertion is
possible, when it's actually forbidden.

>>> - At IETF 101, the 6man WG confirmed that SRH insertion must be worked
>>> on before draft-ietf-spring-srv6-network-programming can progress to RFC
>>> - i.e. there are not surprises anywhere.
>>> - draft-ietf-spring-srv6-network-programming added a normative reference
>>> to draft-voyer-6man-extension-header-insertion to document that fact.
>> Among the possible options is that EH-insertion is never worked out. In
>> which case, what's the point of basing something on EH insertion when
>> the status quo is that EH insertion is not allowed, and there does not
>> seem to be any indication that that will change anytime soon?
> Ah, an excellent reason to never work on anything: if its not easy then don’t bother with the work!

That's clearly not my point. My point is that you are putting the cart
before the horse.

Make your case for EH insertion, and try to update RFC8200 such that EH
insertion is allowed (among other things, explain why you need it, and
why you want to insert EHs instead of encap/decap -- which
draft-voyer-6man-extension-header-insertion does not even mention). Then
do the rest.

Or pursue what you are doing in spring without any EH-insertion, and
postpone anything that has to do with EH insertion for when/if it is
actually allowed.

I'm all for you trying any of these options. But not for the very
curious interpretations of RFC2460 and/or RFC8200, or trying to avoid
updating RFC8200 before doing EH insertion.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492