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

神明達哉 <jinmei@wide.ad.jp> Fri, 06 March 2020 21:49 UTC

Return-Path: <jinmei.tatuya@gmail.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 380303A0B62; Fri, 6 Mar 2020 13:49:05 -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 5T8kWDZzz4dK; Fri, 6 Mar 2020 13:49:01 -0800 (PST)
Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 CF9173A0B60; Fri, 6 Mar 2020 13:49:00 -0800 (PST)
Received: by mail-wm1-f44.google.com with SMTP id a5so4081907wmb.0; Fri, 06 Mar 2020 13:49:00 -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=PWE92aOTqqvs2gZA6NKy2RDfl5/+DkYW30s8vY18JWk=; b=kI2xMcbO4R0zWi01zxtJYoWJf/veUpc8Fu24wlSLhpcwzAnVZga5mZptdRDQo2oPPq LBLf7DdaNqaj2lxmemTa4qCQdKsjU7O+qPSKALWxtgWugiLiKnvapkSLd2fIabO3zNkV nQMZiHC4Pz0KEElaqwQc8NHyF7m7k+R2u7qoTcgM7iEUiQm45YxnrG3TU4aoYzUSWS8w MuS0TT0FQVwqq4iBT36ByyHfvW/hqPTp3hhRp5SwgT/qCQYPU4nMj5kNE+s7hGLvwdUJ Rf7kAc9bRx1XC/6EpOk35neviWdTMj8JCvlVWN771+jkS+DVofzcw9LRBj0kP+BExvI6 IqZQ==
X-Gm-Message-State: ANhLgQ0ZaI4ePva7DAOMr/mjZIlWqXQHein83wIi0vgRRLhjNZLhEgyL JbJGKumRNfftLXqxedOi2XnkYyOmgUn+SPSp/aA=
X-Google-Smtp-Source: ADFU+vvjxzOXtzrq5OIHzjRg1omLa8paMzgIgaVsrfdBaASpPJje7vshE6kbxwn45oZfugkZAc10UUfhxYXrXqeVRFY=
X-Received: by 2002:a1c:bc84:: with SMTP id m126mr5861076wmf.171.1583531339120; Fri, 06 Mar 2020 13:48:59 -0800 (PST)
MIME-Version: 1.0
References: <965ff6bbf1cb4c2f8d48b7b535a0cf5b@huawei.com> <CAJE_bqcTNWt==mtYKeNVXOBAzBNLG=+_mXQQ9xMHYOCDRqCb_Q@mail.gmail.com> <CAOj+MMEzbyzy98iFyfe6Z=dQiWHo=triX6bHKx9fNEUCaSuy3Q@mail.gmail.com> <CAJE_bqeiX1xWSMOOr=SGpVJdBSEgg-kYnUd29yeRURcVnx-xuA@mail.gmail.com> <4B3B4F36-7B15-4CBF-A015-274D10AF37B6@cisco.com> <CAJE_bqdJZuJG1SdMYwQQXn7xx8P_nH4HSVRUzwo584rf8W1ZSg@mail.gmail.com> <MW3PR11MB45700D359C86C45895F15608C1E20@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB45700D359C86C45895F15608C1E20@MW3PR11MB4570.namprd11.prod.outlook.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 06 Mar 2020 13:48:47 -0800
Message-ID: <CAJE_bqfFxcMgo-N9X0X0VxJheP45bDUrY16ZgemBpJrP+whYag@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Cc: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, Robert Raszuk <robert@raszuk.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HYrhPWyMmbo_vNZo9xCV3G22xaE>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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: Fri, 06 Mar 2020 21:49:06 -0000

At Thu, 5 Mar 2020 04:08:28 +0000,
"Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org> wrote:

> If we argue this behavior as not violating "extension headers cannot be removed from a packet until it has arrived at its ultimate destination" because "segment left" is 0 at that point (and therefore
> S2 is the "final destination"), that's a very innovative interpretation of the specification (not really surprisingly, given how "innovative" SRv6 people are:-).  In fact, with that kind of logic, we could write a specification which allows any intermediate node in a routing header decreases the segment left to 0 (regardless of the previous value of it) at its own discretion, and then claim it's the final (ultimate) destination and does whatever is allowed for the final destination node.
>
> [KT] This is definitely not the argument. Please check this link for the explanation of the logic : https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/

This link's explanation is that RFC8200 does NOT mean "extension
headers cannot be removed from a packet until it has arrived at its
ultimate destination" (and therefore PSP doesn't violate it), isn't
it?  Then please remember the context of this conversation - it
started with this comment by Robert:

>> Even if RFC8200 section 4 text would say:

>> "Extension headers cannot be added to a packet after it has left
>> its source node and extension headers cannot be removed from a
>> packet until it has arrived at its ultimate destination".

>> PSP would be still not be violating anything said in this
>> sentence.

And I wondered about the logic how "it would *still* be not violate the
RFC".  So this link's explanation isn't relevant to this specific
discussion.

As for that link's explanation, I already explained why that
interpretation doesn't make sense, probably several times, so I won't
repeat it again.  I know not everyone agrees with my explanation, and
I'm pretty sure no further explanation can change the mind of people
who firmly believe this link's argument, so there's no need for
repeating the position.

I guess that's the same for the rest of your response (sorry for not
addressing these one by one but).  I knew not everyone would
agree/support my arguments and suggestions.  From your response, it
looks like I already made my points clear enough, you understood them
correctly, and still disagreed with those.  At this point, I suspect
we'll just have to agree to disagree than wasting everyone's time to
keep making essentially the same points again and again.

I guess the only feasible next move of mine is to bring my points to
whatever next round of the process (another WGLC or IETF LC).

--
JINMEI, Tatuya