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

Joel Halpern <jmh@joelhalpern.com> Wed, 02 October 2024 00:23 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 C8801C1840C0 for <mpls@ietfa.amsl.com>; Tue, 1 Oct 2024 17:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, HTML_MESSAGE=0.001, 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_BLOCKED=0.001, 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 shxBzEJw1Yi2 for <mpls@ietfa.amsl.com>; Tue, 1 Oct 2024 17:23:52 -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 71CF8C180B58 for <mpls@ietf.org>; Tue, 1 Oct 2024 17:23:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4XJFsh0dpBz1nw53; Tue, 1 Oct 2024 17:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1727828632; bh=iCjYdgACc0J5eSPIgBMdDsYicCbsMyqeSh2iEM62gXg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KfB1K5A1ZLhLux8yjUm1beu7tcS/OgL3lRB9UKcadanUWmsmAvRQzrDtT1qW6T/EX Cd2QwZ8ltU/NHnhUlVpONI8/YQ0D9f0UqVqS5EfCvpngOtw6EKWVvvLNkZR9uNleIT OhYUXZYLxvT5LkLI1920vO3t5Rsn92TOtU6/mnT0=
X-Quarantine-ID: <bnIfVMCIOtU7>
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 4XJFsg0g8Bz1nv24; Tue, 1 Oct 2024 17:23:50 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------KZzmxKiptkWyqE2bqOswkP47"
Message-ID: <1b57e977-cf3e-4f28-8f53-9406143efbc4@joelhalpern.com>
Date: Tue, 01 Oct 2024 20:23:48 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Stewart Bryant <stewart.bryant@gmail.com>
References: <DS0PR19MB65014515D511B396E79BA36FFCF82@DS0PR19MB6501.namprd19.prod.outlook.com> <LV8P220MB1914BBB4896362040615CAB2FC6F2@LV8P220MB1914.NAMP220.PROD.OUTLOOK.COM> <5f5db9a20d8e4b47b5515b686e834227@huawei.com> <4819c3baa7bd4bff81babbd913db2227@huawei.com> <DM6PR11MB46922AC760C358D172A6A4B7DE752@DM6PR11MB4692.namprd11.prod.outlook.com> <452FDD29-F8A9-417A-8BC6-B16721385AEC@tony.li> <DM6PR11MB46923BEAA8216EFBE0545290DE752@DM6PR11MB4692.namprd11.prod.outlook.com> <6b90419c-bcfc-4684-b183-ff0c89b7a3c1@joelhalpern.com> <289b90823ed0455098e01fef4345c033@huawei.com> <681467407.11502344.1727704432584@mail.yahoo.com> <a33ccf42-5fb4-46a6-b288-37f39fb97051@pi.nu> <2055208025.11697997.1727792655775@mail.yahoo.com> <38BD48D5-BD9D-4B00-B1E6-8A916D2213B1@gmail.com>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <38BD48D5-BD9D-4B00-B1E6-8A916D2213B1@gmail.com>
Message-ID-Hash: N6ECQTFC3HCQZQYXAZ2NL5TWDQB4JFPP
X-Message-ID-Hash: N6ECQTFC3HCQZQYXAZ2NL5TWDQB4JFPP
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.9rc4
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/A81FakuomHnuSBrTpjA44QIW1oA>
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>

Accidentally eaten?  We a a group control the usage of the flags.  
Assigning the "p" bit without knowing the meaning, or even knowing if we 
need it, is bad protocol design practice.  Yes, if we agree we need PSD 
we may decide that we need a single bit (although it seems that opcode 
based indication is significantly better).  If so, we assign the bit 
then.   Whereas if we assign the bit now, but don't know how ior whether 
it works, we have created confusion.

Yours,

Joel

On 10/1/2024 12:22 PM, Stewart Bryant wrote:
> … but I support Loa’s point that we should keep the p bit in some 
> format so that it does not get accidentally eaten by some other update 
> to the draft or revision to the protocol.
>
> Stewart
>
>> On 1 Oct 2024, at 15:24, John Drake 
>> <je_drake=40yahoo.com@dmarc.ietf.org> wrote:
>>
>> Loa,
>>
>> My apologies.  I think I heard it from one of the authors of the 
>> subject draft, but basically the source is lost in the mists of time.
>>
>> John
>>
>> On Tuesday, October 1, 2024 at 07:00:18 AM PDT, Loa Andersson 
>> <loa@pi.nu> wrote:
>>
>>
>> John,
>>
>> Nope! That is something you made up.
>>
>> The WGAP on the draft-jags-mpls-mna-hdr was started 2023-01-31 and
>> closed 2023-03-01.
>>
>> The recommendation was two split the document intwo, one for ISD and one
>> for PSD, where the wg chairs call was that we had enough support for
>> adopting the ISD document as a working group document, while the PSD
>> document needed more work.
>>
>> Nothing was said about removing anything, p-flags or something else.
>>
>> The draft-ietf-mpls-mna-hdr was posted 2023-03-02, with the p-flag in
>> place. The wg chairs approved this version.
>>
>> The p-flag was removed in later versioons, and I was (mildly) opposed.
>>
>> SO far from telling the authors (as chair) to remove the the flag, my
>> individual position was and still is that it should be kept, until we
>> understood the implications.
>>
>> /Loa
>>
>> Den 30/09/2024 kl. 15:53, skrev John Drake:
>> > Jie,
>> >
>> > Actually, the subject draft had a PSD indicator and Loa told them to
>> > take it out.  This is actually normal, since as you point out, we 
>> don't
>> > know if we actually need PSD.
>> >
>> > John
>> >
>> > On Sunday, September 29, 2024 at 08:46:46 PM PDT, Dongjie (Jimmy)
>> > <jie.dong=40huawei.com@dmarc.ietf.org> wrote:
>> >
>> >
>> > Hi Joel,
>> >
>> > Having some fields defined as reserved is to leave room for future
>> > functions which currently we don’t have in mind.
>> >
>> > In this case, according to the MNA framework and the recent poll on 
>> IOAM
>> > and PSD, it is clear that PSD is in the scope of MNA, and using one 
>> bit
>> > flag as the indicator for PSD is one candidate approach currently 
>> under
>> > discussion, which can have impact to the encoding of the NAS. It is
>> > better to finalize the discussion about the PSD indication, then make
>> > necessary changes to draft-ietf-mpls-mna-hdr accordingly.
>> >
>> > IMO making a bit reserved first then updating its semantic very 
>> soon is
>> > not good for standardization nor implementation.
>> >
>> > Best regards,
>> >
>> > Jie
>> >
>> > *From:*Joel Halpern [mailto:jmh@joelhalpern.com]
>> > *Sent:* Sunday, September 29, 2024 10:12 PM
>> > *To:* Zafar Ali (zali) <zali=40cisco.com@dmarc.ietf.org>; Tony Li
>> > <tony.li@tony.li>
>> > *Cc:* mpls <mpls@ietf.org>
>> > *Subject:* [mpls] Re: Working Group Last Call on 
>> draft-ietf-mpls-mna-hdr
>> > (2nd WG call)
>> >
>> > I fail to see the coupling you are asserting.  We can happily 
>> define the
>> > reserved bit in the ISD RFC.  And then, if the WG adopts a PSD 
>> draft, it
>> > can define that bit to have specific meaning, if the solution needs
>> > that.  We do this all the time in lots of our protocols.  That is in
>> > fact why we define reserved bits.  Any solution implementing PSD will
>> > know about that bit and its meaning.  The fact that some ISD solutions
>> > that do not support PSD do not know aobut the bit does not cause any
>> > difficulty.  The PSD solution already needs to deal with requiring 
>> that
>> > the node addressed by the bottom of the stack understands PSD and will
>> > properly remove the PSD.
>> >
>> > I also disagree with a number of the other objections.  I am trying to
>> > think through the clearest way to explain my disagreement.  I hope to
>> > post that within a few days.
>> >
>> > Yours,
>> >
>> > Joel
>> >
>> > On 9/29/2024 9:55 AM, Zafar Ali (zali) wrote:
>> >
>> >    Hi Tony
>> >
>> >    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”.
>> >
>> >    For the reason many others and I mentioned, I also fail to see the
>> >    rush to progress draft-ietf-mpls-mna-hdr, prematurely.
>> >
>> >    Let’s first have the working group complete the work on PSD and all
>> >    the pieces and gain implementation maturity.
>> >
>> >    Thanks
>> >
>> >    Regards … Zafar
>> >
>> >    *From: *Tony Li <tony1athome@gmail.com>
>> > <mailto:tony1athome@gmail.com> on behalf of Tony Li
>> >    <tony.li@tony.li> <mailto:tony.li@tony.li>
>> >    *Date: *Sunday, September 29, 2024 at 2:00 AM
>> >    *To: *Zafar Ali (zali) <zali@cisco.com> <mailto:zali@cisco.com>
>> >    *Cc: *Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
>> > <mailto:zhoutianran=40huawei.com@dmarc.ietf.org>, Dongjie (Jimmy)
>> > <jie.dong=40huawei.com@dmarc.ietf.org>
>> > <mailto:jie.dong=40huawei.com@dmarc.ietf.org>, 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> <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)
>> >
>> >    [WG chair hat: on]
>> >
>> >    Hi Zafar,
>> >
>> >
>> >
>> >
>> >        On Sep 28, 2024, at 10:22 PM, Zafar Ali (zali) - zali at
>> >        cisco.com <mailforwards@cloudmails.net>
>> > <mailto:mailforwards@cloudmails.net> wrote:
>> >
>> >        There was a rather encrypted WG poll on PSD interest which shows
>> >        clear support from vendors and operators to work on the PSD 
>> option.
>> >
>> >        However, the working group has not heard any outcome of the 
>> poll.
>> >
>> >    Tarek posted the outcome of the poll on August 14th: https://
>> > mailarchive.ietf.org/arch/msg/mpls/qHBCt-X17u_VLIbuJuuS22C-ru8/
>> >    <https://mailarchive.ietf.org/arch/msg/mpls/qHBCt-X17u_VLIbuJuuS22C-
>> >    ru8/>
>> >
>> >    There were several subsequent comments on that thread that were also
>> >    relevant.
>> >
>> >    T
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> >    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 to mpls-leave@ietf.org <mailto:mpls-
>> > leave@ietf.org>
>> >
>> > _______________________________________________
>> > mpls mailing list -- mpls@ietf.org
>> > To unsubscribe send an email to mpls-leave@ietf.org
>>
>> -- 
>> Loa Andersson
>> Senior MPLS Expert
>> Bronze Dragon Consulting
>> loa@pi.nu
>> loa.pi.nu.@gmail.com
>>
>>
>> _______________________________________________
>> mpls mailing list -- mpls@ietf.org
>> To unsubscribe send an email to mpls-leave@ietf.org
>> _______________________________________________
>> mpls mailing list -- mpls@ietf.org
>> To unsubscribe send an email to mpls-leave@ietf.org
>