[mpls] Re: WGLC on draft-ietf-mpls-mna-usecases

[Loa Andersson <[e-mail]>]

Working Group, wg chairs and authors,

I agree that we should go ahead a request publication. It is a 
well-written and easy to read document.

Earlier I have said that this document is not the type of document that 
we called "use cases" back in the palaeolithical times. Use case were 
written defining "the user" and the "the system", the interactions 
between the two and the "data" needed for the interactions.

The use case document were then used as input for writing system 
requirements, I have not seen much interaction between "MNA use cases" 
and "MNA requirements".

The document as it stands today is more a list af "what MNA can do", 
useful but falling short of what I would expect from a use case document.

I would suggest that we wait until this document has ben published and 
the try to start a discussion on why we need use-case documents and what 
we expect from them.

/Loa



Den 2024-06-18 kl. 09:03, skrev Dongjie (Jimmy):
>
> Hi Greg,
>
> Thanks for the prompt reply and update of the draft which address some 
> of my comments.
>
> Please see further inline for the remaining ones:
>
> *From:*Greg Mirsky [mailto:[e-mail]]
> *Sent:* Tuesday, June 18, 2024 9:04 AM
> *To:* Dongjie (Jimmy) <[e-mail]>
> *Cc:* Tony Li <[e-mail]>; mpls <[e-mail]>; mpls-chairs 
> <[e-mail]>
> *Subject:* Re: [mpls] Re: WGLC on draft-ietf-mpls-mna-usecases
>
> Hi Jie,
>
> thank you for supporting this work and your comments that help 
> improving it. Please find my notes in-lined below. Also, I've attached 
> the working version and diff that highlights the updates.
>
> Regards,
>
> Greg
>
> On Mon, Jun 17, 2024 at 2:22 AM Dongjie (Jimmy) 
> <jie.dong=[e-mail]> wrote:
>
>     Hi all,
>
>     I’ve read the latest version (-09) of this document, and think the
>     document is useful, thus I support moving it forward. I have the
>     following comments for the authors/WG to consider before the
>     publication.
>
>     1.In Terminology section, the definition of “RFC 9543 Network
>     Slice”needs to be consistent with the definition in RFC 9543, or
>     simply a reference to RFC 9543.
>
> GIM>> Updated to reference RFC 9543.
>
> [Jie] The update looks good, thanks.
>
>     2.In Terminology section, the MPLS Ancillary Data (AD) also covers
>     the case of implicit or “no-data”. This is different from the
>     definition of ancillary data in draft-ietf-mpls-mna-requirements,
>     where it only covers ISD and PSD.
>
> GIM>> Removed the reference to the "no-data" case.
>
> [Jie] The update looks good, thanks.
>
>     3.Section 2 in general.
>
>     To help better understanding of the use cases, for each use case,
>     it is suggested to indicate the required scope of this action
>     (HBH, ingress-destination, select), whether ancillary data is
>     needed or not, and whether the ancillary data is mutable or not in
>     terms of its content and size. For some of the use cases (e.g.
>     IOAM) this has been covered, while for other use cases (e.g.
>     NFFRR, network slicing, SFC), this information is missing.
>
> GIM>> In my understanding, the group has agreed that the document does 
> not discuss any aspect of a solution for the MNA use case. That is why 
> we avoided references to proposals that define how the particular 
> scenario can be enabled using MNA. It seems that that is a 
> reasobale way avoiding discussion of which of proposed solutions is 
> more suitable. The reference to the scope of IOAM is from RFC 9197 
> <https://datatracker.ietf.org/doc/rfc9197/>. If you find similar 
> discussions in the base specifications of other use cases observed in 
> the draft, please help us by providing references and I'll update text 
> accordingly.
>
> [Jie] I didn’t suggest to add any MNA solution information in this 
> document.
>
> What I suggest is to add more information about the use cases to help 
> the design of the solution. This includes at which points (ingress, 
> egress, per-hop, or selected hops) the action needs to be performed, 
> what kind of information needs to be carried (one flag, multiple 
> flags, ancillary data), and whether the flags and ancillary data will 
> change enroute.
>
> Please note that for the iOAM case, the above information has already 
> been provided. What I suggest is to do the same for other use cases in 
> this draft.
>
>     4.Section 2.1 says:
>
>     “Several cases exist where, once a Fast Reroute (FRR) has taken
>     place in an MPLS network and resulted in rerouting a packet away
>     from the failure, a second FRR impacts the same packet on another
>     node, and may result in traffic disruption.”
>
>     Jie: It is suggested to describe in which scenarios further FRR
>     may result in traffic disruption.
>
> GIM>> It seems like the group, over the course of discussions, has 
> agreed that NOFRR addresses a real problem. Do you have any concern 
> with that conclusion?
>
> [Jie] I fully agree that NFFRR is useful, and I know it was discussed 
> on the mailing list. While for documentation it would be helpful to 
> provide the background information about the cases where NFFRR is 
> needed in the draft, instead of just saying “several cases exist”.
>
>     Section 2.1 also says:
>
>     “To avoid that situation, packets that have been redirected by FRR
>     will be marked using MNA  to preclude further FRR processing.”
>
>     Jie: The text needs to be clear whether further FRR must be
>     avoided in all cases, or it depends on the service requirements,
>     network topology, tunnel technology (e.g. RSVP-TE or SR), etc.
>
> GIM>> As I understand it, NOFRR is optional functionality that may be 
> used by an operator based on their understanding of their network. 
> Furthermore, the discussion of the applicability of the NOFRR solution 
> seems more applicable in the document that defines such solution.
>
> [Jie] That is also my understanding: NFFRR is optional and will be 
> used according to operator’s local policy. What I suggest is also 
> mention this in the draft. The current text “packets that have been 
> redirected by FRR will be marked using MNA to preclude further FRR 
> processing” may cause some confusion that NFFRR is the default behavior.
>
>     Jie: And it is suggested to add reference to existing mechanisms
>     (e.g. control plane based mechanism) which can avoid FRR or
>     further FRR.
>
> GIM>> I think that the discussion or comparison of existing or 
> possible NOFRR solutions is outside the scope of this document.
>
> [Jie] In section 2.4, the existing MPLS based SFC mechanism and the 
> analysis of its limitations are referenced. For NFFRR, there was some 
> discussion on the list about the control plane based mechanisms, and 
> the potential benefit of data plane (e.g. MNA) -based solution:
>
> https://mailarchive.ietf.org/arch/msg/mpls/DKPtdFdQiSAodrCU6hTsXLc4Grg/
>
> It would be helpful to have some of this discussion documented.
>
>     5.Section 2.2, the first paragraph says:
>
>     “MNA can be used to carry information essential for the collection
>     of operational information and/or measurement of various
>     performance metrics that reflect the experience of the packet
>     marked by MNA.”
>
>     Jie: This sentence contains two types of MNA use cases:
>
>     1. Indicates the performance measurement actions to be applied to
>     the packet.
>
>     2. Carry operational or measurement information related to the
>     packet.
>
>     As 1 and 2 can be used separately or together, it is suggested to
>     split it into two sentences.
>
> GIM>> Although English is not my native language, but, to the best my 
> language skills, the "and/or" construct explicitly allows for 
> inclusive and mutualy exclusive use of both functionalities.
>
> [Jie] English is not my native language either:) I noticed the 
> “and/or” used here. The problem is that currently it reads as: “MNA 
> can be used to … and/or … marked by MNA”. And it is __
>
> If you prefer to keep the two functions in one sentence, maybe it can 
> be revised to something like:
>
>    “MNA can be used to carry A and/or B”.
>
>     6.Section 2.2.1, it is suggested to add some text about for
>     IOAM-DEX what kind of information needs to be carried using MNA.
>
> GIM>> I believe that, according to the scope of the document that the 
> WG has agreed to, that information is outside the scope of this draft 
> and must be discussed in the solution-defining specification.
>
> [Jie] I raised this suggestion because from the below text, it is not 
> clear whether IOAM-DEX is a use case of MNA or not.
>
>        “With all IOAM Option-Types except for the Direct Export (DEX), 
> the collected information is transported in the trigger IOAM packet.”
>
> “In IOAM DEX, the user data packet is only used to trigger the IOAM 
> data to be directly exported or locally aggregated without being 
> carried in the IOAM trigger packets.”
>
>     7.Section 2.3 says:
>
>     “[RFC9543] also defines a Network Resource Partition (NRP) Policy
>     as a policy construct...”
>
>     Jie: NRP Policy is not defined in RFC 9543, suggest to change it
>     to NRP and revise the text accordingly.
>
> GIM>> Section 7.1 of RFC 9543 defines NRP as:
>
>      An NRP is a subset of the buffer/queuing/scheduling resources and
>     associated policies on each of a connected set of links in the
>     underlay network (for example, as achieved in
>     [RESOURCE-AWARE-SEGMENTS]).
>
>     [Jie] Yes, but that is the definition of NRP, which is different
>     from the definition of “NRP Policy”.
>
>     “The packets associated with an NRP may carry a marking in their
>     network layer header to identify this association, which is
>     referred to as an NRP Selector.”
>
>     Jie: For NRP selector, suggest to add a reference to
>     draft-ietf-teas-ns-ip-mpls.
>
> GIM>> Added
>
> [Jie] Thanks.
>
>     “In this case, the routers that forward traffic over resources
>     shared by multiple NRPs need to identify the slice aggregate
>     packets to enforce their respective forwarding actions and
>     treatments.”
>
>     Jie: For multiple NRPs, the network resources need to be
>     partitioned and each NRP is associated with a subset of resources.
>     Thus “resource shared by multiple NRPs”is not accurate. It may
>     actually means “a physical link shared by multiple NRPs”.
>
>     Jie: The term “slice aggregate”is no longer used in network
>     slicing drafts in TEAS, thus it is suggested to replace “identify
>     the slice aggregate packets”with “identify the NRP that the
>     packets belongs to”.
>
> GIM>> Thank you for pointing these deviations out to me. Both are 
> accepted and I updated text accordingly.
>
> [Jie] They look good, thanks.
>
>     8. Section 3, for existing use cases, it is suggested to also
>     include the use MPLS data plane for Detnet described in RFC 8964
>     and 9546.
>
> GIM>> Although we were not trying to provide the exaustive list and 
> the DetNet over  the MPLS data plane is, on the wire, using the PW 
> approach that is referenced in Section 3, I'll be thankful for a text 
> that you propose.
>
> [Jie] Since the introduction mentions the use cases in this document 
> are discussed by MPLS, PALS and DetNet, perhaps the DetNet use cases 
> worth an explicit reference in the document?
>
> I’d propose to add to section 3 something like:
>
>    MPLS can be used as the data plane for DetNet [RFC8655]. The DetNet 
> functions, such as Packet Replication, Elimination and Ordering 
> Functions (PREOF) are provided using MPLS label stack and the DetNet 
> Control Word as described in [RFC 8964].
>
> Best regards,
>
> Jie
>
>     Best regards,
>
>     Jie
>
>     *From:*Tony Li <[e-mail]> *On Behalf Of *Tony Li
>     *Sent:* Wednesday, June 5, 2024 6:26 AM
>     *To:* mpls <[e-mail]>
>     *Cc:* mpls-chairs <[e-mail]>
>     *Subject:* [mpls] WGLC on draft-ietf-mpls-mna-usecases
>
>     [WG chair hat: on]
>
>
>
>     Hi folks,
>
>
>     This starts a 2 week working group last call
>     on draft-ietf-mpls-mna-usecases
>     (https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/)
>
>     This WGLC will expire at 4pm PDT, Jun 18, 2024.
>
>     Please comment as to the readiness of this document for
>     publication, both pro and con.
>
>     There are no IPR filings against this document.
>
>     Regards,
>
>     Tony
>
>     _______________________________________________
>     mpls mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

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