[RTG-DIR]Rtgdir last call review of draft-ietf-mpls-mna-usecases-11

[Bruno Decraene via Datatracker <[e-mail]>]

Reviewer: Bruno Decraene
Review result: Has Issues

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