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

["Dongjie (Jimmy)" <[e-mail]>]

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.


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.


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.



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.



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.


Jie: And it is suggested to add reference to existing mechanisms (e.g. control plane based mechanism) which can avoid FRR or further FRR.


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.


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.


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.

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

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


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.


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