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

[[e-mail]]

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]<mailto:[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.




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



---
"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/


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


§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

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)


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

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.