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

[Gyan Mishra <[e-mail]>]

Hi Greg

I agree the two RFCs IOAM DEX RFC 9326 and IOAM Data both do not have a
requirement stated for mutable IE.

See MPLS ML archive from from this past summer and the MPLS interim link to
presentation by Michael Menth on this topic of IOAM and PSD feasibility
which was tested on Tofino programmable asic using P4 and described in
detail in the slide deck slide 15 excerpt below:

https://mailarchive.ietf.org/arch/msg/mpls/AXZOx0IeKAdZdQA6ZsbgcgNNvqs/


https://datatracker.ietf.org/meeting/interim-2024-mpls-01/materials/slides-interim-2024-mpls-01-sessa-implementation-experience-of-mna-using-p4-on-intel-tofino-hardware-00.pdf


 Mutable data in MNA Only the last 8 bits in an LSE are mutable due to ECMP
hashing compatibility Modifications to mutable data in HBH scopes must be
reflected in all HBH copies in the stack
HBHLabelPreservationfixesthis,butonlyworksifallnodessupportMNA. PSD solves
the issue with mutable data in the HBH NAS replication example PSD not
hashed for ECMP: All bits are mutable  Mutable data kept in one place:
post-stack no copying across different NAS But can it be implemented
efficiently? Challenge:HowtogettoPSD? a) Jump over the MPLS stack to the
end using a pointer or lookahead b) Parse the full MPLS stack In P4 we have
to parse the full stack!


The slide 15 above  talks about mutable data in MNA

>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 example shows how PSD use case for E2E similar to DOH options EH
processing such as use case for IOAM, where ISD use case is for HBH EH
processing for example entropy label ELI/EL per steered hop.

Therefore shows the benefit of PSD with IOAM over ISD.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Sun, Sep 29, 2024 at 12:05 PM Greg Mirsky <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>>
>>
>> On Sun, Sep 29, 2024 at 1:24 AM Zafar Ali (zali) <zali=
>> [e-mail]> 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=[e-mail]>
>>> *Date: *Thursday, September 26, 2024 at 7:48 PM
>>> *To: *Dongjie (Jimmy) <jie.dong=[e-mail]>, Tarek
>>> Saad <[e-mail]>, [e-mail] <[e-mail]>
>>> *Cc: *MPLS Working Chairs <[e-mail]>,
>>> [e-mail] <[e-mail]>
>>> *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=[e-mail]]
>>> *Sent:* Friday, September 27, 2024 12:28 AM
>>> *To:* Tarek Saad <[e-mail]>; [e-mail]
>>> *Cc:* MPLS Working Chairs <[e-mail]>;
>>> [e-mail]
>>> *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 <[e-mail]>
>>> *Sent:* Tuesday, September 24, 2024 9:25 PM
>>> *To:* [e-mail]
>>> *Cc:* MPLS Working Chairs <[e-mail]>;
>>> [e-mail]
>>> *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 ([e-mail])
>>>
>>> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
>> mpls mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>