Skip to main content

Last Call Review of draft-ietf-mpls-inband-pm-encapsulation-14
review-ietf-mpls-inband-pm-encapsulation-14-opsdir-lc-ceccarelli-2024-08-23-00

Request Review of draft-ietf-mpls-inband-pm-encapsulation
Requested revision No specific revision (document currently at 18)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-08-26
Requested 2024-08-05
Requested by Jim Guichard
Authors Weiqiang Cheng , Xiao Min , Tianran Zhou , Jinyou Dai , Yoav Peleg
I-D last updated 2024-08-23
Completed reviews Rtgdir Early review of -08 by Darren Dukes (diff)
Opsdir Last Call review of -14 by Daniele Ceccarelli (diff)
Opsdir Telechat review of -15 by Daniele Ceccarelli (diff)
Assignment Reviewer Daniele Ceccarelli
State Completed
Request Last Call review on draft-ietf-mpls-inband-pm-encapsulation by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/1Cng2k-Ltd9Q2LDpZkrgPYbDefI
Reviewed revision 14 (document currently at 18)
Result Has issues
Completed 2024-08-23
review-ietf-mpls-inband-pm-encapsulation-14-opsdir-lc-ceccarelli-2024-08-23-00
General comments:
The intro says: "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." The first reaction to this statement is: how long will it take for the
MNA encapsulation to be delivered? If we already know that this will be
obsoleted by the MNA encapsulation, is it worth publishing it?

Detailed comments below:
- Section 3: I was expecting a bit of intro/explanation here. The section
starts saying that the encapsulation has this format. Boom. Is it something
that already exists? If so where has it been defined? If not could we say
something like" this document defines a new encapsulation as shown in figure
below..." - Section 3 suggest rephrasing. OLD
 The Traffic Class (TC) and Time To Live (TTL) [RFC3032] for the XL
   and FLI MUST use the same field values as the label immediately
   preceding the XL. unless it is known that the XL will not be exposed
   as the top label at any point along the LSP.
NEW
 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, unless it is known that the XL will not be exposed
   as the top label at any point along the LSP.
Is the "unless..." really necessary? Can't this be always the case?
- Section 3: "The BoS bit for the FL
   depends on whether the FL is placed at the bottom of the MPLS label
   stack, i.e., the BoS bit for the FL is set only when the FL is placed
   at the bottom of the MPLS label stack.
Isn't this always the case?
- Section 3: To achieve the purpose
   of coloring the MPLS traffic, and to distinguish between hop-by-hop
   measurement and edge-to-edge measurement, the TC for the FL is
   defined as follows:
The TC is a single field 3 bits long and here it's used as 3 independent flags.
I'm not sure if this is possible, but if it is it must at least be explained. -
Examples section highly appreciated - Section 4,5 and 6 clear