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

[[e-mail]]

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