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

神明達哉 <jinmei@wide.ad.jp> Thu, 27 February 2020 22:18 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DD3A0D89; Thu, 27 Feb 2020 14:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 odRxsX7MaMFU; Thu, 27 Feb 2020 14:18:38 -0800 (PST)
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE253A0D82; Thu, 27 Feb 2020 14:18:38 -0800 (PST)
Received: by mail-wr1-f51.google.com with SMTP id p18so696247wre.9; Thu, 27 Feb 2020 14:18:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/5DyfIE1rOyb1l1ieS/2QB3djZLYLuDNAisZzdilByU=; b=InVoOvNe6kqqsvhT0zM68uPKy6eWvww1sbiPRRQ5p928A1JkFRyRE8YD6sxYhWkLlC 8gG6o6gxY6Y4W/NLAMwr3nLhUNrx45rNZEhYEKiggSrMn2dpDAacXKj8Xva+l50bM/vm E1+Dy2SJ2DXog9FPLKIaEqtlQvw7+cDjFk9x2lha+3r4Q+vrSnB8HNcMrYIPxm3PX6nX oYecVlqskrOdrFaGcuMtkMlsAXjp3ehQ4buaruNh0PWsVn7b3MyO/+6B0UilRmHIG+aY B+T6QD6m9xZNWx18GEIoj8WoBPF4aZ2vK4n2+qDCVuCY14LFF/jKsXVotiXzjTqyzOoL CVqA==
X-Gm-Message-State: APjAAAVPU1ajtJCm6zQ8F6eCgIcILe+Yqi0Zw4C1LcFtVF9d1+peg/xu vsZC/5S8/MW5T4ZiGUaclzm/cMEnNU09BfHev5Y9/ML4
X-Google-Smtp-Source: APXvYqyNjmMMjacRvQr6RUXCaOFoaDzu4yIclpprOeV9sU/WAyhIf2jX9skm8Y4OjZFscNKx72GdWiW2IWo0QVvEHBk=
X-Received: by 2002:a5d:6a04:: with SMTP id m4mr968616wru.127.1582841916463; Thu, 27 Feb 2020 14:18:36 -0800 (PST)
MIME-Version: 1.0
References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9364A1C2@DGGEMM532-MBX.china.huawei.com> <4038_1582727829_5E568295_4038_168_1_53C29892C857584299CBF5D05346208A48DB381A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <8ca30058-b8cf-cba4-524d-99b34e2b01d6@gont.com.ar> <CAJE_bqebPnJUoSL0KYCabh9tY5iMSFmq_Cg=7oxy4xsrOjs9Zg@mail.gmail.com> <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6348E24C7B3334B45571B7F2AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 27 Feb 2020 14:18:25 -0800
Message-ID: <CAJE_bqf8EBWxkkgtJj5RrKPR_z4GsZV888cUfZ_iigVXy+7nHw@mail.gmail.com>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: Fernando Gont <fernando@gont.com.ar>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZsOetWf61OERYavsTmCMLcu9TJE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 22:18:40 -0000

At Thu, 27 Feb 2020 21:29:24 +0000,
Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> 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), 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.  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.

And that's why I'm surprised at seeing this argument now.  Perhaps
those making this just because they forgot the previous discussion or
simply weren't involved in it.  But combining this point and other
signals that indicate the reluctance to take on the tedious
reconciliation between RFC8200 and this spec (which would be most
likely to require an update to the RFC), it wouldn't be unreasonable
if one suspects it may be an attempt of easily circumventing the
process rather than a genuine misunderstanding of the text.  I guess
this suspicion is somewhat commonly shared by those raising concerns
(including myself).

--
JINMEI, Tatuya