Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases-11


Document: draft-ietf-mpls-mna-usecases-11
Reviewer: Bruno Decraene
Review Date: 2024-09-02
Intended Status: Informational

Summary:
    I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.


Comments:

The document reads well and is interesting to read. Thank you.

I think that the document and the abstract should better indicate how use cases have been selected. In particular
 
- I think that the Abtract should better states how use cases have been selected (and rejected). Abstract has two sentences about this while one should be enough. And they differ ("community interest" vs "actively discussed"). Especially since some uses cases have been moved to appendix, and some of the uses cases could be read as "motivating MNA" while some could be read as "could (possibly) use MNA is MNA existed".

-  Ideally, each use case could better indicate which category it falls into. (e.g., it's difficult to assume that the Segment Routing use case (section 2.5) which has probably not been discussed in the SPRING WG is one use case motivating MNA work and implementation)


§1 Introduction
" The current state of the art requires allocating a new special-purpose label [RFC3032] or extended special-purpose label.  To conserve that limited resource, an MPLS Network Action (MNA) approach was proposed to extend the MPLS architecture."
I don't feel that extended special-purpose label is such a limited ressource. So you may want to rephase/split and indicate other reasons for MNA (e.g., stack size when multiple MNA are used in the same packet, common framework simplifying implementation...)

---
"This document lists various use cases that could benefit extensively from the MNA framework [I-D.ietf-mpls-mna-fwk]."

This reads as a normative reference to me. So I'd rather move the reference to normative. Alternative, you could rephrase to make the use case independent of the framework.

§1.1 Terminology

"The MPLS Ancillary Data (AD) is classified as:
residing within the MPLS label stack and referred to as In Stack Data (ISD), and
residing after the Bottom of Stack (BoS) and referred to as Post Stack Data (PSD)."

I'd rather say :s/and/or

§1.2.1. Acronyms and Abbreviations 
Thanks for expanding the acronym. But someone not familiar with the accronym may also not be familiar with the concept. So I think adding a refence to the RFC defining it would help.

Also GDF has been moved to appendix. Is is still necessary in this list?

§2.2.2. Alternate Marking Method 

Given that the MPLS WG already provided a solution for the use case, it would be good to indicate why this is still a use case to work on and why adding a second solution would be helpful.

§2.4. NSH-based Service Function Chaining 
"This approach, however, can benefit from the framework introduced with MNA "
It's not crystal clear to me what "this" refers to. e.g., RFC8595 or draft-ietf-mpls-mna-usecases? May be clarifying would help.

§2.5. Network Programming 
Has this Segment Routing use case been discussed in the SPRING WG? I don't recall so. This comes back to the question of how the use cases have been selected.

§3. Existing MPLS Use cases
This section is not clear to me. Is this expected to be count as use cases for MNA? Justifying MNA? Using MNA? (if so why would those existing MPLS use cases be changed to use MNA)
Could this be clarified.
--
"It is expected that new use cases described in this document will allow"
by "new" do you mean "additional uses case that will be descibed in the future" in which cases this seems unlikely after RFC publication. Or do you mean the new use cases described in this document. If so do you mean all use cases or a select number of use cases. If so may be they could be referenced in the sentence.

§4. Co-existence of the MNA Use Cases 

MPLS allows for hierarchy. e.g., with Carriers' carrier. It would be good for this section to cover the co-existence of MNA at multiple level of the hierarchy. e.g. how MNA can freely be used by the customer carrier without interference with the supporting carrier use of MNA. 

§6. Security Considerations

"This document introduces no new security considerations."

I think that the above point has security implications and that they should be covered in this section.

§ Appendix A. Use Cases for Continued Discussion 
Again, what are the considerations for moving some of the use cases to appendix?
If the only reason is ongoing discussion, shouldn't we wait for the conclusion of those discussions before publishing this document?

Thanks,
Regards,
--Bruno