Re: [mpls] RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05

["Matthew Bocci (Nokia)" <[e-mail]>]

Hi Sasha

Thank you very much for your detailed review.

Please see below for some responses, prefixed by MB>.

Regards

Matthew

From: rtg-dir <[e-mail]> on behalf of Alexander Vainshtein <[e-mail]>
Date: Thursday, 6 July 2023 at 07:41
To: MPLS Working Group <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [RTG-DIR] RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05



Hello

I have been selected to do a routing directorate “early” review of this draft: draft-ietf-mpls-mna-requirements-05<https://datatracker.ietf.org/doc/html/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<https://datatracker.ietf.org/doc/html/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.
MB> There is plenty of precedent for informational RFCs to contain RFC2119 language, and speaking as a co-author it seems reasonable here when we are setting out the requirements for protocol development.
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”).

MB> I agree that one is unclear. I think where we are not with the solutions, it would
make sense to change 'normally' to MUST only be. SOme thing like "If NAIs are inserted in
a label stack, they MUST only be inserted at the ingress LER for that label stack, and they MAY be processed..."

MB> I will look through and clean up the other cases where there could be ambiguity.

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<https://datatracker.ietf.org/doc/html/rfc3031> and RFC 3032<https://datatracker.ietf.org/doc/html/rfc3032> as the references for the MPLS architecture, but it does not mention RFC 5331<https://datatracker.ietf.org/doc/html/rfc5331> 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.

MB> Agreed. I will add a reference.


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

MB> I am not sure it says that, and if in-stack was not allowed then we would have a requirement that says so.
Maybe what we could add  "A solution MAY choose to use in-stack ancillary data, or it MAY
choose to use post-stack ancillary data." as a first requirement in 3.4?



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

MB> That may be better suited to the framework draft.


  1.  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<https://datatracker.ietf.org/doc/html/rfc7274>. (This comment is based on the discussion of re-use of GAL for MNA in the early days of the MPLS Open Design Team).
MB> I agree this is a useful clarification.

  1.  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?
MB> No. SR-MPLS is not a control plane protocol, although it may use a control plane protocol. The control plane protocols that can signal MPLS labels whether for segment routing or other cases that use an MPLS data plane include LDP, RSVP, BGP, ISIS, OSPF... and there are numerous out of band mechanisms for programing labels like SNMP, Netconf, etc. I do not think there is any need to define what we mean by control plane protocols in this draft.

  1.  Item #12 in Section 3.3 states that “NAIs are normally inserted at LERs “:

     *   As mentioned above,. this statement does not carry any IETF keyword (MUST or SHOULD) to indicate the requirement level
     *   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)

MB> See my response above.

  1.  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<https://datatracker.ietf.org/doc/html/rfc9256>) that uses Binding SIDs in its list of segments?

     *   Usage of Binding SIDs makes control over the depth of the label stack quite problematic for the head-end of an SR Policy
     *   Another case when such control is problematic is usage of TI-LFA<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa> or Segment Routing Micro-loop Avoidance<https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15> mechanisms.
MB> I agree with you that this is a problematic case. Any inter-domain case (which is a common application of BSIDS) or cases where the label stack is expanded using SR policies with BSIDS is an issue. As are tunnel-in-tunnel cases like LDP over RSVP/SR-TE, BGP-LU over RSVP/SR-TE, etc. I think the requirement is still valid, and we probably don't need to say anything more in a requirements document. It is up to the solutions to solve the problem.
NITS:

  1.  The draft refers to draft-saad-mpls-miad-usecases<https://datatracker.ietf.org/doc/html/draft-saad-mpls-miad-usecases-02> 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<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-usecases> that is a MPLS WG document.  IMHO the reference should updated accordingly.
MB>Agreed

  1.  I did not run the ID Checker on the draft, so could have missed other nits.
MB> It passes.

Hopefully, these notes will be useful.
Regards,
Sasha



Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.