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

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?

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

# 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?

Thanks for all your work!

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.

I support John Scudder's DISCUSS.

(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?

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.

Thanks for addressing my discuss point.