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

[IJsbrand Wijnands <[e-mail]>]

Hey Greg,

> thank you for the clarification, that helps me to get a more complete picture. I might have a slightly different opinion in regard to the efficiency of MNA when comparing ISD and PSD solutions. IMHO, PSD will always be a less efficient overall solution performance-wise as it, as I understand it, will also require NAI in ISD. Furthermore, if the access of AD is a concern, AD in PSD would require a larger cache memory support to sustain line-rate processing. But, by all means, each use case should be thoroughly 

This is the part I’m not getting. If you use PSD, you’ll need a single NAI and you can encode your AD just below the bottom (NAI) label. Assume we’ll use 4 bytes for the AD (could be like a sub-stack encoding). That means the packet header has increased with 8 bytes. If you use ISD, you also need a NAI and an additional (sub-stack) label to encode the AD, packet also has increased with 8 bytes. I don’t see the difference wrt to how far you have to look inside the packet.

Thx,

Ice.


> analyzed when it comes to selecting between ISD and PSD approaches.
> 
> Regards,
> Greg
> 
> 
> 
> On Mon, Aug 28, 2023 at 10:56 AM Alexander Vainshtein <[e-mail]> wrote:
> 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) 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]> 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]> 
> Sent: Wednesday, July 19, 2023 6:25 PM
> To: Alexander Vainshtein <[e-mail]>
> Cc: [e-mail]; [e-mail]; MPLS Working Group <[e-mail]>; [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]>
> Date: Sunday, 16 July 2023 at 11:43
> To: Matthew Bocci (Nokia) <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, MPLS Working Group <[e-mail]>, [e-mail] <[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 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]> 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.
> 
> 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
> 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 and RFC 3032 as the references for the MPLS architecture, but it does not mention RFC 5331 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. 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. (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) 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 or Segment Routing Micro-loop Avoidance 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 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 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]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls