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

[Greg Mirsky <[e-mail]>]

Dear All,
thinking about the mutability issue in MNA some more. I think that the
concern about the mutability of 20 LSBs of all defined LSE Formats for the
given packet needs more precise characterization. It seems that changing
value of 20 LSBs as the packet traverses the MNA domain by itself doesn't
cause potential out-of-order situation. Only if the value of 20 LSBs is
different on the same node for the same LSE, then hashing on the label
stack may produce different result causing the packet being forwarded along
different paths. WDYT? In other words, if a node changes value in the same
manner for all packets, that would not cause packet being forwarded over
different paths in ECMP. But carrying a sequence number or a timestamp -
may cause out-of-order delivery in the ECMP environment.
Am I missing something?

Regards,
Greg

On Tue, Sep 24, 2024 at 12:21 PM Greg Mirsky <[e-mail]> wrote:

> Dear All,
> I've read the latest version of the draft. It is a pleasure to read (thank
> authors!) and it provides a practical mechanism that can be used to support
> use cases documented in draft-ietf-mpls-mna-usecases
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/>. I
> support the publication of the draft.
> Below, please find my notes (mostly nits):
>
>    - Abstract
>       - Some abbreviations seem unnecessary - OAM, ISD
>       - On the other hand, MNA abbreviation is introduced in the first
>       sentence. It may be used after that throughout the Abstract. Alternatively,
>       may use the extended form "MPLS Network Action(s)" throughout the Abstract
>    - Introduction
>       - May use 'AD' after is introduced in the first paragraph.
>       Repeating that in the second paragraph is unnecessary.
>       - In your opinion, what is the value of "User-defined network
>       actions allow new, local actions to be defined."? Note that user-defined
>       actions are not discussed anywhere else in the document.
>    - Abbreviations
>       - Perhaps the expanded form of MNA is singular as 'MPLS Network
>       Action', and plural would be MNAs. WDYT?
>       - Perhpas a minor modification in capitalization of NAS and
>       its varians as "Network Action Sub-stack" (with the capitalized 'Stack'
>       should the abbreviation be NASS?)
>    - Section 5.2
>       - What is the value of the last paragraph:
>
>    If a network action needs to encode more data that might need to
>
>    change during packet forwarding it will need to use a stack of Format
>
>    D LSEs (Section 4.3) (which may be inefficient) or post-stack
>
>    ancillary data (which is beyond the scope of this document).
>
> That paragraph picks only one of scenarios related to AD mutability
> (another - changing AD among packets in the same flow). Furthermore,
> immutability of 19 LSBs of the Data field in LSE Format D is essential only
> in ECMP environment (e.g., DetNet does not use load-balancing) and in the
> network in which nodes use the label stack to generate entropy rather than
> Entropy Label. I think that the mutability/immutability of AD might be
> discussed in documents that describe solutions based on MNA. It seems the
> paragraph can me removed without losing any value in the document.
>
>
>    - Section 7
>       - Using the future tense in the two first sentences seems
>       unwarranted. PErhaps these can be edited as follows:
>
> OLD TEXT:
>    The node adding an NAS to the label stack will need to place a copy
>    of the NAS where it can be read by the relevant nodes.  Each
>    downstream node along the path will have a Readable Label Depth (RLD)
>    [I-D.ietf-mpls-mna-fwk].
> NEW TEXT:
>    The node adding an NAS to the label stack places a copy
>    of the NAS where the relevant nodes can read it.  Each
>    downstream node along the path has a Readable Label Depth (RLD)
>    [I-D.ietf-mpls-mna-fwk].
>
>
>    - Section 9.2
>       - The mutability of 20 LSBs considered only from the PoV of the
>       packet traversing the MPLS network. As noted above, to avoid out-of-order
>       delivery for the same MPLS flow, 20 LSBs must be immutable among packets in
>       the same MPLS data flow.
>    - Section 15
>       - The firsrt field in Figure 7 is tagged differently
>       "MNA-Label=bSPL (TBA)" from Figures 5, 6, 8, 9, and 10. Personally, I like
>       Figure 7-style better.
>
> Regards,
> Greg
>
> On Tue, Sep 24, 2024 at 6:25 AM Tarek Saad <[e-mail]> wrote:
>
>> 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]
>>
>