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

Greg Mirsky <gregimirsky@gmail.com> Sun, 29 September 2024 16:05 UTC

Return-Path: <gregimirsky@gmail.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 47EF8C14F61F; Sun, 29 Sep 2024 09:05:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 (2048-bit key) header.d=gmail.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 xT2kYE9BzEKH; Sun, 29 Sep 2024 09:05:39 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247A3C14F5F9; Sun, 29 Sep 2024 09:05:39 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-42cbbb1727eso31658885e9.2; Sun, 29 Sep 2024 09:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727625937; x=1728230737; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cDMiIhMDmUwNBICcD+a+qS100tOoc28D72JOTJPAa68=; b=TYgZeArYcAx1PjCHfRu7s0DisGAdeZD0huvIBA3L6bK5snof3rCTFv0O3mtbfOILTZ WC0jr+ZKFCyHY9tFZWdcukxx3Z6veid6TI/c/mf+c/Wmh05j286LMW8pkltQx9RT5txt jiZJhlWPA+sWt487hnTwVJqI5I0b6ywunMBTm/gBt7YEtUR5PllJBRNNG0Ax7/4jxv7/ vSfvCEs2Svr5Kcve8XtioUTuLEvRVuRK+zZAZGvRfc7cuGp5MPto4TnVy5eh1HdtsG9B LJjH1Dcnu82OFvPFk7s+L/XYvzes/2SZsJXV9VuAfqXs24GwY21s6/nWmHz1Hs7Pk0YQ x1Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727625937; x=1728230737; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cDMiIhMDmUwNBICcD+a+qS100tOoc28D72JOTJPAa68=; b=bSxdE6xsFaKqbNpeK9gN2YZwREhkbD/G6gS1xGJc9CmYDG7PqQ8fsP1ICsTvJocpYZ 5bu/PH1R1IJ1Kd6KdrAekkGj2blUYvL2tqTDiWPRUA4MsUnfUCTtFyLqWB9mn4sGskFy 6dNPV23VvNsgJznR268v0Dqk1MlhGTTPN1Pln5J9cTqW0D5fEEorkG1xeSyS9N4Kyb0d PYTiCXjOC00+NVi432jXGBFSSoEdGFesD1aHO4d3whMyDtmg41tE+8Jfmg89prJyqYSH YxHyrlmEGlHWJ7GTIRs0oJcyhVRMnjqmNYP7qp6lfkv3kQ7l28nY0SMmwAfeCHkmVeR9 hD8A==
X-Forwarded-Encrypted: i=1; AJvYcCUUZBTigabq9vgnOAygAJKMKGVkIVOZ/BYJI3ZyVqQdAdY/X1BijhfMxSUG8N5b7yzjJtk4PrsypkufNAM=@ietf.org, AJvYcCXipT27A+6Um/0gAJ05c1qPzX6hLUKvsC2u/4W0uH6VtYqTrMmmWV8PVTvGnByXbw2Fc3NUPA==@ietf.org, AJvYcCXzbEMaSUHU0ly6Oas7hLBsZEcJ8AEIIZkDQDZyMrcH2+IvRIFnMua/PpAsJFrdnoe/d1VRGzpvvQqIc0PqIU30jjTnZmyozQ==@ietf.org
X-Gm-Message-State: AOJu0Yz8MTz5FpgsNrzKTkb669fsUb0OPWqdCwvdIFwW8m8x0KEgrvli 5j4jDcJ3siqrtRV5cX05z2dvdDQvAlFwmgM5Zkr/cAvVIl6G9lGg5Tx9b09Wsg2Vn6gwuwa0Vbq lj7n1t0Gsq9D7rRfYYyVYUmKWXmZWSxYV
X-Google-Smtp-Source: AGHT+IHo6LaKDdgdArVksL0vKrQ7jo9Csdwetvum6XHW5wiWzV3xECtYXI1BDWCdExEbnxwbkt4s0c81cnNHQgq2z2o=
X-Received: by 2002:a05:600c:4f01:b0:42c:afea:2a10 with SMTP id 5b1f17b1804b1-42f58441814mr77521565e9.21.1727625937135; Sun, 29 Sep 2024 09:05:37 -0700 (PDT)
MIME-Version: 1.0
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> <CABNhwV1w3UU+CCbw7JUQ_B4q8MbrO0W-r8vTtY_AZb6q5SQ3hQ@mail.gmail.com>
In-Reply-To: <CABNhwV1w3UU+CCbw7JUQ_B4q8MbrO0W-r8vTtY_AZb6q5SQ3hQ@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 29 Sep 2024 09:05:25 -0700
Message-ID: <CA+RyBmUwJHPaieSONnPrOq0X-3pXoxc5Ggr4_-fRBNV0cUkmqw@mail.gmail.com>
To: Gyan Mishra <hayabusagsm@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000049b4ee062344420c"
Message-ID-Hash: JXOOL7SRMRUHN4BTSZN6W6E4IAULETG6
X-Message-ID-Hash: JXOOL7SRMRUHN4BTSZN6W6E4IAULETG6
X-MailFrom: gregimirsky@gmail.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: "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, MPLS Working Chairs <mpls-chairs@ietf.org>, "draft-ietf-mpls-mna-hdr@ietf.org" <draft-ietf-mpls-mna-hdr@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/wLjI34_pv5EGG8jOO7NPOOVfYAQ>
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>

Hi Gyan,
thank you for sharing your view on progressing MNA solution and the
realization of IOAM in the MPLS network. I have a question. You assert that
"IOAM requires mutable data". Could you point where in IOAM specifications,
i.e., RFC 9197 and RFC 9326, a mutable information element is required to
realize on-path operational state and performance metric information
collection?

Regards,
Greg

On Sun, Sep 29, 2024 at 12:34 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> Dear Chairs & WG
>
> I agree with points raised by  Zafar, Jimmy, Tianran, Loe and other WG
> members that this is a hardware implementation that is standards track and
> that said must have a minimum two interoperable implementations.
>
> I support both ISD and PSD.
>
> There has been a lot of discussions on ML about both and I think both
> should be included in this draft as they are in the MNA framework
> architecture draft section 3.6.
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-10#name-encoding-of-post-stack-data
>
> I agree the PSD work should be completed before we move forward with
> progressing this document.
>
> This was from “IOAM and PSD” discussion this past summer:
>
> From Michel Menth 8/3/23 below
> - presented some results at an interim meeting before:
>
> https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls
>
> IOAM requires mutable data. In combination with multiple labels, e.g., for
> SR, these mutable data need to be near the bottom of the stack, otherwise
> they get popped along the way. Moving them to PSD makes encoding more
> efficient without increasing the effective header length that needs  to be
> parsed. Therefore, we think PSD is the better option for applications like
> IOAM.
> This draft is not ready for progression at this time.
>
> Kind Regards
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
>
>
> On Sun, Sep 29, 2024 at 1:24 AM Zafar Ali (zali) <zali=
> 40cisco.com@dmarc.ietf.org> wrote:
>
>> Dear chairs and the WG,
>>
>>
>>
>> I agree with points raised by Jimmy, Tianran, Loe and others.
>>
>>
>>
>> This is hardware implementation.
>>
>> The ask is to progress the document as a standards track RFC.
>>
>> Having at least two interoperable implementations by vendors should be a
>> bare minimum bar.
>>
>>
>>
>> Support for PSD is part of the MNA architecture.
>>
>> 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.
>>
>> The PSD draft remains an individual draft.
>>
>>
>>
>> Let’s first have the working group complete the work on PSD and all the
>> pieces.
>>
>> The document is not ready for progression as a standards track RFC at
>> this point in time.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>> *From: *Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
>> *Date: *Thursday, September 26, 2024 at 7:48 PM
>> *To: *Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>, Tarek Saad
>> <tsaad.net@gmail.com>, mpls@ietf.org <mpls@ietf.org>
>> *Cc: *MPLS Working Chairs <mpls-chairs@ietf.org>,
>> draft-ietf-mpls-mna-hdr@ietf.org <draft-ietf-mpls-mna-hdr@ietf.org>
>> *Subject: *[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
>> (2nd WG call)
>>
>> Hi Tarek and WG,
>>
>>
>>
>> I do not support the publication of this draft.
>>
>> I agree with Jimmy there are serious concerns about ISD implementation
>> and performance.
>>
>> I believe ISD is not the right approach for MNA, we will not implement it.
>>
>> I need a knob in existing MNA hdr to disable ISD and enable PSD.
>>
>>
>>
>> Best,
>>
>> Tianran
>>
>>
>>
>> *From:* Dongjie (Jimmy) [mailto:jie.dong=40huawei.com@dmarc.ietf.org]
>> *Sent:* Friday, September 27, 2024 12:28 AM
>> *To:* Tarek Saad <tsaad.net@gmail.com>; mpls@ietf.org
>> *Cc:* MPLS Working Chairs <mpls-chairs@ietf.org>;
>> draft-ietf-mpls-mna-hdr@ietf.org
>> *Subject:* [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr
>> (2nd WG call)
>>
>>
>>
>> Hi Tarek,
>>
>>
>>
>> Before the 1st WG LC, some implementation experience with the -04 version
>> of this draft was presented on an interim meeting:
>> https://datatracker.ietf.org/meeting/interim-2024-mpls-01/session/mpls.
>> That implementation was from Academia.
>>
>>
>>
>> As shown in the meeting materials, the implementors met some challenges
>> with the encodings in -04 version, they asked some questions and also gave
>> some proposals for possible optimization. As part of the WG LC, it would be
>> important to check whether the issues raised at that time have be addressed
>> by the latest version. It would be helpful if some feedback on the latest
>> version can be provided by those implementors.
>>
>>
>>
>> At IETF 120 I asked one question about the implementation report. Are we
>> aware of any other implementation of this document, besides the
>> implementation of the -04 version from Academia? This would be important to
>> gauge the maturity of the document and the interest in implementing it.
>>
>>
>>
>> Best regards,
>>
>> Jie
>>
>>
>>
>> *From:* Tarek Saad <tsaad.net@gmail.com>
>> *Sent:* Tuesday, September 24, 2024 9:25 PM
>> *To:* mpls@ietf.org
>> *Cc:* MPLS Working Chairs <mpls-chairs@ietf.org>;
>> draft-ietf-mpls-mna-hdr@ietf.org
>> *Subject:* [mpls] Working Group Last Call on draft-ietf-mpls-mna-hdr
>> (2nd WG call)
>>
>>
>>
>> Dear WG,
>>
>>
>>
>> This email starts a two-week Working Group last call for
>> draft-ietf-mpls-mna-hdr
>> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-hdr/>. This is the
>> 2nd WG last call for this document.
>>
>> Please indicate your support or concern for this draft. If you are
>> opposed to the progression of the draft to RFC, please articulate your
>> concern. If you support it, please indicate that you have read the latest
>> version, and it is ready for publication in your opinion. As always, review
>> comments and nits are most welcome.
>>
>>
>>
>> Please send your comments to the mpls WG mailing list (mpls@ietf.org)
>>
>> If necessary, comments may be sent unidirectional to the WG chairs.
>>
>>
>>
>> Note, currently there are 5 IPR disclosures against this document at
>> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr
>>
>>
>>
>> This poll runs until October 8, 2024.
>>
>>
>>
>> Thank you,
>>
>> Tarek (for the MPLS WG co-chairs)
>> _______________________________________________
>> 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
>