[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

Joel Halpern <jmh@joelhalpern.com> Wed, 02 October 2024 17:29 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835DC180B79 for <mpls@ietfa.amsl.com>; Wed, 2 Oct 2024 10:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejPvF8fCojbA for <mpls@ietfa.amsl.com>; Wed, 2 Oct 2024 10:29:51 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37080C180B54 for <mpls@ietf.org>; Wed, 2 Oct 2024 10:29:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4XJhdW0b87z1prZR; Wed, 2 Oct 2024 10:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1727890191; bh=SRqRKaNAAZ+Ek+frwNwiaUIj4XlR2Q+H7auAXZh6430=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZNGhlnoEk4pIvIec4jQDrm2ozunFTXao0yZaBpZxyveSQF5NU5b+yVplTir/pjJB/ BdNmN0lHJbtHxR/KsBuCJgywHpiLCSNG7BsOk7GLbea+zgQVLmTwpFsOj6Lscm0U5P jHAd25TufEmY26CMaNZ472Y6pbC0MRC/3Xty6x6g=
X-Quarantine-ID: <3nPKBF06468n>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.22.13] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4XJhdV3thHz1pJKN; Wed, 2 Oct 2024 10:29:50 -0700 (PDT)
Message-ID: <a2c48db3-a12b-4ee5-ab30-be15bf879e32@joelhalpern.com>
Date: Wed, 02 Oct 2024 13:29:48 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Loa Andersson <loa@pi.nu>
References: <DS0PR19MB65014515D511B396E79BA36FFCF82@DS0PR19MB6501.namprd19.prod.outlook.com> <DM6PR11MB46922AC760C358D172A6A4B7DE752@DM6PR11MB4692.namprd11.prod.outlook.com> <452FDD29-F8A9-417A-8BC6-B16721385AEC@tony.li> <DM6PR11MB46923BEAA8216EFBE0545290DE752@DM6PR11MB4692.namprd11.prod.outlook.com> <2AEEDFE6-230A-4A19-BF5E-3B9AC34B5603@tony.li> <7390a29e261f4728a31e6984240efdab@huawei.com> <CA+RyBmXLYTybEGsSK6Wx0+g-TnPStWGN-zosfRutsJ1Eo2kDzA@mail.gmail.com> <17428b303a3540ba8266b78128f27938@huawei.com> <940c9751-0731-4d6f-9087-dc6efe610b32@joelhalpern.com> <aa8154bfa19d494b8e75b9523c8d508c@huawei.com> <d4620d84-9e57-4931-a92c-ac36fe9d6c9a@joelhalpern.com> <1d091faa1bb5408fa19a5feee479fb4c@huawei.com> <f404e92c-4618-4245-b5ce-e1ff232296d5@joelhalpern.com> <DM6PR11MB46923AC9A8019DC5AA31EA14DE772@DM6PR11MB4692.namprd11.prod.outlook.com> <9f6d3a6a-ee6b-4625-8783-6fefeb8c97c6@pi.nu> <acdaf5be-3b66-49e3-9d83-0d1ef5842fa0@joelhalpern.com> <46257d16-2b53-413b-9af7-6bd03605453c@pi.nu>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <46257d16-2b53-413b-9af7-6bd03605453c@pi.nu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: KA45UHTZXYP5CII3G6HU4RTUNW5FYOC5
X-Message-ID-Hash: KA45UHTZXYP5CII3G6HU4RTUNW5FYOC5
X-MailFrom: jmh@joelhalpern.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lfNTopn61BX3nTmM0Z5Ww9lwnTM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

No, that does not follow.   PSD can build on the ISD draft. There are no 
changes required to the ISD (mna-hdr) draft to enable supporting PSD.  
Additional opcdes, flags, or other indications can be added in whatever 
PSD draft the working group adopts, if it ever does.

The only justification for holding up the ISD draft that I can see would 
be if there was support needed in nodes that support ISD and not PSD.  
There is  no indication of such a need.

Please do not put words in my mouth.  I have been very clear that the 
ISD draft should be advanced.

Yours,

Joel

On 10/2/2024 1:21 PM, Loa Andersson wrote:
> Joel,
>
> Since you agree that PSD can't be done in isolation, but will depend 
> on ISD (or at least the MPLS label stack), I guess that you also agree 
> that we should wait with progress the ISD draft.
>
> /Loa
>
> Den 02/10/2024 kl. 14:57, skrev Joel Halpern:
>> You highlight one of many open questions about what a P-flag would 
>> mean.  Which strongly suggests that deferring adding it until we have 
>> a working group draft on PSD, which can add it, would be sensible.  
>> And you have not responded meaningfully to my earlier concern that 
>> ther ei sno benefit to assigning the bit isntead of reserving it, as 
>> the draft currently does.
>>
>> Yours,
>>
>> Joel
>>
>> On 10/2/2024 6:01 AM, Loa Andersson wrote:
>>> Zafar and Tianran,
>>>
>>> I certainly think that we should have the p-flag re-inserted.
>>>
>>> The problematic part is that we can't guarantee that the MNA Post- 
>>> Stack header directly after the LSE with the BoS set. There might be 
>>> some CW there and we need to be able (one way or another) to tell 
>>> where the MNA Post-stack header starts. OpCode + offset? That is by 
>>> definition ISD, so we need to think a bit about how we specify this.
>>>
>>> /Loa
>>>
>>>
>>>
>>> Den 01/10/2024 kl. 18:37, skrev Zafar Ali (zali):
>>>> Dear chairs and the WG,
>>>>
>>>> I agree with Tianran.
>>>>
>>>> I am also concerned about lack of implementation experience and 
>>>> interoperability for a data plane change addressing a subset of the 
>>>> MNA architecture.
>>>>
>>>> These are hardware changes that are not proven or demonstrated in 
>>>> the field, yet.
>>>>
>>>> Thanks
>>>>
>>>> Regards … Zafar
>>>>
>>>> *From: *Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
>>>> *Date: *Monday, September 30, 2024 at 8:08 PM
>>>> *To: *Joel Halpern <jmh@joelhalpern.com>
>>>> *Cc: *mpls <mpls@ietf.org>
>>>> *Subject: *[mpls] Re: Working Group Last Call on 
>>>> draft-ietf-mpls-mna- hdr (2nd WG call)
>>>>
>>>> Looking at the use case draft, PSD can address all use cases and 
>>>> future proof. In this sense, there is no need to implement ISD at all.
>>>>
>>>> I also started a thread in the working group mailing list to 
>>>> investigate the operators requirements. I only got one requirement 
>>>> on noffrr. There’s rare interest on existing MNA.
>>>>
>>>> I can’t believe we are going to publish such paper work in a hurry.
>>>>
>>>> Tianran
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>>
>>>> Sent from WeLink
>>>>
>>>> *发**件人: *Joel Halpern<jmh@joelhalpern.com 
>>>> <mailto:jmh@joelhalpern.com>>
>>>>
>>>> *收件人: *Tianran Zhou<zhoutianran@huawei.com 
>>>> <mailto:zhoutianran@huawei.com>>
>>>>
>>>> *抄送: *mpls<mpls@ietf.org <mailto:mpls@ietf.org>>
>>>>
>>>> *主**题**: *Re: [mpls] Re: Working Group Last Call on draft-ietf- 
>>>> mpls- mna-hdr (2nd WG call)
>>>>
>>>> *时间**: *2024-09-30 10:40:20
>>>>
>>>> Given that the PSD proposal on the table requires the ISD draft, 
>>>> and does not require any changes to the ISD draft, I do not 
>>>> understand your comments.  You have said you do not want any ISD 
>>>> solution, and now you are suggesting we adopt a PSD solution that 
>>>> requires ISD?
>>>>
>>>> And it is not clear that we need a PSD solution at all.
>>>>
>>>> If we need a PSD solution, I expect with some clarifications and 
>>>> modifications the jags psd draft can serve as a basis for further 
>>>> work.  I would strongly prefer to get the ISD work done.  Then we 
>>>> can have the debate about whethere we need PSD, and then discuss 
>>>> what a solution should look like.
>>>>
>>>> Yours,
>>>>
>>>> Joel
>>>>
>>>> On 9/29/2024 10:16 PM, Tianran Zhou wrote:
>>>>
>>>>     Then why not adopting that PSD proposal as the base for 
>>>> discussion?
>>>>     And find out how it will require the draft-ietf-mpls-mna-hdr.
>>>>
>>>>     Best,
>>>>
>>>>     Tianran
>>>>
>>>>     *From:*Joel Halpern [mailto:jmh@joelhalpern.com
>>>>     <mailto:jmh@joelhalpern.com>]
>>>>     *Sent:* Monday, September 30, 2024 9:43 AM
>>>>     *To:* Tianran Zhou <zhoutianran@huawei.com>
>>>>     <mailto:zhoutianran@huawei.com>
>>>>     *Cc:* mpls <mpls@ietf.org> <mailto:mpls@ietf.org>
>>>>     *Subject:* Re: [mpls] Re: Working Group Last Call on draft-ietf-
>>>>     mpls-mna-hdr (2nd WG call)
>>>>
>>>>     So we should hold up the ISD draft for some proposal to 
>>>> appear?  The
>>>>     one PSD proposal we have on the table does not require any changes
>>>>     to the mna-hdr ISD draft.    That seems to request arbitrary delay
>>>>     from the WG without justification.
>>>>
>>>>     Yours,
>>>>
>>>>     Joel
>>>>
>>>>     On 9/29/2024 9:36 PM, Tianran Zhou wrote:
>>>>
>>>>         So the next step for the WG is to work out the PSD and see how
>>>>         ISD and PSD can complement and be compatible.
>>>>
>>>>         It’s not the time to finalize draft-ietf-mpls-mna-hdr in 
>>>> hurry.
>>>>
>>>>         Especially when there is no hands on implementation.
>>>>
>>>>         Tianran
>>>>
>>>>         *From:*Joel Halpern [mailto:jmh@joelhalpern.com
>>>>         <mailto:jmh@joelhalpern.com>]
>>>>         *Sent:* Monday, September 30, 2024 9:06 AM
>>>>         *To:* Tianran Zhou <zhoutianran@huawei.com>
>>>>         <mailto:zhoutianran@huawei.com>
>>>>         *Cc:* mpls <mpls@ietf.org> <mailto:mpls@ietf.org>
>>>>         *Subject:* Re: [mpls] Re: Working Group Last Call on 
>>>> draft-ietf-
>>>>         mpls-mna-hdr (2nd WG call)
>>>>
>>>>         If someone wants to put a proposal on the table for PSD that
>>>>         does not require ISD, they can do so.  And the WG can, if the
>>>>         process moves that far, consider that solution. But, by
>>>>         definition, if the solution does not use ISD then it has no
>>>>         impact on advancing the mna-hdr draft solution for those cases
>>>>         which use ISD.  I still do not see the coupling you are 
>>>> asserting.
>>>>
>>>>         In particular, while the requirements permit such a solution,
>>>>         they do not mandate it.  Since we do not even have a proposal
>>>>         for how to do PSD without ISD, it seems really confusing to be
>>>>         objecting to advancing the mna-hdr draft on such a basis.
>>>>
>>>>         Yours,
>>>>
>>>>         Joel
>>>>
>>>>         On 9/29/2024 8:43 PM, Tianran Zhou wrote:
>>>>
>>>>             Hi Greg,
>>>>
>>>>             Please see below:
>>>>
>>>>                 5.   Subject to the constraints in these 
>>>> requirements, a
>>>>             Network
>>>>
>>>>                      Action solution MAY carry MNA information 
>>>> in-stack,
>>>>             post-stack,
>>>>
>>>>                      or both in-stack and post-stack.
>>>>
>>>>                 6.   Solution specifications MUST NOT require an
>>>>             implementation to
>>>>
>>>>                      support in-stack ancillary data, unless the
>>>>             implementation
>>>>
>>>>                      chooses to support an NA that uses in-stack
>>>>             ancillary data.
>>>>
>>>>             Tianran
>>>>
>>>>             *From:*Greg Mirsky [mailto:gregimirsky@gmail.com
>>>>             <mailto:gregimirsky@gmail.com>]
>>>>             *Sent:* Monday, September 30, 2024 8:24 AM
>>>>             *To:* Tianran Zhou <zhoutianran@huawei.com>
>>>>             <mailto:zhoutianran@huawei.com>
>>>>             *Cc:* Tony Li <tony.li@tony.li> <mailto:tony.li@tony.li>;
>>>>             Zafar Ali (zali) <zali@cisco.com> <mailto:zali@cisco.com>;
>>>>             mpls <mpls@ietf.org> <mailto:mpls@ietf.org>; mpls-chairs
>>>>             <mpls-chairs@ietf.org> <mailto:mpls-chairs@ietf.org>; 
>>>> draft-
>>>>             ietf-mpls-mna-hdr@ietf.org <mailto:draft-ietf-mpls-mna-
>>>>             hdr@ietf.org>
>>>>             *Subject:* Re: [mpls] Re: Working Group Last Call on 
>>>> draft-
>>>>             ietf-mpls-mna-hdr (2nd WG call)
>>>>
>>>>             Hi Tianran,
>>>>
>>>>             Please point me to the part of RFC 9613 <https://
>>>>             datatracker.ietf.org/doc/rfc9613/> that supports your 
>>>> request.
>>>>
>>>>             Regards,
>>>>
>>>>             Greg
>>>>
>>>>             On Sun, Sep 29, 2024 at 4:44 PM Tianran Zhou
>>>>             <zhoutianran=40huawei.com@dmarc.ietf.org
>>>>             <mailto:40huawei.com@dmarc.ietf.org>> wrote:
>>>>
>>>>                 The IPR poll for the two document did not hit the 
>>>> point.
>>>>
>>>>                 The point is how can the MNA mechanism disable the ISD
>>>>                 and use PSD only.
>>>>
>>>>                 The draft-ietf-mpls-mna-hdr need to resolve this.
>>>>
>>>>                 Tianran
>>>>
>>>>                 *From:*Tony Li [mailto:tony1athome@gmail.com
>>>>                 <mailto:tony1athome@gmail.com>] *On Behalf Of *Tony Li
>>>>                 *Sent:* Monday, September 30, 2024 12:13 AM
>>>>                 *To:* Zafar Ali (zali) <zali@cisco.com
>>>>                 <mailto:zali@cisco.com>>
>>>>                 *Cc:* Tianran Zhou <zhoutianran@huawei.com
>>>>                 <mailto:zhoutianran@huawei.com>>; Dongjie (Jimmy)
>>>>                 <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>;
>>>>                 Tarek Saad <tsaad.net@gmail.com
>>>>                 <mailto:tsaad.net@gmail.com>>; mpls <mpls@ietf.org
>>>>                 <mailto:mpls@ietf.org>>; mpls-chairs <mpls-
>>>>                 chairs@ietf.org <mailto:mpls-chairs@ietf.org>>; draft-
>>>>                 ietf-mpls-mna-hdr@ietf.org 
>>>> <mailto:draft-ietf-mpls-mna-
>>>>                 hdr@ietf.org>
>>>>                 *Subject:* Re: Working Group Last Call on draft-ietf-
>>>>                 mpls-mna-hdr (2nd WG call)
>>>>
>>>>                 Hi Zafar,
>>>>
>>>>                     I am aware of the thread but all we hear is that
>>>>                     chairs are discussing the responses and will share
>>>>                     further update, “interest” vs. “consensus” debate,
>>>>                     the chairs are discussing how to initiate the PSD
>>>>                     debate, etc. There were 65 emails on the original
>>>>                     PSD poll. I am not sure why we need another 
>>>> round of
>>>>                     debate and what will be the nature of that debate.
>>>>                     Why not just start WG adoption call and gauge 
>>>> the WG
>>>>                     “consensus”.
>>>>
>>>>                 That’s exactly what we’re doing. The process for doing
>>>>                 this begins with an IPR poll.
>>>>
>>>>                 Nic started the IPR poll on draft-mb-mpls-ioam-dex and
>>>>                 draft-gandhi-mpls-ioam-dex on Sept 3.
>>>>
>>>>                 https://mailarchive.ietf.org/arch/msg/mpls/
>>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/ <https://
>>>>                 mailarchive.ietf.org/arch/msg/mpls/
>>>>                 XU3Ycij6Oq2kGWi14k3eXmpdQvM/>
>>>>
>>>>                 https://mailarchive.ietf.org/arch/msg/
>>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/ <https://
>>>>                 mailarchive.ietf.org/arch/msg/
>>>>                 mpls/7NmJqyMHDairPxEn7PGxz99KNiI/>
>>>>
>>>>                 Tony
>>>>
>>>> _______________________________________________
>>>>                 mpls mailing list -- mpls@ietf.org 
>>>> <mailto:mpls@ietf.org>
>>>>                 To unsubscribe send an email to mpls-leave@ietf.org
>>>>                 <mailto:mpls-leave@ietf.org>
>>>>
>>>>             _______________________________________________
>>>>
>>>>             mpls mailing list --mpls@ietf.org <mailto:mpls@ietf.org>
>>>>
>>>>             To unsubscribe send an email tompls-leave@ietf.org 
>>>> <mailto:mpls-leave@ietf.org>
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls mailing list -- mpls@ietf.org
>>>> To unsubscribe send an email to mpls-leave@ietf.org
>>>
>