Hello
I have been selected to do a routing directorate “early” review of this draft: draft-ietf-mpls-mna-requirements-05.

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

The draft in question is a WG document, has been adopted about 1 year ago and is not yet in the WG Last Call. It has been extensively discussed in the MPLS Open Design Team. 
I have asked Loa (who is the shepherd of this draft) for the reasons for and the purpose of this review, and he has said that the draft “is a going into the WGLC process, we want the comments early, i.e.  before we start the WGLC, after all it is supposed to be "early", after the WGLC is too late in the process. Better to have the RTG Area Early comments fully available to the WG during the WGLC ”.
For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-mpls-mna-requirements-05
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 06-Jul-23.
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 draft is well written and easy to read.
As the title clearly states, this draft presents generic requirements that should be met by any specific MPLS Network Actions (MNA) solutions.
As a generic comment, I am not sure whether the IETF reserved terms for indication of requirement levels can be used in an Informational document, this is for the WG Chairs and ADs to decide.
But I think that usage – or non-usage – of these terms should be consistent in the document, and this condition is not met in this draft. 
It contains:
-	Requirements that use the reserved IETF keywords (e.g., “Any MNA solutions to these requirements MUST NOT restrict the generality of MPLS architecture”)
-	Requirements that use the non-capitalized words that, in their capitalized form, become the IETF keywords (e.g., “An MNA solution MUST respect the principle that Special Purpose        Labels are the mechanism of last resort and therefore must minimize the number of new SPLs that are allocated“). Having a mix of capitalized and non-capitalized terms in the same requirement looks problematic to me
-	Requirements that do not include any words that can be associated with the IETF reserved keywords (e.g., “NAIs are normally inserted at LERs, but MAY be processed at LSRs and LERs”). 
I have sent my early comments to the draft authors, and they suggested that these should be submitted as the RTG-DIR review without any private discussions. I am following this suggestion after adopting these comments to the RTG-DIR Early review template format.
MAJOR ISSUES: 
None found.

MINOR ISSUES:
1.	The draft mentions RFC 3031 and RFC 3032 as the references for the MPLS architecture, but it does not mention RFC 5331 that augments MPLS architecture with upstream-allocated labels,  label context spaces and “context labels”. Does this mean that MNA is expected to be incompatible with upstream-allocated labels and/or context label spaces? If yes, it would be nice to have this stated explicitly.
2.	Item #7 in Section 3.1 as well as items #2 and #3 in Section 3.4 seem to imply preference to Post-stack ancillary data vs. In-stack one. Is this really the intention? If not, please consider stating explicitly that these requirements do not preclude usage of In-stack ancillary data.
3.	Section 3.9 of RFC 3031 states that “the processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present”.  (This principle has been tweaked when “context labels” have been introduced in RFC 5331.)  IMHO and FWIW, it would be useful to explain what should happen to this architectural principle with regard to MNA.
4.	I suggest augmenting item #3 in Section 3.2 with a statement that reuse of an already allocated SPL for MNA purposes would require its retirement and re-allocation in accordance with the process defined in RFC 7274. (This comment is based on the discussion of re-use of GAL for MNA in the early days of the MPLS Open Design Team).
5.	Do items#8 and #9 in Section 3.3 consider SR-MPLS as one of the relevant control plane protocols? May I suggest that an explicit list of such protocols be provided to avoid any possible misunderstandings?
6.	Item #12 in Section 3.3 states that “NAIs are normally inserted at LERs “:
a.	As mentioned above,. this statement does not carry any IETF keyword (MUST or SHOULD) to indicate the requirement level
b.	I suspect that normality, like beauty, is in the eye of the beholder. A more suitable wording could be “LSRs SHOULD NOT insert NAI” (or something like that)
7.	Can you please clarify whether the requirement in item#10 of Section 3.4 can be addressed by an LER that is a head-end of an SR Policy (RFC 9256) that uses Binding SIDs in its list of segments?  
a.	Usage of Binding SIDs makes control over the depth of the label stack quite problematic for the head-end of an SR Policy
b.	Another case when such control is problematic is usage of TI-LFA or Segment Routing Micro-loop Avoidance mechanisms. 
NITS:
1.	The draft refers to draft-saad-mpls-miad-usecases for the description of new MPLS use cases (both in the Introduction and Background sections). According to the Datatracker this draft has been replaced by the MNA Usecases draft that is a MPLS WG document.  IMHO the reference should updated accordingly.
2.	I did not run the ID Checker on the draft, so could have missed other nits.
Hopefully, these notes will be useful.
Regards,
Sasha