[mpls] Re: Rtgdir last call review of draft-ietf-mpls-mna-usecases-11

[Greg Mirsky <[e-mail]>]

Hi Bruno,
thank you for your thorough review, constructive comments, and helpful
suggestions. Please find my notes below tagged by GIM>>. I attached the new
working version of the draft and the diff that highlights all the updates.

Regards,
Greg

On Mon, Sep 2, 2024 at 4:53 AM Bruno Decraene via Datatracker <
[e-mail]> wrote:

> 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.
>
GIM>> Thank you for your kind words, Bruno.

>
> 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").
>
GIM>> I think that "community interest" describes the attitude towards MNA
work in general, while "actively discussed" is intended to reflect the
situation with the use cases.

> Especially since some uses cases have been moved to appendix,

GIM>> Indeed, over the course of the discussion, the feedback received from
groups that work with the MPLS data plane indicated that theese groups have
not yet reached consensus on the proposed solutions. The authors proposed
moving these cases to the appendix rather than removing them altogether for
the historical value. It appears that the WG agreed and supported that
update.

> 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".
>
GIM>> I agree that some use cases, e.g., NOFRR, can be realized by using an
assigned SPL. Some other use cases also can be supported by assigning a
dedicated SPL. As the available number of bSPLs is limited, it is very
likely that the respective solutions will use eSPL, i.e., two LSEs. In that
regard, MNA improves utilization of SPL space.

>
> -  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)
>
GIM>>  Yes, although the use case described in Section 2.5 seems useful, I
also cannot find a document on that topic that have been submitted for the
discussion by SPRING WG. Do you propose removing this section?

>
> §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...)
>
GIM>> Would the following updated text be clearer:
OLD TEXT:
   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.  MNA is expected to enable functions
   that may require carrying additional ancillary data within the MPLS
   packets, as well as a means to indicate the ancillary data is present
   and a specific action needs to be performed on the packet.
NEW TEXT:
   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.  MNA is expected to enable functions
   that may require carrying additional ancillary data within the MPLS
   packets, as well as a means to indicate the ancillary data is present
   and a specific action needs to be performed on the packet.

>
> ---
> "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.
>
GIM>> Thank you for the suggestion. I moved it to the Normative References
list.

>
> §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
>
GIM>> I think that "and" is appropriate in characterizing two types of MPLS
Ancillary Data. But I noticed hypen missing in ISD and PSD. Fixed these.

>
> §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.
>
GIM>> I know that some documents provide references in Abbreviation
section. I find that references in the body of the document is sufficiently
useful to a reader.

>
> Also GDF has been moved to appendix. Is is still necessary in this list?
>
GIM>> I agree; removed.

>
> §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.
>
GIM>> As I understand it, the WG decided that the publication of
draft-ietf-mpls-inband-pm-encapsulation
<https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/> is
to fix squatting of the code point and the MNA-based solution will be
considered:
   Considering the MPLS performance measurement with the Alternate-
   Marking method can also be achieved by MNA encapsulation, it is
   agreed that this document will be made Historic once the MNA solution
   of performance measurement with the Alternate-Marking method is
   published as an RFC.

>
> §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.
>
GIM>> I hope that the following update makes it clearer:
NEW TEXT:
   The approach in [RFC8595] introduces some limitations discussed in
   [I-D.lm-mpls-sfc-path-verification].  However, that approach can
   benefit from the framework introduced with MNA in
   [I-D.ietf-mpls-mna-fwk].

>
> §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.
>
GIM>> The work on MNA was first conducted by the Open DT chartered by MPLS,
PALS, and DetNet WGs. Once fundamental MNA documents matured, they were
adopted by the MPLS WG. After that MNA work, as I understand it, has been
conducted as part of MPLS WG agenda.

>
> §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.
>
GIM>> That section is intended as the reminder to the authors of drafts
that propose MNA-based solutions for the use cases listed in this document
as well as for any applications in the future. I agree that "new" is
confusing in the sentence. I propose the following update:
NEW TEXT:
   MNA-based solutions for the use cases described in this document and
   proposed in the future are expected to allow for coexistence and
   backward compatibility with all existing MPLS services.

>
> §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.
>
GIM>> I think that the the questions of MNA deployment are outside the
scope of the document that is aimed at listing generic use cases that
benefit from MNA. Deployment of MNA-based solutions should be discussed in
respective drafts that define the solution for the particular case listed
in this document.

>
> §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
>
>
>