Re: [mpls] Review of draft-ietf-mpls-mna-usescases

[Greg Mirsky <[e-mail]>]

Hi Loa,
thank you for your thorough review, thoughtful questions, and helpful
suggestions. Please find my notes below tagged GIM>>. Attached, please find
the copy of the working version of the draft.

Regards,
Greg

On Thu, Apr 11, 2024 at 7:59 AM <[e-mail]> wrote:

> All,
>
> Sorry I forgot the subject, use this one if you respond.
>
> Review of draft-ietf-mpls-mna-usescases (started 2023-04-08)
>
> Major:
> ======
>
> Use cases in general
> --------------------
>
> I've looked around a bit for a workable definition of "use case",
> there seem to be  at least a rough consensus around this:
>
>    A use case is a methodology used in system analysis to identify,
>    clarify and organize system requirements. The use case is made
>    up of a set of possible sequences of interactions between systems
>    and users in a particular environment and related to a particular
>    goal. The method creates a document that describes all the steps
>    taken by a user to complete an activity.
>
> In general I miss both the the analysis and the "sequences of
> interactions" in draft-ietf-mpls-mna-usescases.
>
> Now there might be other definitions of "the purpose the use case
> methodology" that result in the type of document we have now, if so
> that definition should be included in the document.
>
GIM>> A great point, thank you! I've found the following definition that
seems close to the implied interpretation in this document:
A use case is a concept used in software development, product design, and
other fields to describe how a system can be used to achieve specific goals
or tasks. It outlines the interactions between users or actors and the
system to achieve a specific outcome.

Do you think that that definition can be added to the Terminology section
as-is or would suggest re-wording like follows:
A use case is a concept describing how a system can be used to achieve
specific goals or tasks. It outlines the interactions between users or
actors and the system to achieve a specific outcome.

WDYT?

>
> Introduction
> ------------
>
> I think the the discussion on preserving the scarce Special Purpose
> Label (SPL) resource put the cart before the horse. And it seem to
> be outside the scope of the document. Even though MNA does
> its best to limit the use of SPLs, it was never a motivation for MNA,
> rather it has been a requirement not to consume bSPLs unnecessarily..
>
GIM>> If I recall the early discussions about the MNA, it all started with
a single NOFRR proposal. Over time, we've realized that the case can be
generalized to also support network actions with ancillary data. Some use
cases, e.g., draft-ietf-mpls-inband-pm-encapsulation, are still progressing
outside of MNA, although the same case can be solved using MNA
(draft-cx-mpls-mna-inband-pm) avoiding using a new eSPL value. As discussed
in RtgDir Early review
<https://mailarchive.ietf.org/arch/browse/mpls/?gbt=1&index=41q0ysSnylT2VjRJwPmR8ASXi9w>,
each case listed in the draft could have been realized using a dedicated
(e)SPL. I think that Druv and I agree that by introducing MNA solution, we
can preserve more (e)SPLs and, also, use the canonical format for MNA
options so that an implementation can handle unsupported actions more
gracefully (skip over rather than dropping the packet). Druv and I are
working on the text to be added describing the latter benefit.

>
> Also the statement that previously "functions that are based on
> special processing by forwarding hardware" required a new
> special-purpose label is incorrect, for example FRR is a special
> processing, dut does not require a bSPL or eSPL.
>
> Also PWs and the GACh are kind of special processing-
>
GIM>> I agree, although only partially. The special processing of a PW is
established via the control plane. And the presence of G-ACh, i.e., a
specific version of a Post-stack Header, is signalled by the presence of
GAL in the stack.

>
> We should also be careful before we start talking about eSPLs as
> "scare", the very reason why we created the eSPLs were that bSPLs
> were becoming scarce, and we needed a source of APLs that were not
> scare, eSPLs are also easily extendable.
>
GIM>> True, eSPL is less scarce, although it is still a limited resource.

>
> The Introduction contains a discussion about the ISD and PSD
> terminology, why is that not part of the Terminology?
>
GIM>> A great suggestion, thank you. Please check the attached copy of the
working version. Let me know if it reflects your suggestion.

>
> Use Cases
> ---------
>
> A general comment is that there are very little information, apart
> in the 5 use cases listed in this document.
>
> I had expected that if we define use at least "the user" should be
> identified for each use case, what the goal of the user is, what part
> of "the system" this user is interacting with and how this
> interaction works.
>
> I can't find this.
>
> Question that must be asked
> ---------------------------
>
> If one of the key goaöls with a use case document is to be "used in
> system analysis to identify,    clarify and organize system
> requirements", and we are about to request publication of the MNA
> requirements, why do we need the MNA use cases?
>
> Note: I don't think of this as a suggestion to discontinue the use
> case document, but more a request that motivational text (or at
> least some very good pointers) are added to the document.
>

GIM>> AFAICS, this document is instrumental in the analysis of the required
scope of MNA solution regarding supported AD options - no AD, ISD, PSD. Of
course, we welcome your help and be happy to work together on extending the
motivational section of the document.

>
>
> Minor:
> ======
>
> Title
> -----
>
> The title of the document is "Use Cases for MPLS Network Action
> Indicators and MPLS Ancillary Data", why isn't it "Use cases MPLS
> Network Actions", indicators and and data are parts of MNA, and the
> use cases are for MNA.
>
GIM>> That can be updated if no one objects. Please share your thoughts and
suggestions how to proceed.

>
> Unexpanded Abbreviations
> ------------------------
>
> LSP (Label Switched Path) is in the document but not expanded, nor is it
> in the Abbreviation is the document.
>
GIM>> Added

>
> Expansion not according to the book
> -----------------------------------
>
> This document expands BoS as "Bottom of the MPLS label Stack (BoS)"
> in section 1.
> RFC 3032 says Bottom of Stack (S), i.e. the Bottom of Stack referred
> to the bit (S).
> This document  says BoS - Bottom of Stack in section 2.5, we should
> stick to that, and try put it into the RFC Editors Abbreviation list.
>
GIM>> Thank you for pointing that out to me. Fixed.

>
> I think we have started to slide a bit from RFC 3032, where bottom
> of stack referred to the bit (S), to a practice today there BoS
> more often refer to the LSE that has the S-bit set. It might be a
> good idea to tell the reader how you are using the concept.
>
> This document uses E2E: Edge-to-Edge, while I think the consensus was
> that MNA should use "I2E: Ingress to Egress", as documented in the
> framework.
>
> Note: it might be the the "Edge-to-Edge" used here refers to another
> documeht/technology, is so it should be made clear.
>
GIM>> Another great catch. Fixed by s/E2E/I2E/

>
> This document has FRR in the abbreviation list, but it also says
> "MPLS Fast Reroute (FRR) [RFC4090], [RFC5286] and [RFC7490]", since
> only RFC 7490 actually uses FRR, I think it would be correct to
> remove (FRR) from that sentence, they are all good references to Fast
> Reroute.
>
GIM>> Please let me know whether the update captured your suggestion.

>
> NRP is in the document and expanded in section 2.3, but not in the
> abbreviation list in the document.
>
GIM>> Added, thank you.

>
> In section 2.5 we have the odd practice to expand the abbreviation on
> second occurrence :).
>
GIM>> SR, I assume? ;) Fixed.

>
>
> Abstract
> --------
>
> OLD
>    This document presents a number of use cases that have a common
>    need for encoding network action indicators and associated
>    ancillary data inside MPLS packets.  There has been significant
>    recent interest in extending the MPLS data plane to carry such
>    indicators and ancillary data to address a number of use cases
>    that are described in this document.
> NEW
>    This document presents use cases that have a common feature in
>    that they may be addressed by encoding network action indicators
>    and associated ancillary data within MPLS packets.  There are
>    interest to extend the MPLS data plane to carry such indicators
>    and ancillary data to address the use cases that are described
>    in this document.
> END
>
> Comment: I normally don't bother making comments that are language
> or grammar, people writing the text are normally better at Engish
> than I am. However, spreading out for example "a number of" does not
> add anything.
>
GIM>> MAny thanks for the proposed update. Applied with a minor editorial
twist s/to extend/in extending/. I hope you will agree.

>
> OLD
>    The use cases described in this document are not an exhaustive set,
>    but rather the ones that are actively discussed by members of the
>    IETF MPLS, PALS, and DetNet.
> NEW
>    The use cases described in this document are not an exhaustive set,
>    but rather the ones that are actively discussed by members of the
>    IETF MPLS, PALS, and DetNet working groups.
> END
>
GIM>> Perfect!

>
> Key words
> ---------
>
> The RFC 2119 language are included but not used.
>
GIM>> We do have a single use of the normative language in:
   Two or more of the aforementioned use cases MAY co-exist in the same
   packet.
while there are more lower-case uses of "may". After considering that
situation, I decided to s/MAY/may/ and, as a result, remove the
boilerplate. Please let me know if you have any concerns with this update.

>
> Abbreviations and Acronyms
> --------------------------
> I think everything in the list is "Abbreviations", we normally don't
> do "Acronyms". Might want to change the  section title.
>
GIM>> I found the following explanation of the terms that demonstrates
their difference:

An abbreviation is a shortened form of a word used in place of the full
word (e.g., Inc.). An acronym is a word formed from the first letters of
each of the words in a phrase or name.

 AFAICS, Acronyms is a closer title of the section. WDYT?

>
> Do we use ToS elsewhere in the MPLS documentation, if we do is it
> ToS or TOS?
>
>
> ToS        - Top of Stack, is not in the RFC Abbreviation List, if
>                            this document makes it to RFC, we  should
>                            make sure that it is included RFC Editors
>                            Abbreviation lsit.
>
> There is a TOS, in the RFC Editirs list but totally different meaning:
> TOS        - Type of Service (TOS)
>
GIM>> I think that this acronym is used in the scope of this document.

>
> Appendix A1
> -----------
> At the time I thought the GDF was interesting, but it has now been
> expired for 15 months, if it is not going to progress, why do we
> need it in the appendix?
>
GIM>> All appendixes are for informational and historical purposes. I see
that as beneficial to a reader.

>
> Nits:
> =====
>
> Use case vs usecase
> -------------------
>
> I think the preferred spelling is "use case" rather than "usecase",
> should be corrected. This applies to several places in the document.
>
GIM>> Got it, thx!

>
> Flow Aggregate Selector
> -----------------------
>
> FAS (Flow Aggregate Selector) is only present in the Abbreviation
> list.
>
GIM>> Thank you for the catch! That's a leftover resulting from the
terminology change to NRP Selector.

>
>
> Summary
> -------
>
> I have the impression that a lot of work, and a lot of discussion why
> we need use cases are needed.
>
>
> /Loa
>
>
>