Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Suresh Krishnan <> Thu, 27 February 2020 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2FC33A0DE5; Thu, 27 Feb 2020 14:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kwsJQsWpjP9N; Thu, 27 Feb 2020 14:34:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B812C3A0DE0; Thu, 27 Feb 2020 14:34:18 -0800 (PST)
Received: by with SMTP id i190so1345598ywc.2; Thu, 27 Feb 2020 14:34:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oNdxJzJGhhYbatidg3laNTEn3j4/6GV3YovFHhfjF6M=; b=NQumqDEkNIK85dqzIoPbkKveggaOYi1CK24qnTPaZje2bQiXdIcD4xexdNH1I+tvRa W7ov2+8FvMGx1BGnHLmWR1DbBkmcwJ6w57703lFxR7IW235OnmwE1SVh5QieU8wyOoRr 7VuxAllz3JR4da5Xn4+snxg5UVhUO746AnVHdVTO2MuDWdQckpgDgXc+5dFAId/bZ1wF aGrUBb1vO8tGDXDdnrfSCJ5SSlBYQB4DJoAjUT8iJa1xODFTXHOFb755xw9IVxqLlyG7 MuuLyhRhmTfqSv625und+YAaTJP2RvsGBxpqwb20+Xf5lJvEvnXTXDYtXumvWysXeUn8 +QBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oNdxJzJGhhYbatidg3laNTEn3j4/6GV3YovFHhfjF6M=; b=Dfc3+2EqsoQ0LvOaVRHRdf/BcicAV9v/X7ZVq8O4eWU+8Ste/RvnSMNRr5EY/GgzUZ ZSo02Merc4x9RSrAdO5EO78YceB7Hrb1lMCdZKQZJctSlTlpPqf+wIucikRyNGqZMSsW sJI87wbeaFHmuV+c9lYIkpC+VVUE3Aj9XSKb0jwdMh54mPEEtqhEe08Zlj+OgPKEYR1V 5eM0rbufNZhVBubPgwj5ly/czL3Zbuj+KJA0zvw+BAs+MmWsIUeDxKoH0tFSIBrYq3lW gejV+9B5NI1wHEEWYbZXrIjgFJPmT6YSb+XRuMrAyPlpY8cEvdRcGW+t+oF0QpHvvhnL rF0w==
X-Gm-Message-State: APjAAAV7Lbn7vvgLph4q3DDC6LHULlBncsBy1vwLf4GgUcLiwIzOWZx1 ekOcGNyGB5K5uB9mRp8zwQc=
X-Google-Smtp-Source: APXvYqy3gGD3f6qCryTFzmupAhAkxHHO3j50X3t+00sLpbRXU3Ois4rnupZDJ+ouToNvu6KQha9C5Q==
X-Received: by 2002:a0d:fb82:: with SMTP id l124mr1795453ywf.507.1582842857851; Thu, 27 Feb 2020 14:34:17 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d9sm3098622ywh.55.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 14:34:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
From: Suresh Krishnan <>
In-Reply-To: <>
Date: Thu, 27 Feb 2020 17:34:16 -0500
Cc: Ron Bonica <>, SPRING WG List <>, "" <>, Fernando Gont <>, draft-ietf-spring-srv6-network-programming <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <4038_1582727829_5E568295_4038_168_1_53C29892C857584299CBF5D05346208A48DB381A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <> <> <> <>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Feb 2020 22:34:21 -0000

Hi Jinmei,

> On Feb 27, 2020, at 5:18 PM, 神明達哉 <> wrote:
> At Thu, 27 Feb 2020 21:29:24 +0000,
> Ron Bonica <> wrote:
>> The question is whether PSP violates the following clause from Section 4 of RFC 8200:
>> "Extension headers (except for the Hop-by-Hop Options header) are not
>>   processed, inserted, or deleted by any node along a packet's delivery
>>   path, until the packet reaches the node (or each of the set of nodes,
>>   in the case of multicast) identified in the Destination Address field
>>   of the IPv6 header."
>> A literal reading of this text suggest that any segment endpoint (i.e., any node referenced in the Routing Header) can process, insert, or delete any extension header. This is because when a packet arrives at a segment endpoint, one of its addresses appears in the IPv6 Destination Address field.
> Please see my response to my own message.  Yes, purely "literally", it
> could read that way (it's amazing human-written text can be always
> ambiguous to some extent, no matter how hard we try to clarify it),

Yes, this is unfortunate. We ended up strengthening some constraints while leaving some others open. While I would (and do) interpret things exactly as you did, it is impossible to determine after the fact if a different text formulation would have gotten consensus. What we have is the text of RFC8200.

> but
> that doesn't make sense if we recall a larger context.  If the phrase
> "Destination Address field of the IPv6 header" could justify the
> deletion (or even insertion, for that matter) of an EH at a node like
> that, then changing this text in RFC2460
>   With one exception, extension headers are not examined or processed
>   by any node along a packet's delivery path, until the packet reaches
>   the node (or each of the set of nodes, in the case of multicast)
>   identified in the Destination Address field of the IPv6 header.
> to the above one in RFC8200 shouldn't have caused the painful debate
> regarding the implication of SRv6.  

In my mind it did because some people claimed that RFC2460 did allow insertion and deletion since it only prohibited “examining and processing” the headers. The controversy was because some people were opposed to the prohibition for insertion and deletion be explicit.

> We should have known this change
> would make the SRv6-style insertion/deletion a violation of the RFC
> even more clearly than RFC2460 at that time, and that's why we needed
> that discussion.

Just so we are clear, SRv6 is defined in draft-ietf-6man-segment-routing-header-26 and it does not have anything about header insertion. Some earlier versions of the draft did and I was clear that it needed to be removed for it to progress from 6man. The authors removed the insertion mode from the draft.