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

[Greg Mirsky <[e-mail]>]

Hi Tony,
thank you for correcting my mistake.
I agree that the mutability requirement should be replaced with the
requirement to use all the necessary measures to prevent the flow
reordering.

Regards,
Greg

On Tue, Sep 24, 2024 at 5:42 PM Tony Li <[e-mail]> wrote:

> [WG chair hat: off]
>
> Hi Greg,
>
> First, if you refer to RFC 3032, the label is in the 20 most significant
> bits of the LSE, so it’s MSB, not LSB.
>
> Changing a value in the label field of an LSE could easily result in a
> modified hash result and subsequently a different forwarding path. That
> alone does not necessarily result in reordering within a flow, which is the
> real issue that is to be avoided.  To avoid reordering, we need the hash
> result to be a constant within a flow. That should be our first and
> strongest requirement.
>
> That alone, however, may not be sufficient in all cases.  Even if flow
> ordering is preserved, changing hash results could cause multiple flows to
> interact downstream. This has the consequence that it might cause
> congestion downstream that was not seen previously.  It could also equally
> likely alleviate congestion by separating flows.  Thus, I think that the
> real question is whether we feel that traffic patterns must be identical
> both before and after MNA operation that was not intended to affect the
> traffic pattern.
>
> In my experience, someone will be upset by this, but I don’t think that
> it’s serious enough to make it a mandatory requirement.  Only preventing
> flow reordering should be the requirement.
>
> T
>
>
>
> On Sep 24, 2024, at 4:15 PM, Greg Mirsky - gregimirsky at gmail.com <
> [e-mail]> wrote:
>
> 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]
>>>
>>
>