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

[Tony Li <[e-mail]>]

[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>