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

[Loa Andersson <[e-mail]>]

Greg,


Tnx! I'm responding inline, while removing everything where we agree.


> 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?

I think I can live with both the descriptions of what a use case is, they
are very similar. The key point is that I need to see for each of the
use cases in the document who "the user" are, what the system is, the
goal of the user and the user and system communicates to reach that goal.

As far as I can see that is missing for all of the use cases 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..
>>
> 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.

The NFFRR proposal did consume a bSPL, and yes it was a good thing that
we could generalize so we only used on bSPL.

> 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.

1. I thought we had a, even if somewhat rough, consensus on that the
   draft-ietf-mpls-inband-pm-encapsulation is a gap filler, while
   waiting for  draft-cx-mpls-mna-inband-pm.
2. It is correct that draft-ietf-mpls-inband-pm-encapsulation, consumes
   an eSPL, though eSPLs technically is limited, we only need to flip
   one bit to get another 256 new eSPls
   I don't share the concerns about running out of eSPLs.
3. With this line of reasoning  why is not performance management one
   of the use case.

> 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.

New text for the use case document?

>
>>
>> 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.
>

<snip - ISD/PSD 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 goals 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.
>
<snip - LSP, BoS>

>> 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.

If the sliding I'm talking about is real, it need to captured somewhere,

<snip 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.
>
>>
< snip - FRR>

>> Abstract
>> --------

<snip - grammar, DT>


>>
>> 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.

hmm, it seems that the powers to be don't agree, I found this:

Is OMG an acronym or abbreviation?
Oh my God! (sometimes also Oh my Goodness! or Oh my Gosh!), a common
abbreviation; often used in SMS messages and Internet communication.

The RFC Editor uses Abbreviations for what we are discussing, we should
follow the RFC Editor, unless we want the RFC Editor to change abbreviation
list to acronym list.

I think there is a general agreement that acronyms are abbreviations that
can be pronounced as a word, i.e. MPLS is not an acronym but cats are,
and they are both abbreviations.
>
>  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 Editors list but totally different meaning:
>> TOS        - Type of Service (TOS)
>>
> GIM>> I think that this acronym is used in the scope of this document.

Then you need to spell that out carefully.
>
>>
>> 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.

The motivation for the Appendixes are:

   A number of use cases for which MNA can provide a viable solution
   have been brought up.  The discussion of these aspirational cases is
   ongoing.

Which seem to be different from what you say in your response, the
motivation(s) and the information should match.
>
>>
>> Nits:
>> =====
>>
<snip - usecases, FAS>

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

/Loa
>>
>> /Loa
>>
>>
>>
>


-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]