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

[Alexander Vainshtein <[e-mail]>]

Greg,
Lots of thanks for your input.

I would like to clarify that my comments – both in the review and in the follow-up emails – are not about “selecting between ISD and PSD MNA solution”.

I have been only trying to assure that nothing in the MNA requirement draft could be (mis)interpreted as bias in favor of one of these solutions.

I suspect (and this may be my personal feeling) that the requirements like “MNA solutions MUST NOT increase the size of the MPLS label stack more than is necessary” (item#7 in Section 3.1 of the draft<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-06#section-3.1>) may be interpreted as a bias in favor of PSD solution since, to the best of my understanding an ISD solution cannot be more effective than an equivalent PSD solution from the POV of increase of the depth of the label stack. This is why I have been asking to clarify that no bias is intended by this requirement. Of course, it may will be that my imagination simply runs wild…

Hope these notes help.

Regards,
Sasha

From: Greg Mirsky <[e-mail]>
Sent: Monday, August 28, 2023 10:14 AM
To: Alexander Vainshtein <[e-mail]>
Cc: Matthew Bocci (Nokia) <[e-mail]>; [e-mail]; [e-mail]; MPLS Working Group <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [mpls] RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05

Hi, Sasha, Matthew, et al.,
I have an observation to share that might be relevant to the discussion of selecting between an ISD or PSD MNA solution. It seems to me that we are often concerned with the possible impact of a NAS on the size of the label stack when using ISD MNA with AD. When that is the case, moving a large block of AD into PSD, particularly when the MNA scope is HbH, doesn't seem to elevate the problem. So, my suggestion would be to seek other solutions, including disaggregation of functions, to go beyond mere comparison of ISD vs. PSD MNA.

Regards,
Greg

On Sun, Aug 27, 2023 at 7:14 PM Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Matthew and all,
My sincere apologies for a much-delayed response – somehow, I have missed your email.
Please see my responses to your comments marked <MB2> inline below. In some cases these comments refer to the changes done in the -06 version of the draft.

Regards,
Sasha

From: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 19, 2023 6:25 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; MPLS Working Group <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05

Hi Sasha

Please see below for further responses, prefixed by MB2.

Regards

Matthew

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 16 July 2023 at 11:43
To: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, MPLS Working Group <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: RTG-DIR Early review: draft-ietf-mpls-mna-requirements-05

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information.


Mathew,
Lots of thanks for a prompt response.

Please see some comments inline below.

Regards,
Sasha

[snip]

From: rtg-dir <[e-mail]<mailto:[e-mail]>> on behalf of Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 6 July 2023 at 07:41
To: MPLS Working Group <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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://clicktime.symantec.com/15t5eifvppF3oNDJe6YAr?h=1UnUGEPuji-PF4Mor-R2LQjBlUredyVVjIKwCHWkt1k=&u=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<https://clicktime.symantec.com/15t6QCRUxMPPWsecY88WS?h=nWAQ6rytFdiT4w-kZaa8TPxvEVTXa2z6KuWAfUsGPHY=&u=https://wiki.ietf.org/en/group/rtg/RtgDir>



Document: draft-ietf-mpls-mna-requirements-05<https://clicktime.symantec.com/15t5eifvppF3oNDJe6YAr?h=1UnUGEPuji-PF4Mor-R2LQjBlUredyVVjIKwCHWkt1k=&u=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.
[[Sasha]] My point was not about usage or non-usage of RFC 2119 language in Informational RFCs, but about consistency of their usage.
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..."
[[Sasha]] Looks fine to me.

MB> I will look through and clean up the other cases where there could be ambiguity. [[Sasha]] OK
[[Sasha]] I have looked up the -06 version, and this issue is fully resolved now.

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://clicktime.symantec.com/15t5z3T4fGyRT9WzpL8mL?h=MemY0VeCiE7ytuB6QEqEhRpjp6Q6t_tR0d185QssSmo=&u=https://datatracker.ietf.org/doc/html/rfc3031> and RFC 3032<https://clicktime.symantec.com/15t64seM7tf1s6LvMtXux?h=GBClyeHz62Vz2C5duIXGnBN8dWa1MBdoaTvb2LyC9K0=&u=https://datatracker.ietf.org/doc/html/rfc3032> as the references for the MPLS architecture, but it does not mention RFC 5331<https://clicktime.symantec.com/15t69hqdaWLcH3AquSw4a?h=VbBs9nfdGK_QmRhX4YpOBn-2sUmp9RV8d9CUv1eGY3o=&u=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.
 [[Sasha]] I have looked up the -06 version, and this issue is fully resolved now.


2.       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?
[[Sasha]] Please note that the first problematic (from my POV) item appears in Section 3.1., so adding another requirement in Section 3.4 may be too late. Any text that eliminates any suggestion of bias towards In-stack or Post stack ancillary date would do.

             MB2> Here is the text of the requirement from Section 3.1: “7.   MNA solutions MUST NOT increase the size of the MPLS label stack more than is necessary.” It is simply saying that the whole solution must not bloat the label stack. There are well known engineering consequences of this. I do not think it is biased against in-stack data. The term “…more than is necessary” is key, and the text of this requirement was crafted following a long discussion within the OpenDT. It is simply saying that the choices made when solving a particular use case must consider the impact on the label stack size and the consequences of such an impact on the viability of the solution. Those choices will include the size of other elements such as the MNA sub-stack, not just the ancillary data. Regarding in-stack vs post-stack, some use cases are better solved with in-stack (indeed that may be the only viable solution given the MPLS architecture), but some may require such large amounts of AD that in-stack is not practical. We should not infer a precedence in the requirements based on the order they appear in the document.
[[Sasha]] I agree that in-stack data is not explicitly precluded, but its usage, by definition, increases the label stack. I still think that a note saying that “A solution MAY choose to use in-stack ancillary data, or it MAY choose to use post-stack ancillary data” would be nice, but I see that it is not present in the -06 version.



3.       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.
[[Sasha]] I assume this means the MNA Framework draft<https://clicktime.symantec.com/15sLvStzeEHuS3Zcu4Sk9?h=HdZvEDu4aZzSX6DlcBlnkwj5Yi3Q9d0x7Gzr0PRrM5U=&u=https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-03>. If so then:
MB2> yes

•       This document is not referenced in the draft under review, but the need to cross-check with the framework draft appears as an Editor’s comment in Section 1.1.
MB2> Thanks for spotting that ed note. This needs to be removed. The intent was that the base terminology would be defined in the requirements, and any additional terminology not needed by the requirements draft but necessary for the framework draft be specified in the framework. The framework draft references the requirements draft accordingly. The intent with the ed note was as a reminder that we need to make sure the definition of NA used in both drafts is consistent.
[[Sasha]] It has been indeed removed in the -06 version.

•       After briefly looking up the framework document, it seems that this Editor’s comment highly relevant. I have to admit that I have completely missed this aspect in my original review.

•       The framework document explicitly states in Section 2.4 that “A network action sub-stack should never occur at the top of the MPLS label stack”. This addresses (in a way) my original question but seems to be in contradiction with item#3 in Section 3.1 of the requirements draft. Spreading these statements to two different documents looks problematic to me.


MB2> I think  this relates to the intent of the requirements draft (to set general requirements on the protocol architecture and solutions), and the framework to define the architectural components and how they relate. C.f. previous examples of this kind of split, e.g. RFC5654 and RFC5921. In that MPLS-TP case, there is no downref from the requirements to the framework. I read the requirement you quote as a constraint on a specific architectural element defined in the framework, rather than a general requirement, so I think it is fine where it is.
[[Sasha]] If NAI in the middle of the label stack can be acted upon by an LSR parsing this stack, this violates the quoted architectural principle from RFC 3031. Maybe this deserves an explanation – say, in a note to item#3 in Section 3.1?

4.       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://clicktime.symantec.com/15t6EY2v382CgyzmT1LDC?h=ASF8btND7Cmbc3GuSzm5I2JYqEU6Devc47aH5geanVE=&u=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. [[Sasha]] I have not found this clarification in the -06 version.


5.       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.
[[Sasha]] This is probably a misunderstanding, since my question was about ISIS, OSPF and BGP extensions for SR-MPLS. It seems that you consider these protocols as relevant for the purpose of items #8 and #9 in Section 3.3 – and I am OK with this.

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

a.       As mentioned above,. this statement does not carry any IETF keyword (MUST or SHOULD) to indicate the requirement level

b.       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. [[Sasha]] This issue has been fully resolved in the -06 revision.

7.       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://clicktime.symantec.com/15t6KNECVjho6vpgzZjMp?h=y3AD-V2HObWjkAAAjkI9xG6PHnHTKWuoK4b23v4CfNw=&u=https://datatracker.ietf.org/doc/html/rfc9256>) that uses Binding SIDs in its list of segments?

a.       Usage of Binding SIDs makes control over the depth of the label stack quite problematic for the head-end of an SR Policy

b.       Another case when such control is problematic is usage of TI-LFA<https://clicktime.symantec.com/15t5pP4Vk3cEdFs9jDLU6?h=U621AneHaXJniuLaEWeSXsT5-gkPPU5u1NnqWPkt8TI=&u=https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa> or Segment Routing Micro-loop Avoidance<https://clicktime.symantec.com/15t5ZtUeNCZTPRPP6Y92E?h=q5UnvrjvwvNlCl9GwWmGaGFWh1Vry-VgAAemivSHsmw=&u=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.
[[Sasha]] Item #6 in Section 3.1 says: “Any MNA solution specification MUST discuss the ECMP consequences of the design.”  I think that a similar statement about the need to discuss consequences of technologies that increase the depth of the label stack in a way that is not controlled by the ingress LER for this stack would be very much in place.
            MB2> I agree with you. Can you propose text for a new requirement to address this?
[[Sasha]] What about “Any MNA specification MUST discuss the impact existing of well-known  MPLS applications that increase the depth of the label stack in a way that is not controlled by the ingress LER on the design”? New item#8 in Section 3.1 of the -06 version says something else IMHO.

NITS:

1.       The draft refers to draft-saad-mpls-miad-usecases<https://clicktime.symantec.com/15t5uDFnCfHq3Ch5Gmjci?h=wW6aacU_3fuTfYzsEw6nm1auGy0FPky1G_LePNIkcEQ=&u=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://clicktime.symantec.com/15t5jYsDHRveDK3EBewKU?h=74XbZnPK6Fuw4rBCst1Q73XWFmYx3IhTylhn6aPImp0=&u=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 [[Sasha]] This issue has been fully resolved in the -06 version.

2.       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.
_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>