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

[Greg Mirsky <[e-mail]>]

Hi Loa,
thank you for your thorough review, detailed questions, and helpful
suggestions. I'll prepare the updates, discuss with the authors and bring
our proposals for further discussion.

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.
>
> 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..
>
> 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-
>
> 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.
>
> The Introduction contains a discussion about the ISD and PSD
> terminology, why is that not part of the Terminology?
>
> 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.
>
>
> 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.
>
> Unexpanded Abbreviations
> ------------------------
>
> LSP (Label Switched Path) is in the document but not expanded, nor is it
> in the Abbreviation is the document.
>
> 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.
>
> 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.
>
> 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.
>
> NRP is in the document and expanded in section 2.3, but not in the
> abbreviation list in the document.
>
> In section 2.5 we have the odd practice to expand the abbreviation on
> second occurrence :).
>
>
> 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.
>
> 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
>
> Key words
> ---------
>
> The RFC 2119 language are included but not used.
>
> Abbreviations and Acronyms
> --------------------------
> I think everything in the list is "Abbreviations", we normally don't
> do "Acronyms". Might want to change the  section title.
>
> 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)
>
> 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?
>
> 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.
>
> Flow Aggregate Selector
> -----------------------
>
> FAS (Flow Aggregate Selector) is only present in the Abbreviation
> list.
>
>
> Summary
> -------
>
> I have the impression that a lot of work, and a lot of discussion why
> we need use cases are needed.
>
>
> /Loa
>
>
>