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

[Greg Mirsky <[e-mail]>]

Hi Bruno,
thank you for the detailed feedback and helpful suggested changes. Please
find my follow-up notes below tagged GIM2>>. I've attached the diff that
reflects all updates we discussed.

Regards,
Greg

On Wed, Sep 11, 2024 at 7:26 AM <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Thank you for your replay and constructive suggestion.
>
> Please see inline [Bruno]
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Friday, September 6, 2024 1:19 AM
> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [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.
>
>
>
> [Bruno] OK.
>
>
>
> 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?
>
>
>
> [Bruno] I was proposing that use cases be split between:
>
>    1. uses cases justifying the creation of MNA
>    2. uses cases that would use MNA once MNA was available.
>
>
>
> Because probably network operator and vendors are primarily interested in
> uses cases strong enough to motivate the investment in a new technology. At
> least that’s what I was looking for and section 2.5 did not seem like a
> strong reason to me so the use case could even be read as counter
> productive by some people (“if this is the use case for MNA, then I don’t
> really need MNA).
>
> But that’s just a feedback. I understand that different people may have
> different on each use case which make my comment difficult to address. So,
> up to you.
>
> No, I was not suggesting to remove a use case.
>
GIM2>> Thank you for sharing your perspective. The document has changed
from what it was when the MPLS WG adopted it. All updates were presented,
discussed by the WG, and, as I understand it, changes agreed to. Although
no specific document describes in more detail how MNA could be used in
support of the network programming paradigm, I think that the WG indicated
interest in this use case by supporting the publication of the document
during the WG LC.

>
>
>
>
>
>
>
> §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.
>
>
>
> [Bruno] I couldn’t spot any difference between your above OLD and NEW.
> Looking at the diff you provided (thanks, much useful), new text seems
> better but it removes one technical argument/reason in favor of MNA.
>
> Personally I had in mind the following change:
>
>
>
> OLD: To conserve that limited or extended special-purpose label.  An MPLS
> Network Action (MNA)
>
> NEW: SPL are a very limited resource while eSPL requires two extra label
> per Network Action which is expensive. Therefore an MPLS Network Action
> (MNA)
>
GIM2>> Thank you for the clear and crisp proposed text. I applied it
resulting in the following;
NEW TEXT:
  The current state
   of the art requires allocating a new special-purpose label (SPL)
   [RFC3032] or extended special-purpose label (eSPL).  SPLs are a very
   limited resource, while eSPL requires an extra Label Stack Entry per
   Network Action, which is expensive.  Therefore, an MPLS Network
   Action (MNA) [RFC9613] 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.
>
>
>
> [Bruno] OK, thanks.
>
>
>
>
> §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.
>
>
>
> [Bruno] TBH, being non-native, I don’t really know, so totally up to
> you/RFC editor.
>
> FYI, while it’s a very biased search 😉, I could find example with “or”.
> e.g., “Non-Standards Track RFCs may be classified as Informational or
> Experimental.“ https://www.ietf.org/process/informal/
>
GIM2>> I am non-native too. I will follow suggestions from the IESG reviews
and rely on the RFC Editor's guidance.

>
>
>
> §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.
>
>
>
> [Bruno] OK. Anyway it’s an editorial choice so up to you.
>
>
>
>
> Also GDF has been moved to appendix. Is is still necessary in this list?
>
> GIM>> I agree; removed.
>
>
>
> [Bruno] Ack.
>
>
>
>
> §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.
>
>
>
> [Bruno] Thanks for clarifying to me. I feel that the above clarification
> would be useful in the draft and would better motivate the creation of MNA
> (rather than the current: “The MNA is an alternative mechanism that can be
> used to support AMM in the MPLS network.” which reads as creating a second
> solution for no extra benefit.)
>
> But up to you.
>
GIM2>> Thank you for your kind consideration. AFAICS, the discussion of
draft-ietf-mpls-inband-pm-encapsulation
<https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/>
continues.
We will follow it and will align this document accordingly once the final
text is settled.

>
>
>
> §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].
>
>
>
> [Bruno] ok, thanks.
>
>
>
>
> §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.
>
>
>
> [Bruno] OK, thanks for the clarification. I read your answer as a ‘No’
> (this Segment Routing use case has not been discussed in the SPRING WG.)
>
>
>
>
> §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.
>
>
>
> [Bruno] Thanks for the clarification. If that’s the intention I would not
> call that section a “use case”. At minimum I propose to change the title of
> this section
>
> OLD: Existing MPLS Use cases
>
> NEW: Co-existence with existing MPLS extensions
>
GIM2>> Thank you for suggesting a clearer title for the section. I updated
it accordingly

>
>
> The above proposition tries to be aligned with the title of the next
> section. That being said, all the MPLS extensions defined in §3 seems to be
> classified as Post Stack Data (PSD) (as per §1.1). If so, I’d rather
> propose
>
> NEW2: Co-existence with existing MPLS Post Stack extensions
>
>
>
> (I tried to avoid using the term PSD... Obviously please feel free to
> reword)
>
GIM2>> Would the follwoing work:
NEW TEXT:
Co-existence with the Existing MPLS Services Using Post-Stack Headers

>
>
>
> §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.
>
>
>
> [Bruno] Fair enough, I guess. But its seems that the point could at least
> be raised.
>
> I still believe that MNA introduces security consideration including for
> existing network (in particular with Carrier’s Carrier deployment) if MNA
> is activated by default on equipments. I.e. there is no MNA deployment done
> but MNA is exploited by unauthorized person which previously where shielded
> through MPLS hierarchy
>
>
>
> Cf  VPN security text “unless it is known that
>
>          such packets will leave the backbone before the IP header or
>
>          any labels lower in the stack will be inspected,”
>
>
>
> https://datatracker.ietf.org/doc/html/rfc4364#section-13.1
>
>
>
> with MNA the lower labels are inspected even if they will never appear at
> the top of stack.
>
GIM2>> I think that the question of activating, using MNA in an MPLS domain
deserves thorough analysis. I imagine that MNA would not be enabled by
default but only after the MNA-capabilities have been discovered.

>
>
> Regards,
>
> --Bruno
>
>
>
>
> §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
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>