[mpls] Re: Gunter Van de Velde's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

[[e-mail]]

Hi Gunter,

Thanks for your review and comments.
Please see inline.

Original


From: GunterVandeVeldeviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月04日 21:14
Subject: Gunter Van de Velde's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

Gunter Van de Velde has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: No Objection
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/
 
 
 
----------------------------------------------------------------------
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.
 [XM]>>> Understood.


## 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?
 [XM]>>> It's a bug that should have been fixed in version -15. It's been fixed in version -16.


## 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
 [XM]>>> In my experience not all field requirements need to be accompanied by a exception procedure. It's case by case.


## When inserting labels, then this impacts the packet IP MTU. This seems not
discussed?
 [XM]>>> Considering the Flow-ID label introduced in this document is similar to the Entropy label introduced in RFC 6790, I checked that RFC and didn't find MTU related discussion. And then I checked RFC 8662, in Section 10.2 it says "Also, the bandwidth overhead and potential MTU issues of deep label stacks should be considered in the network design", which is the only one MTU related discussion I can find.


## 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?
 [XM]>>> I believe it's "unique for any flow at any given time". If a controller reboots, I checked it with my colleague who has implemented this feature in ZTE, I was told that the controller won't lose its database of the used Flow-IDs, and if needed, the databases between the controller and the node can be synchronized by manual trigger.


#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.
" 
 [XM]>>> In version -12 it's changed from "live traffic" to "data traffic" due to the comment from Greg Mirsky. Do you prefer "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. " 
 [XM]>>> Yes, your text is better. Will use it in the next revision.


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)
 [XM]>>> I'll let the responsible AD and MPLS chairs to decide.


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?
 [XM]>>> As I've replied to Eric and John, "In this case..." should have been deleted along with the deletion of "unless..." in version -15. It's been fixed in version -16.


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?
 [XM]>>> Do you mean "TTL for the FL" is NOT zero? If yes, the quoted sentence "The TTL for the FL MUST be zero to ensure that it is not used inadvertently for forwarding" was borrowed from Section 4.2 of RFC 6790, and I don't find the handling procedure when a receiver received a packet where the TTL for 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?
 [XM]>>> Yes, "a transit node" is more technically correct. Will make this change in the next revision.


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?
 [XM]>>> In Section 5 two ways of allocating Flow-ID are described, manual trigger and automatic trigger. For manual trigger, the flow 1234 is provisioned at the node and this flow always exists. For automatic trigger, there is an aging time for the flow 1234, and after this flow ages, the controller can reallocate 1234. Is there any suggested text?


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?
 [XM]>>> Normally when a controller reboots, the controller won't lose its database of the allocated Flow-IDs. If needed, the databases between the controller and the node can be synchronized by manual trigger. In an abnormal situation, if the controller wants to allocate an existing Flow-ID, the node would reject it and send an error to the controller.


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?
 [XM]>>> As I've responded to Roman, I'm ok to delete "However,...". Will make this change in the next revision.


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?
 [XM]>>> No. As far as I know, it works well in the real delopyment with mixing EL and FL. 
 




Best Regards,
Xiao Min