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

[Greg Mirsky <[e-mail]>]

I got carried away. My apologies.

Regards,
Greg

On Mon, Aug 28, 2023, 15:24 Alexander Vainshtein <
[e-mail]> wrote:

> Greg, Ice and all,
>
>
>
> Comparison of ISD vs. PSD solutions is a very interesting topic in MNA.
>
> But, IMHO and FWIW, the MNA requirements draft
> <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-06>
> should be *completely neutral* regarding these two approaches.
>
>
>
> Maybe there is a place for a dedicated draft defining the rules and
> criteria for such comparison.
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Monday, August 28, 2023 3:13 PM
> *To:* IJsbrand Wijnands <[e-mail]>
> *Cc:* Alexander Vainshtein <[e-mail]>; Routing
> Directorate <[e-mail]>;
> [e-mail]; MPLS Working Group <
> [e-mail]>; mpls <[e-mail]>
> *Subject:* Re: [mpls] [EXTERNAL] Re: RTG-DIR Early review:
> draft-ietf-mpls-mna-requirements-05
>
>
>
> Hi Ice,
>
> thank you for taking interest in my notes. Yes, in some cases, PSD might
> be more efficient compared to ISD because of how we encode AD when it is
> ISD. What I wanted to point out, is that PSD, being after the BoS, might be
> way furher away from the NAI. If that is the case, to process PSD at
> line-rate would require larger cache memory to store the part of the
> received MPLS packet. That's what I wanted yo point.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Aug 28, 2023, 11:35 IJsbrand Wijnands <[e-mail]>
> wrote:
>
> 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
>
>