Encapsulation For MPLS Performance Measurement with Alternate-Marking Method
draft-ietf-mpls-inband-pm-encapsulation-18

[Ballot comment]
(Revised ballot)
Thank you for addressing my DISCUSS feedback.

** For the responsible AD and WG chairs: I observe that this document doesn’t fit neatly into the work items described in the “The current WG focus areas and work items” section of https://datatracker.ietf.org/doc/charter-ietf-mpls/07/

** Section 6.
  How the ingress node knows the FLC and FRLD of all
  the on-path nodes is outside the scope of this document.  However,
  [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

Why make a reference to an expired, individual submission if the methodology is out of scope?

[Ballot comment]
Section 2.1 defines "MNA" but it's not used after it's defined.  A few entries in that section are also out of order.

Thanks for including Section 9.

Eric's ABSTAIN position is interesting.  I'd like to have some understanding about his primary issue as well.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15

# Thanks for the Shepherd writeup from Tony Li, providing useful insight in the origins of the document and the relationship with MNA.

#Thanks to Darren Dukes for the early RTGDIR review.

#GENERIC COMMENTS
#================
## I support the DISCUSS from John Scudder

## I was flipping between NoObjection and DISCUSS as there are items that to me look serious enough to be discussed more in detail in the WG.
However, the existing DISCUSS items from fellow IESG area directors will most likely cause that to happen anyway.

## I got confused with the text handling The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI where first the formal procedure is them to equal and next to state they MAY be different?

## If there is formal requirement to set some fields to 0 or 1 with a MUST, then exception procedures should be provided when a (transit) router receives an mpls packet with potentially non-conforming fields set. Should the packet be dropped? allowed? tagged? ICMP message created

## When inserting labels, then this impacts the packet IP MTU. This seems not discussed?

## The exact definition of 'unique' is not defined in the document. Does unique mean unique over  time? unique for any flow at any given time?  If a controller reboots, will it have to harvest all used LFIs that are running in the infrastructure?

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

84   [RFC9341] describes a performance measurement method, which can be
85   used to measure packet loss, delay, and jitter on data traffic.

[minor]
RFC9341 describes this as "live" traffic and not data traffic. I believe there is a substantial difference between the two

"
  This document describes the Alternate-Marking technique to perform
  packet loss, delay, and jitter measurements on live traffic.
"

87   it is referred to as the Alternate-Marking Method.  [RFC8372]
88   discusses aspects to consider when developing a solution for MPLS
89   flow identification for performance monitoring of MPLS flows.

[minor]
RFC8372 says the following:

"
  This document discusses aspects to consider when developing a
  solution for MPLS flow identification.  The key application that
  needs this solution is in-band performance monitoring of MPLS flows
  when MPLS is used to encapsulate user data packets.
"

Hence the phrase construct is not 100% correct. Maybe the following should be considered instead:

"
[RFC8372] outlines key considerations for developing a solution for MPLS flow identification, intended for use in performance monitoring of MPLS flows.
"

98   Note that in parallel to the work of this document, there is ongoing
99   work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
100   Considering the MPLS performance measurement with the Alternate-
101   Marking method can also be achieved by MNA encapsulation, it is
102   agreed that this document will be made Historic once the MNA solution
103   of performance measurement with the Alternate-Marking method is
104   published as an RFC.

[minor]
As other ADs suggested, this looks as an unusual statement.
What is the value of this section when the document is a proposed standard. Can it not be simply a rfc editor note and remove it when becoming RFC? (this is a non-blocking comment/observation)


196   The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
197   FLI MUST use the same values of the label immediately preceding the
198   XL.  In this case the TC and TTL for the XL and FLI MAY be of
199   different values. 

[major]
These two phrases seem to contradict each other. First sentence say they MUST use same values and the second sentence suggest that they MAY be different.
How is exception handling when a receiver receives (first sentence) the where FLI and XL and TC/TTL is not identical?

214   FL in a label stack.  The TTL for the FL MUST be zero to ensure that
215   it is not used inadvertently for forwarding.  The BoS bit for the FL
216   depends on whether the FL is placed at the bottom of the MPLS label
217   stack, i.e., the BoS bit for the FL is set only when the FL is placed
218   at the bottom of the MPLS label stack.

[minor]
What is the formal handling procedure when a receiver received (a transit node or mpls recipient) a packet where the FL is NOT zero?

412   service and the MPLS transport would be generated.  In this case, the
413   transit node needs to look up both of the two Flow-IDs by default.

[minor]
"the" transit node? Not sure the exact meaning of "the" is in this context.
There may be many transit nodes that the flow traverses. Would in this context using the word "a transit node" not be more technically correct?

418   Whether using the two methods mentioned above or other methods to
419   allocate Flow-ID, the NMS/controller MUST ensure that every generated
420   Flow-ID is unique within the administrative domain and MUST NOT have
421   any value in the reserved label space (0-15) [RFC3032].

[major]
I think that there should be understanding on what unique exactly means. for example, if at time=1 there is allocated FL=1234. next and time=2 the flow no longer exists. And at time=3 for a new unrelated flow there is allocation of FL=1234. Would that count as being unique?

What happens when the controller that allocated rebooted and lost all awareness of allocated LFIs? can it create new, potentially non-unique (over time) LFIs?

438   the on-path nodes is outside the scope of this document.  However,
439   [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

[minor]
The [I-D.xzc-lsr-mpls-flc-frld] document is not a WG accepted document. Is it really your objective to have this current standards based document fateshare with this not addopted informative reference?

451 7.  Equal-Cost Multipath Considerations

[minor]
Any concerns with mixing ELI/EL and FL? any impact between identifying flow and the entropy caused by Entropy Labels?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15

# Thanks for the Shepherd writeup from Tony Li, providing useful insight in the origins of the document and the relationship with MNA.

#Thanks to Darren Dukes for the early RTGDIR review.

#GENERIC COMMENTS
#================
## I support the DISCUSS from John Scudder

## I was flipping between NoObjection and DISCUSS as there are items that to me look serious enough to be discussed more in detail in the WG.
However, the existing DISCUSS items from fellow IESG area directors will most likely cause that to happen anyway.

## I got confused with the text handling The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI where first the formal procedure is them to equal and next to state they MAY be different?

## If there is formal requiremnt to set some fields to 0 or 1 with a MUST, then exception procedures should be provided when a (transit) router receives an mpls packet with potentially non-conforming fields set. Should the packet be dropped? allowed? tagged? ICMP message created

## When inserting labels, then this impacts the packet IP MTU. This seems not discussed?

## The exact definition of 'unique' is not defined in the document. Does unique mean unique over  time? unique for any flow at any given time?  If a controller reboots, will it have to harvest all used LFIs that are running in the infrastructure?

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

84   [RFC9341] describes a performance measurement method, which can be
85   used to measure packet loss, delay, and jitter on data traffic.

[minor]
RFC9341 describes this as "live" traffic and not data traffic. I believe there is a substantial difference between the two

"
  This document describes the Alternate-Marking technique to perform
  packet loss, delay, and jitter measurements on live traffic.
"

87   it is referred to as the Alternate-Marking Method.  [RFC8372]
88   discusses aspects to consider when developing a solution for MPLS
89   flow identification for performance monitoring of MPLS flows.

[minor]
RFC8372 says the following:

"
  This document discusses aspects to consider when developing a
  solution for MPLS flow identification.  The key application that
  needs this solution is in-band performance monitoring of MPLS flows
  when MPLS is used to encapsulate user data packets.
"

Hence the phrase construct is not 100% correct. Maybe the following should be considered instead:

"
[RFC8372] outlines key considerations for developing a solution for MPLS flow identification, intended for use in performance monitoring of MPLS flows.
"

98   Note that in parallel to the work of this document, there is ongoing
99   work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
100   Considering the MPLS performance measurement with the Alternate-
101   Marking method can also be achieved by MNA encapsulation, it is
102   agreed that this document will be made Historic once the MNA solution
103   of performance measurement with the Alternate-Marking method is
104   published as an RFC.

[minor]
As other ADs suggested, this looks as an unusual statement.
What is the value of this section when the document is a proposed standard. Can it not be simply a rfc editor note and remove it when becoming RFC? (this is a non-blocking comment/observation)


196   The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
197   FLI MUST use the same values of the label immediately preceding the
198   XL.  In this case the TC and TTL for the XL and FLI MAY be of
199   different values. 

[major]
These two phrases seem to contradict each other. First sentence say they MUST use same values and the second sentence suggest that they MAY be different.
How is exception handling when a receiver receives (first sentence) the where FLI and XL and TC/TTL is not identical?

214   FL in a label stack.  The TTL for the FL MUST be zero to ensure that
215   it is not used inadvertently for forwarding.  The BoS bit for the FL
216   depends on whether the FL is placed at the bottom of the MPLS label
217   stack, i.e., the BoS bit for the FL is set only when the FL is placed
218   at the bottom of the MPLS label stack.

[minor]
What is the formal handling procedure when a receiver received (a transit node or mpls recipient) a packet where the FL is NOT zero?

412   service and the MPLS transport would be generated.  In this case, the
413   transit node needs to look up both of the two Flow-IDs by default.

[minor]
"the" transit node? Not sure the exact meaning of "the" is in this context.
There may be many transit nodes that the flow traverses. Would in this context using the word "a transit node" not be more technically correct?

418   Whether using the two methods mentioned above or other methods to
419   allocate Flow-ID, the NMS/controller MUST ensure that every generated
420   Flow-ID is unique within the administrative domain and MUST NOT have
421   any value in the reserved label space (0-15) [RFC3032].

[major]
I think that there should be understanding on what unique exactly means. for example, if at time=1 there is allocated FL=1234. next and time=2 the flow no longer exists. And at time=3 for a new unrelated flow there is allocation of FL=1234. Would that count as being unique?

What happens when the controller that allocated rebooted and lost all awareness of allocated LFIs? can it create new, potentially non-unique (over time) LFIs?

438   the on-path nodes is outside the scope of this document.  However,
439   [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

[minor]
The [I-D.xzc-lsr-mpls-flc-frld] document is not a WG accepted document. Is it really your objective to have this current standards based document fateshare with this not addopted informative reference?

451 7.  Equal-Cost Multipath Considerations

[minor]
Any concerns with mixing ELI/EL and FL? any impact between identifying flow and the entropy caused by Entropy Labels?

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15

# Thanks for the Shepherd writeup from Tony Li, providing useful insight in the origins of the document and the relationship with MNA.

#Thanks to Darren Dukes for the early RTGDIR review.

#GENERIC COMMENTS
#================
## I support the DISCUSS from John Scudder

## I was doubting between NoObjection and DISCUSS as there are items that to me look serious enough to be discussed more in detail in the WG.
However, the existing DISCUSS items from fellow IESG area directors will most likely cause that to happen anyway.

## I got confused with the text handling The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI where first the formal procedure is them to equal and next to state they MAY be different?

## If there is formal requiremnt to set some fields to 0 or 1 with a MUST, then exception procedures should be provided when a (transit) router receives an mpls packet with potentially non-conforming fields set. Should the packet be dropped? allowed? tagged? ICMP message created

## When inserting labels, then this impacts the packet IP MTU. This seems not discussed?

## The exact definition of 'unique' is not defined in the document. Does unique mean unique over  time? unique for any flow at any given time?  If a controller reboots, will it have to harvest all used LFIs that are running in the infrastructure?

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

84   [RFC9341] describes a performance measurement method, which can be
85   used to measure packet loss, delay, and jitter on data traffic.

[minor]
RFC9341 describes this as "live" traffic and not data traffic. I believe there is a substantial difference between the two

"
  This document describes the Alternate-Marking technique to perform
  packet loss, delay, and jitter measurements on live traffic.
"

87   it is referred to as the Alternate-Marking Method.  [RFC8372]
88   discusses aspects to consider when developing a solution for MPLS
89   flow identification for performance monitoring of MPLS flows.

[minor]
RFC8372 says the following:

"
  This document discusses aspects to consider when developing a
  solution for MPLS flow identification.  The key application that
  needs this solution is in-band performance monitoring of MPLS flows
  when MPLS is used to encapsulate user data packets.
"

Hence the phrase construct is not 100% correct. Maybe the following should be considered instead:

"
[RFC8372] outlines key considerations for developing a solution for MPLS flow identification, intended for use in performance monitoring of MPLS flows.
"

98   Note that in parallel to the work of this document, there is ongoing
99   work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
100   Considering the MPLS performance measurement with the Alternate-
101   Marking method can also be achieved by MNA encapsulation, it is
102   agreed that this document will be made Historic once the MNA solution
103   of performance measurement with the Alternate-Marking method is
104   published as an RFC.

[minor]
As other ADs suggested, this looks as an unusual statement.
What is the value of this section when the document is a proposed standard. Can it not be simply a rfc editor note and remove it when becoming RFC? (this is a non-blocking comment/observation)


196   The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
197   FLI MUST use the same values of the label immediately preceding the
198   XL.  In this case the TC and TTL for the XL and FLI MAY be of
199   different values. 

[major]
These two phrases seem to contradict each other. First sentence say they MUST use same values and the second sentence suggest that they MAY be different.
How is exception handling when a receiver receives (first sentence) the where FLI and XL and TC/TTL is not identical?

214   FL in a label stack.  The TTL for the FL MUST be zero to ensure that
215   it is not used inadvertently for forwarding.  The BoS bit for the FL
216   depends on whether the FL is placed at the bottom of the MPLS label
217   stack, i.e., the BoS bit for the FL is set only when the FL is placed
218   at the bottom of the MPLS label stack.

[minor]
What is the formal handling procedure when a receiver received (a transit node or mpls recipient) a packet where the FL is NOT zero?

412   service and the MPLS transport would be generated.  In this case, the
413   transit node needs to look up both of the two Flow-IDs by default.

[minor]
"the" transit node? Not sure the exact meaning of "the" is in this context.
There may be many transit nodes that the flow traverses. Would in this context using the word "a transit node" not be more technically correct?

418   Whether using the two methods mentioned above or other methods to
419   allocate Flow-ID, the NMS/controller MUST ensure that every generated
420   Flow-ID is unique within the administrative domain and MUST NOT have
421   any value in the reserved label space (0-15) [RFC3032].

[major]
I think that there should be understanding on what unique exactly means. for example, if at time=1 there is allocated FL=1234. next and time=2 the flow no longer exists. And at time=3 for a new unrelated flow there is allocation of FL=1234. Would that count as being unique?

What happens when the controller that allocated rebooted and lost all awareness of allocated LFIs? can it create new, potentially non-unique (over time) LFIs?

438   the on-path nodes is outside the scope of this document.  However,
439   [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

[minor]
The [I-D.xzc-lsr-mpls-flc-frld] document is not a WG accepted document. Is it really your objective to have this current standards based document fateshare with this not addopted informative reference?

451 7.  Equal-Cost Multipath Considerations

[minor]
Any concerns with mixing ELI/EL and FL? any impact between identifying flow and the entropy caused by Entropy Labels?

[Ballot comment]
I agree with Éric and John about the text in the Introduction about this doc becoming historic when draft-ietf-mpls-mna-fwk gets published ("it is agreed..."). However, I believe that can be fixed by changing that text, removing any such "requirement" from this document, and expanding on the context and similarities with draft-ietf-mpls-mna-fwk (and I hope the responsible AD will work with the authors on it).

[Ballot discuss]
Thanks for working on this specification.

I have noted this specificaiton uses RFC 9341 performance measurement methods. RFC 9341 says -

  "the Alternate-Marking Method MUST only be applied to controlled domains."

Hence, I would like to discuss

  - if MPLS performance measurement will be done in "controlled domains" or not. If yes, should this specification not discuss and state about measurement done in "controlled domains"?

  - current security consideration does not describe the implications if the measurement is not done in the controlled domains, should this specification not describe those?

[Ballot comment]
Ooof, this is a hard one...

While balloting I have repeatedly cycled between DISCUSS, Abstain, and No Objection.

This text makes me want to Abstain like Eric:
"Note that in parallel to the work of this document, there is ongoing
work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
Considering the MPLS performance measurement with the Alternate-
Marking method can also be achieved by MNA encapsulation, it is
agreed that this document will be made Historic once the MNA solution
of performance measurement with the Alternate-Marking method is
published as an RFC."
It feels distinctly weird for a document to be published with a built in expiration date -- but this is tempered by the fact that 1: there is (apparently) WG consensus behind this and 2: there are implementations, so... well, I finally decided to not Abstain.

I very strongly agree with Roman on:
"Why is the SHOULD in (b), (c) and (d) not a MUST? 

If (a) mandates that there is no signaling of the Flow-ID outside of the administrative domain, (b) and (c) should be mandatory to enforce that policy."
.. but he is already carrying the DISCUSS. While I could also ballot DISCUSS on this point, I feel that this would be redundant, and so I'll jsut note that I am supporting his position.
The same goes for John Scudder's DISCUSS, both on the limited number of flows, and the PHP issue.

I'd also like to thank Daniele Ceccarelli for the Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-mpls-inband-pm-encapsulation-14-opsdir-lc-ceccarelli-2024-08-23/) and the authors for engaging.

[Ballot discuss]
** Section 8. 

There appears be conflicting guidance on how to handle packets on the administrative domain boundary.

  (a) The Flow-ID
  label MUST NOT be signaled and distributed outside the administrative
  domain.

  (b) To prevent packets carrying Flow-ID labels from leaking from one
  domain to another, domain boundary nodes SHOULD deploy policies
  (e.g., ACL) to filter out these packets.

  (c) Specifically, at the
  sending edge, the domain boundary node SHOULD filter out the packets
  that carry the Flow-ID Label Indicator and are sent to other domains.

  (d) At the receiving edge, the domain boundary node SHOULD drop the
  packets that carry the Flow-ID Label Indicator and are from other
  domains.

Why is the SHOULD in (b), (c) and (d) not a MUST? 

If (a) mandates that there is no signaling of the Flow-ID outside of the administrative domain, (b) and (c) should be mandatory to enforce that policy.

If (d) uses a weaker “SHOULD”, what would the receiving edge do with the packet if not drop it?

[Ballot comment]
** For the responsible AD and WG chairs: I observe that this document doesn’t fit neatly into the work items described in the “The current WG focus areas and work items” section of https://datatracker.ietf.org/doc/charter-ietf-mpls/07/

** Section 6.
  How the ingress node knows the FLC and FRLD of all
  the on-path nodes is outside the scope of this document.  However,
  [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

Why make a reference to an expired, individual submission if the methodology is out of scope?

[Ballot comment]
Note:  routing and MPLS are not my strong suit. And while the Introduction looks a little unusual, Tony Li's explanation on the list makes sense (to this 'not a routing' person).

I have one comment:

Section 8, paragraph 1:  Like Eric V., I also don't see the security consideration in this paragraph.  I would ask why 'the value of a Flow-ID label MUST be unique within the administrative domain'?  What result does a collision in the labels cause?

[Ballot discuss]
Thanks for this document. I agree with Éric Vyncke that the paragraph in the introduction about moving to Historic is unusual, to say the least. However, if the working group has consensus to publish the document in this form, I won’t stand in their way.

I do have three points I'd like to discuss, and also a comment.

## DISCUSS

### Section 3, same values, or different?

  The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
  FLI MUST use the same values of the label immediately preceding the
  XL.  In this case the TC and TTL for the XL and FLI MAY be of
  different values. 

The "in this case" sentence doesn't make sense to me (what case is "this case"?), and seems to contradict the preceding sentence. Either they MUST use the same values, or not. Which is it? Is there something missing before the "in this case" sentence?

### Number of flows vs. ECMP

Section 3 says,

  The Flow-ID Label (FL) is used as an MPLS flow identification
  [RFC8372].  Its value MUST be unique within the administrative
  domain.
 
So, there can be at most 2^20 flows per administrative domain. That seems small, but I guess it's OK if I think of the number of instrumented flows as being a small fraction of the total flows that exist. But then later, Section 7 says,

  Analogous to what's described in Section 5 of [RFC8957], under
  conditions of Equal-Cost Multipath (ECMP), the introduction of the FL
  may lead to the same problem as caused by the Synonymous Flow Label
  (SFL).  The two solutions proposed for SFL would also apply here.
  Specifically, adding FL to an existing flow may cause that flow to
  take a different path.  If the operator expects to resolve this
  problem, they can choose to apply entropy labels [RFC6790] **or add FL
  to all flows**.

(Emphasis added.)

When I add these up, it seems to me that the operator of a large network has some unpleasant options.

- They can accept that the use of FL may perturb the path taken by the flow. But that seems unacceptable for a technology whose purpose is performance measurement.

- They can use entropy label.

- They can add FL to all flows, but this means they have to instrument every flow, so they really are restricted to 2^20 total flows in their network. That is a rather small number, probably too small for a significant deployment.

The conclusion I arrive at is that any deployment at scale has to use entropy label. Is that correct? If so it seems to me it would be better to be more up-front about it. If I'm mistaken (e.g. there's some realistic use case where it's fine to accept the observer effect perturbing the selected path, or where 2^20 flows is more than enough) I'd appreciate some help seeing it.

### Penultimate hop popping creates a conflict

Section 4 has,

  *  The processing node MUST pop the XL, FLI and FL from the MPLS
      label stack when it needs to pop the preceding forwarding label.
      The egress node MUST pop the whole MPLS label stack, and this
      document doesn't introduce any new process to the decapsulated
      packet.

But Section 3.1 said,

  Note that here if the penultimate hop popping (PHP) is in use, the
  PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the
  following Flow-ID label, otherwise the egress LSR would be excluded
  from the performance measurement.
 
As far as I can tell, these two are in conflict, and there's no way to comply with both other than by disabling PHP. That's OK I guess, but if so you should just say PHP isn't allowed.

By the way (and this is not DISCUSS level, just included here since we're already talking about this section) I find it problematic that a subsection called "examples" includes normative requirements, which 3.1 does in two places -- the quote above, and also,

  Note that for this example, the two Flow-ID Label values appearing in
  a label stack MUST be different.  In other words, the Flow-ID label
  applied to the MPLS transport and the Flow-ID label applied to the
  MPLS service MUST be different.  Also, note that the two Flow-ID
  label values are independent of each other.  For example, two packets
  can belong to the same VPN flow but different LSP flows, or two
  packets can belong to different VPN flows but the same LSP flow.

[Ballot discuss]
Thanks for this document. I agree with Éric Vyncke that the paragraph in the introduction about moving to Historic is unusual, to say the least. However, if the working group has consensus to publish the document in this form, I won’t stand in their way.

## DISCUSS

### Section 3, same values, or different?

  The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
  FLI MUST use the same values of the label immediately preceding the
  XL.  In this case the TC and TTL for the XL and FLI MAY be of
  different values. 

The "in this case" sentence doesn't make sense to me (what case is "this case"?), and seems to contradict the preceding sentence. Either they MUST use the same values, or not. Which is it? Is there something missing before the "in this case" sentence?

### Number of flows vs. ECMP

Section 3 says,

  The Flow-ID Label (FL) is used as an MPLS flow identification
  [RFC8372].  Its value MUST be unique within the administrative
  domain.
 
So, there can be at most 2^20 flows per administrative domain. That seems small, but I guess it's OK if I think of the number of instrumented flows as being a small fraction of the total flows that exist. But then later, Section 7 says,

  Analogous to what's described in Section 5 of [RFC8957], under
  conditions of Equal-Cost Multipath (ECMP), the introduction of the FL
  may lead to the same problem as caused by the Synonymous Flow Label
  (SFL).  The two solutions proposed for SFL would also apply here.
  Specifically, adding FL to an existing flow may cause that flow to
  take a different path.  If the operator expects to resolve this
  problem, they can choose to apply entropy labels [RFC6790] **or add FL
  to all flows**.

(Emphasis added.)

When I add these up, it seems to me that the operator of a large network has some unpleasant options.

- They can accept that the use of FL may perturb the path taken by the flow. But that seems unacceptable for a technology whose purpose is performance measurement.

- They can use entropy label.

- They can add FL to all flows, but this means they have to instrument every flow, so they really are restricted to 2^20 total flows in their network. That is a rather small number, probably too small for a significant deployment.

The conclusion I arrive at is that any deployment at scale has to use entropy label. Is that correct? If so it seems to me it would be better to be more up-front about it. If I'm mistaken (e.g. there's some realistic use case where it's fine to accept the observer effect perturbing the selected path, or where 2^20 flows is more than enough) I'd appreciate some help seeing it.

### Penultimate hop popping creates a conflict

Section 4 has,

  *  The processing node MUST pop the XL, FLI and FL from the MPLS
      label stack when it needs to pop the preceding forwarding label.
      The egress node MUST pop the whole MPLS label stack, and this
      document doesn't introduce any new process to the decapsulated
      packet.

But Section 3.1 said,

  Note that here if the penultimate hop popping (PHP) is in use, the
  PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the
  following Flow-ID label, otherwise the egress LSR would be excluded
  from the performance measurement.
 
As far as I can tell, these two are in conflict, and there's no way to comply with both other than by disabling PHP. That's OK I guess, but if so you should just say PHP isn't allowed.

By the way (and this is not DISCUSS level, just included here since we're already talking about this section) I find it problematic that a subsection called "examples" includes normative requirements, which 3.1 does in two places -- the quote above, and also,

  Note that for this example, the two Flow-ID Label values appearing in
  a label stack MUST be different.  In other words, the Flow-ID label
  applied to the MPLS transport and the Flow-ID label applied to the
  MPLS service MUST be different.  Also, note that the two Flow-ID
  label values are independent of each other.  For example, two packets
  can belong to the same VPN flow but different LSP flows, or two
  packets can belong to different VPN flows but the same LSP flow.

[Ballot comment]
### Section 8, ACLs

The Shepherd write-up, and Section 9, indicate that this specification has been implemented. Section 8 says,

  To prevent packets carrying Flow-ID labels from leaking from one
  domain to another, domain boundary nodes SHOULD deploy policies
  (e.g., ACL) to filter out these packets.  Specifically, at the
  sending edge, the domain boundary node SHOULD filter out the packets
  that carry the Flow-ID Label Indicator and are sent to other domains.
  At the receiving edge, the domain boundary node SHOULD drop the
  packets that carry the Flow-ID Label Indicator and are from other
  domains.

Do the existing implementations provide the necessary ACL primitives to comply with the SHOULD above? For that matter, why are these SHOULD and not MUST?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15

Thank you for the work put into this document. As this I-D is about very specific protocols, I have only reviewed it from the high level perspective.

I am balloting ABSTAIN because I am neither comfortable nor confident that having a time bomb (see below about MNA) in a published RFC is sensible.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tony Li for the shepherd's write-up even if more information about the 'time bomb' would have assisted my reading.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Having the time bomb...

Both the shepherd's write-up and section 1 `it is agreed that this document will be made Historic` contain a trigger bomb to make this document historic. No explanations are given, so I guess that this was a WG compromise but without any further justification, it is hard to tell and hard to judge the IETF consensus.

Why has the MPLS WG (and IETF Last Call and then the IESG) worked on this document if it was clear that it will become historic ?

I am not convinced that `it is agreed` in an IETF RFC is meaningful.

If the authors or the MPLS WG have a precedent case in a published RFC, then I will be happy to read it.

## Section 2.1

Beyond acronyms expansions, some information references (e.g., for IPFIX or MNA), or some concise definitions (e.g., for eSPL or cSPL) would be useful for the readers.

## Section 3

Possibly linked to my lack of MPLS expertise, I wonder why fields MUST be identical and MAY differ in `The Traffic Class (TC) and Time To Live (TTL) fields of the XL and FLI MUST use the same values of the label immediately preceding the XL. In this case the TC and TTL for the XL and FLI MAY be of different values. ` Should `In this case` be more specific ?

What is the expected behavior when the TC/TTL are not using the same value ? Is this specified in other MPLS document or should it be specified in this I-D ?

## Section 4

Also probably due to my own lack of expertise, how can a transit MPLS node know that it needs to do 'deep packet inspection' ?

BTW, as 'deep packet inspection' is usually used in a security context to look in the application payload, may I suggest to use 'labels look-ahead' or something similar ?

## Section 7

Please add a reference for `Synonymous Flow Label`.

## Section 8

While I understand that it is not clean when packets with those labels leak outside the admin domain, what are the *actual security issues* ? E.g., DoS ? privacy ?

# NITS (non-blocking / cosmetic)

## Section 3

Rather than `as shown in figure below` please use the figure number.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-mpls-inband-pm-encapsulation-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Extended Special-Purpose MPLS Label Values registry in the Special-Purpose Multiprotocol Label Switching (MPLS) Label Values registry group located at:

https://www.iana.org/assignments/mpls-label-values/

a single new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Flow-ID Label Indicator (FLI)
Reference: [ RFC-to-be ]

IANA notes that the authors have requested Value: 18 for this new registration.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-08-19):

From: The IESG
To: IETF-Announce
CC: draft-ietf-mpls-inband-pm-encapsulation@ietf.org, james.n.guichard@futurewei.com, mpls-chairs@ietf.org, mpls@ietf.org, tony.li@tony.li, tsaad@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Encapsulation For MPLS Performance Measurement with Alternate-Marking Method) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Encapsulation For MPLS
Performance Measurement with Alternate-Marking
  Method'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-08-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines the encapsulation for MPLS performance
  measurement with the Alternate-Marking method, which performs flow-
  based packet loss, delay, and jitter measurements on the MPLS
  traffic.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6376/
  https://datatracker.ietf.org/ipr/4745/
  https://datatracker.ietf.org/ipr/6363/

Document shepherd writeup for draft-ietf-mpls-inband-pm-encapsulation

Document History
----------------

> Does the working group (WG) consensus represent the strong
> concurrence of a few individuals, with others being silent, or did
> it reach broad agreement?

This document has broad support.


> Was there controversy about particular points, or were there
> decisions where the consensus was particularly rough?

There has been some discussion about some points. Of particular
interest is the document's relationship to MPLS Network Actions
(MNA), since there is some functional overlap and this document
already has an installed base. The consensus of the WG is to publish
this document, but to move it to Historical after an MNA based
alternative is published.


> Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the responsible Area Director. (It should
> be in a separate email because this questionnaire is publicly
> available.)

No one has proposed an appeal or has expressed any lasting discontent
with the document.


> For protocol documents, are there existing implementations of the
> contents of the document? Have a significant number of potential
> implementers indicated plans to implement? Are any existing
> implementations reported somewhere, either in the document itself
> (as RFC 7942 recommends) or elsewhere (where)?

Implementation information is discussed in Section 8 of the document.


Additional Reviews
------------------

> Do the contents of this document closely interact with technologies
> in other IETF working groups or external organizations, and would it
> therefore benefit from their review? Have those reviews occurred? If
> yes, describe which reviews took place.

No, this document would not cause interactions with other working
groups. The document was reviewed by the Routing Directorate and all
concerns raised have been addressed.


> Describe how the document meets any required formal expert review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
> type reviews.

Not applicable.


> If the document contains a YANG module, has the final version of the
> module been checked with any of the recommended validation tools for
> syntax and formatting validation? If there are any resulting errors
> or warnings, what is the justification for not fixing them at this
> time? Does the YANG module comply with the Network Management
> Datastore Architecture (NMDA) as specified in RFC 8342?

Not applicable.


> Describe reviews and automated checks performed to validate sections
> of the final version of the document written in a formal language,
> such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.


Document Shepherd Checks
------------------------

> Based on the shepherd's review of the document, is it their opinion
> that this document is needed, clearly written, complete, correctly
> designed, and ready to be handed off to the responsible Area Director?

In the eyes of this shepherd, the document is a needed description of
an existing, deployed feature that is likely to be supplanted by
better mechanisms in the near future. Publication is warranted due to
the installed base. The document is reasonably clearly written,
reasonably complete, reasonably designed, and reasonably ready to be
handed off to the responsible Area Director. No document is perfect.


> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been
> identified and addressed? For which does this still need to happen
> in subsequent reviews?

The document has been reviewed with respect to the Routing Area AD
Nits issues list. No open issues remain.


> What type of RFC publication is being requested on the IETF stream
> (Best Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper
> type of RFC? Do all Datatracker state attributes correctly reflect
> this intent?

This is being submitted as a Proposed Standard. This is an extension
to MPLS that has been implemented and deployed. To allocate an
extended special purpose label, it needs to progress by standards
action. If and when a comparable MNA based proposal is ratified by the
WG, it has been agreed that this document will transition to
Historical. This agreement is recorded in the document text.


> Have reasonable efforts been made to remind all authors of the
> intellectual property rights (IPR) disclosure obligations described
> in BCP 79? To the best of your knowledge, have all required
> disclosures been filed? If not, explain why. If yes, summarize any
> relevant discussion, including links to publicly-available messages
> when applicable.

Immediately before WGLC, an IPR poll was conducted of all authors and
contributors.  This resulted in the submission of two IPR claims after
which all parties responded. The organizations that submitted the
claims were very late in doing so and have published apologies to the
WG. To the best of my knowledge, all disclosures have been filed.

IPR poll thread, including responses and apologies:
https://mailarchive.ietf.org/arch/msg/mpls/Thu0tA24sbmC1OyX22gqscbmDYQ/


> Has each author, editor, and contributor shown their willingness to
> be listed as such? If the total number of authors and editors on the
> front page is greater than five, please provide a justification.

Yes.


> Document any remaining I-D nits in this document. Simply running the
> idnits tool is not enough; please review the "Content Guidelines" on
> authors.ietf.org. (Also note that the current idnits tool generates
> some incorrect warnings; a rewrite is underway.)

None observed.


> Should any informative references be normative or vice-versa? See
> the IESG Statement on Normative and Informative References.

Everything seems appropriate.


> List any normative references that are not freely available to
> anyone. Did the community have sufficient access to review any such
> normative references?

Not applicable, all normative references are RFCs.


> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so, list
> them.

Not applicable, all normative references are Proposed Standards.


> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear
> state? If so, what is the plan for their completion?

Not applicable, all normative references are RFCs.


> Will publication of this document change the status of any existing
> RFCs? If so, does the Datatracker metadata correctly reflect this
> and are those RFCs listed on the title page, in the abstract, and
> discussed in the introduction? If not, explain why and point to the
> part of the document where the relationship of this document to
> these other RFCs is discussed.

No, this is a pure extension of existing mechanisms and does not
update or obsolete any other document.


> Describe the document shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of
> the document. Confirm that all aspects of the document requiring
> IANA assignments are associated with the appropriate reservations in
> IANA registries. Confirm that any referenced IANA registries have
> been clearly identified. Confirm that each newly created IANA
> registry specifies its initial contents, allocations procedures, and
> a reasonable name (see RFC 8126).

The authors have addressed all comments on the IANA considerations.


> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert
> clear? Please include suggestions of designated experts, if
> appropriate.

Not applicable. The document does not request any new registries.

Document shepherd writeup for draft-ietf-mpls-inband-pm-encapsulation

Document History
----------------

> Does the working group (WG) consensus represent the strong
> concurrence of a few individuals, with others being silent, or did
> it reach broad agreement?

This document has broad support.


> Was there controversy about particular points, or were there
> decisions where the consensus was particularly rough?

There has been some discussion about some points. Of particular
interest is the document's relationship to MPLS Network Actions
(MNA), since there is some functional overlap and this document
already has an installed base. The consensus of the WG is to publish
this document, but to move it to Historical after an MNA based
alternative is published.


> Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the responsible Area Director. (It should
> be in a separate email because this questionnaire is publicly
> available.)

No one has proposed an appeal or has expressed any lasting discontent
with the document.


> For protocol documents, are there existing implementations of the
> contents of the document? Have a significant number of potential
> implementers indicated plans to implement? Are any existing
> implementations reported somewhere, either in the document itself
> (as RFC 7942 recommends) or elsewhere (where)?

Implementation information is discussed in Section 8 of the document.


Additional Reviews
------------------

> Do the contents of this document closely interact with technologies
> in other IETF working groups or external organizations, and would it
> therefore benefit from their review? Have those reviews occurred? If
> yes, describe which reviews took place.

No, this document would not cause interactions with other working
groups. The document was reviewed by the Routing Directorate and all
concerns raised have been addressed.


> Describe how the document meets any required formal expert review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
> type reviews.

Not applicable.


> If the document contains a YANG module, has the final version of the
> module been checked with any of the recommended validation tools for
> syntax and formatting validation? If there are any resulting errors
> or warnings, what is the justification for not fixing them at this
> time? Does the YANG module comply with the Network Management
> Datastore Architecture (NMDA) as specified in RFC 8342?

Not applicable.


> Describe reviews and automated checks performed to validate sections
> of the final version of the document written in a formal language,
> such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.


Document Shepherd Checks
------------------------

> Based on the shepherd's review of the document, is it their opinion
> that this document is needed, clearly written, complete, correctly
> designed, and ready to be handed off to the responsible Area Director?

In the eyes of this shepherd, the document is a needed description of
an existing, deployed feature that is likely to be supplanted by
better mechanisms in the near future. Publication is warranted due to
the installed base. The document is reasonably clearly written,
reasonably complete, reasonably designed, and reasonably ready to be
handed off to the responsible Area Director. No document is perfect.


> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been
> identified and addressed? For which does this still need to happen
> in subsequent reviews?

The document has been reviewed with respect to the Routing Area AD
Nits issues list. No open issues remain.


> What type of RFC publication is being requested on the IETF stream
> (Best Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper
> type of RFC? Do all Datatracker state attributes correctly reflect
> this intent?

This is being submitted as a Proposed Standard. This is an extension
to MPLS that has been implemented and deployed. To allocate an
extended special purpose label, it needs to progress by standards
action. If and when a comparable MNA based proposal is ratified by the
WG, it has been agreed that this document will transition to
Historical. This agreement is recorded in the document text.


> Have reasonable efforts been made to remind all authors of the
> intellectual property rights (IPR) disclosure obligations described
> in BCP 79? To the best of your knowledge, have all required
> disclosures been filed? If not, explain why. If yes, summarize any
> relevant discussion, including links to publicly-available messages
> when applicable.

Immediately before WGLC, an IPR poll was conducted of all authors and
contributors.  This resulted in the submission of two IPR claims after
which all parties responded. The organizations that submitted the
claims were very late in doing so and have published apologies to the
WG. To the best of my knowledge, all disclosures have been filed.

IPR poll thread, including responses and apologies:
https://mailarchive.ietf.org/arch/msg/mpls/Thu0tA24sbmC1OyX22gqscbmDYQ/


> Has each author, editor, and contributor shown their willingness to
> be listed as such? If the total number of authors and editors on the
> front page is greater than five, please provide a justification.

Yes.


> Document any remaining I-D nits in this document. Simply running the
> idnits tool is not enough; please review the "Content Guidelines" on
> authors.ietf.org. (Also note that the current idnits tool generates
> some incorrect warnings; a rewrite is underway.)

None observed.


> Should any informative references be normative or vice-versa? See
> the IESG Statement on Normative and Informative References.

Everything seems appropriate.


> List any normative references that are not freely available to
> anyone. Did the community have sufficient access to review any such
> normative references?

Not applicable, all normative references are RFCs.


> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so, list
> them.

Not applicable, all normative references are Proposed Standards.


> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear
> state? If so, what is the plan for their completion?

Not applicable, all normative references are RFCs.


> Will publication of this document change the status of any existing
> RFCs? If so, does the Datatracker metadata correctly reflect this
> and are those RFCs listed on the title page, in the abstract, and
> discussed in the introduction? If not, explain why and point to the
> part of the document where the relationship of this document to
> these other RFCs is discussed.

No, this is a pure extension of existing mechanisms and does not
update or obsolete any other document.


> Describe the document shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of
> the document. Confirm that all aspects of the document requiring
> IANA assignments are associated with the appropriate reservations in
> IANA registries. Confirm that any referenced IANA registries have
> been clearly identified. Confirm that each newly created IANA
> registry specifies its initial contents, allocations procedures, and
> a reasonable name (see RFC 8126).

The authors have addressed all comments on the IANA considerations.


> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert
> clear? Please include suggestions of designated experts, if
> appropriate.

Not applicable. The document does not request any new registries.

DRAFT DRAFT DRAFT

Document writeup for draft-ietf-mpls-inband-pm-encapsulation

Document History
----------------

> Does the working group (WG) consensus represent the strong
> concurrence of a few individuals, with others being silent, or did
> it reach broad agreement?

This document has broad support.


> Was there controversy about particular points, or were there
> decisions where the consensus was particularly rough?

There has been some discussion about some points. Of particular
interest is the document's relationship to MPLS Network Actions
(MNA), since there is some functional overlap and this document
already has an installed base. The consensus of the WG is to publish
this document, but to move it to Historical after an MNA based
alternative is published.


> Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the responsible Area Director. (It should
> be in a separate email because this questionnaire is publicly
> available.)

No one has proposed an appeal or has expressed any lasting discontent
with the document.


> For protocol documents, are there existing implementations of the
> contents of the document? Have a significant number of potential
> implementers indicated plans to implement? Are any existing
> implementations reported somewhere, either in the document itself
> (as RFC 7942 recommends) or elsewhere (where)?

Implementation information is discussed in Section 8 of the document.


Additional Reviews
------------------

> Do the contents of this document closely interact with technologies
> in other IETF working groups or external organizations, and would it
> therefore benefit from their review? Have those reviews occurred? If
> yes, describe which reviews took place.

No, this document would not cause interactions with other working
groups. The document was reviewed by the Routing Directorate and all
concerns raised have been addressed.


> Describe how the document meets any required formal expert review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
> type reviews.

Not applicable.


> If the document contains a YANG module, has the final version of the
> module been checked with any of the recommended validation tools for
> syntax and formatting validation? If there are any resulting errors
> or warnings, what is the justification for not fixing them at this
> time? Does the YANG module comply with the Network Management
> Datastore Architecture (NMDA) as specified in RFC 8342?

Not applicable.


> Describe reviews and automated checks performed to validate sections
> of the final version of the document written in a formal language,
> such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

Not applicable.


Document Shepherd Checks
------------------------

> Based on the shepherd's review of the document, is it their opinion
> that this document is needed, clearly written, complete, correctly
> designed, and ready to be handed off to the responsible Area Director?

In the eyes of this shepherd, the document is a needed description of
an existing, deployed feature that is likely to be supplanted by
better mechanisms in the near future. Publication is warranted due to
the installed base. The document is reasonably clearly written,
reasonably complete, reasonably designed, and reasonably ready to be
handed off to the responsible Area Director. No document is perfect.


> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been
> identified and addressed? For which does this still need to happen
> in subsequent reviews?

The document has been reviewed with respect to the Routing Area AD
Nits issues list. No open issues remain.


> What type of RFC publication is being requested on the IETF stream
> (Best Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper
> type of RFC? Do all Datatracker state attributes correctly reflect
> this intent?

This is being submitted as a Proposed Standard. This is an extension
to MPLS that has been implemented and deployed. To allocate an
extended special purpose label, it needs to progress by standards
action. If and when a comparable MNA based proposal is ratified by the
WG, it has been agreed that this document will transition to
Historical. This agreement is recorded in the document text.


> Have reasonable efforts been made to remind all authors of the
> intellectual property rights (IPR) disclosure obligations described
> in BCP 79? To the best of your knowledge, have all required
> disclosures been filed? If not, explain why. If yes, summarize any
> relevant discussion, including links to publicly-available messages
> when applicable.

Immediately before WGLC, an IPR poll was conducted of all authors and
contributors.  This resulted in the submission of two IPR claims after
which all parties responded. The organizations that submitted the
claims were very late in doing so and have published apologies to the
WG. To the best of my knowledge, all disclosures have been filed.

IPR poll thread, including responses and apologies:
https://mailarchive.ietf.org/arch/msg/mpls/Thu0tA24sbmC1OyX22gqscbmDYQ/


> Has each author, editor, and contributor shown their willingness to
> be listed as such? If the total number of authors and editors on the
> front page is greater than five, please provide a justification.

Yes.


> Document any remaining I-D nits in this document. Simply running the
> idnits tool is not enough; please review the "Content Guidelines" on
> authors.ietf.org. (Also note that the current idnits tool generates
> some incorrect warnings; a rewrite is underway.)

None observed.


> Should any informative references be normative or vice-versa? See
> the IESG Statement on Normative and Informative References.

I believe that one correction should be made and that RFC 9341 should
be informative. This writeup will be amended when that is done.


> List any normative references that are not freely available to
> anyone. Did the community have sufficient access to review any such
> normative references?

Not applicable, all normative references are RFCs.


> Are there any normative downward references (see RFC 3967 and BCP
> 97) that are not already listed in the DOWNREF registry? If so, list
> them.

Not applicable, all normative references are RFCs.


> Are there normative references to documents that are not ready to be
> submitted to the IESG for publication or are otherwise in an unclear
> state? If so, what is the plan for their completion?

Not applicable, all normative references are RFCs.


> Will publication of this document change the status of any existing
> RFCs? If so, does the Datatracker metadata correctly reflect this
> and are those RFCs listed on the title page, in the abstract, and
> discussed in the introduction? If not, explain why and point to the
> part of the document where the relationship of this document to
> these other RFCs is discussed.

No, this is a pure extension of existing mechanisms and does not
update or obsolete any other document.


> Describe the document shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of
> the document. Confirm that all aspects of the document requiring
> IANA assignments are associated with the appropriate reservations in
> IANA registries. Confirm that any referenced IANA registries have
> been clearly identified. Confirm that each newly created IANA
> registry specifies its initial contents, allocations procedures, and
> a reasonable name (see RFC 8126).

There are issues here that have been raised with the authors. This
writeup will be amended when those issues have been addressed.


> List any new IANA registries that require Designated Expert Review for
> future allocations. Are the instructions to the Designated Expert
> clear? Please include suggestions of designated experts, if
> appropriate.

Not applicable. The document does not request any new registries.