[mpls] (no subject)
loa@pi.nu Thu, 11 April 2024 05:32 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5815DC14F6AD; Wed, 10 Apr 2024 22:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdnLc-Limg8L; Wed, 10 Apr 2024 22:32:35 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DC5C14F6BB; Wed, 10 Apr 2024 22:32:32 -0700 (PDT)
Received: from pi.nu (localhost.localdomain [127.0.0.1]) by pipi.pi.nu (Postfix) with ESMTP id DDAC73A9777; Thu, 11 Apr 2024 07:32:29 +0200 (CEST)
Received: from 119.95.121.99 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Thu, 11 Apr 2024 07:32:29 +0200
Message-ID: <db6f751f585ab9680a909ebb6ef32978.squirrel@pi.nu>
Date: Thu, 11 Apr 2024 07:32:29 +0200
From: loa@pi.nu
To: mpls@ietf.org
Cc: draft-ietf-mpls-mna-usecases@ietf.org, mpls-chairs@ietf.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/3Ie6wYCqxzi25l7JW5PniU3xNWw>
Subject: [mpls] (no subject)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2024 05:32:41 -0000
Review of draft-ietf-mpls-mna-usescases (started 2023-04-08) Major: ====== Ise 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