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

[Greg Mirsky <[e-mail]>]

Hi Loa,
thank you for a good constructive discussion. Please find my follow-up
notes below tagged GIM2>>.

Regards,
Greg

On Sun, Apr 21, 2024 at 12:04 PM Loa Andersson <[e-mail]> wrote:

> 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.
>
GIM2>> I will add the latter version of the definition to the Introduction.
As for changing the structure of describing a use case to one that you're
suggesting, perhaps before making these changes, we can get additional
comments from the WG. I invite the WG Chairs, all interested in this draft
to share their opinions.

> >
> >>
> >> 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.
>
GIM2>> That determination, as always, for the WG Chairs. AFAICS, there was
no WG LC on draft-ietf-mpls-inband-pm-encapsulation. Or have I missed it?

> 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.
>
GIM2>> A very good question, thank you! I've looked through the draft from
that PoV, and I think that Section 2.2 can be generalized for the hybrid
performance measurement method in the MPLS network in general. Changing the
title and adding a paragraph with references to the Alternate Marking
method seems like a reasonable way. If you agree with that in principle,
we, the authors, will work on updating Section 2.2 accordingly.

>
> > 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?
>
GIM2>> Coming up. Will share before posting.

>
> >
> >>
> >> 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.
>
GIM2>> I agree, eSPL is not a scarce resource, as bSPL. I'll check the
document to not suggest that point.

> >>
> > 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.
>
> ???
>
GIM2>> It seems like I've missed your original question, my apologies. It
now moved to the top. I hope that our discussion will motivate others to
share their opinions on the document, its scop, and structure.

>
> >>
> >> 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,
>
GIM2>> If this is a common trend, perhaps a new document (short) document
could be the solution. This document is more specific and probably not
everyone will read it.

>
> <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.
>
GIM2>> In my experience, Acronyms was acceptable form to name the section.
If the RFC Editor will suggest the change, I will be glad to accept and
will use that from then on.

> >
> >  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.
>
GIM2>> I think that we already do that:
 ToS: Top of Stack
and there's no other expansion of the 'ToS' in the document.  AFAIK, the
scope of acronyms/abbreviations expanded in that section is the document
and nothing beyond it.

> >
> >>
> >> 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.
>
GIM2>> Perhaps we interpret "informational and historical" differently. I
would not change the current text in the document if it is acceptable to
you in its current form.

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