[mpls] AD review for draft-ietf-mpls-inband-pm-encapsulation-13

[James Guichard <[e-mail]>]

Dear authors,

I have reviewed v-13 of draft-ietf-mpls-inband-pm-encapsulation and have the following comments (I have included line numbers from nits to help identify where in the document the comment applies):


  == Outdated reference: A later version (-01) exists of

     draft-ietf-ippm-alt-mark-deployment-00



  == Outdated reference: A later version (-09) exists of

     draft-ietf-mpls-mna-fwk-08



87      it is referred to as the Alternate-Marking Method.  [RFC8372]

88      describes the desired capabilities for the MPLS flow identification

89      for performance monitoring of MPLS flows.



Jim> RFC8372 discusses aspects to consider when developing a solution for MPLS flow identification. I would not say that it describes “desired capabilities” so perhaps reword the last sentence to more accurately reflect the intent of RFC8372.



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.



Jim> the above paragraph is very strange, at least to me. The text is putting the cart before the horse - while MNA is being worked by the MPLS WG there is no guarantee on timeline or outcome so to suggest that it will obsolete this document is at best premature. I would suggest that the WG consider removing this paragraph and if in the future MNA obsoletes it then mark it as historic at that point in time.



194     The Traffic Class (TC) and Time To Live (TTL) [RFC3032] for the XL

195     and FLI SHOULD use the same field values as the label immediately

196     preceding the XL.  Otherwise, the TC and TTL for the XL and FLI MAY

197     be of different values if it is known that the XL will not be exposed

198     as the top label at any point along the LSP.  The Bottom of the Stack

199     (BoS) bit [RFC3032] for the XL and FLI MUST be zero.



Jim> I would suggest a stronger use of requirements language above. Please consider the following:



      NEW: 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. In this case the TC and

          TTL for the XL and FLI MAY be of different values.



203     domain.  The Flow-ID values MAY be allocated by an external NMS or



Jim> s/Flow-ID values/Flow-ID Label values



209     The FL can be placed either at the bottom or in the middle of the

210     MPLS label stack, and it MAY appear multiple times within a label

211     stack.  Section 2.1 of this document provides several examples to



Jim> The FL must be preceded by the Extension Label and Flow-ID Label indicator but this is not clear in the text. Please clarify this in the text. Furthermore, I assume that it cannot be placed at the top of the stack but the text does not specify this (?).



212     illustrate the application of FL in a label stack.  The TTL for the

213     FL MUST be zero to ensure that it is not used inadvertently for

214     forwarding.  The BoS bit for the FL depends on whether the FL is

215     placed at the bottom of the MPLS label stack.



Jim> I think you mean that the setting of the BoS bit for the FL depends on whether it is at the bottom of the stack. The BoS bit will always be present in the label entry but may or may not be set. Please clarify this in the text.



223     *  L(oss) bit is used for coloring the MPLS packets for loss

224         measurement.



Jim> You should explicitly state that setting the bit means color for loss measurement.



226     *  D(elay) bit is used for coloring the MPLS packets for delay/jitter

227         measurement.



Jim> You should explicitly state that setting the bit means color for delay measurement.



264     Note that here if the penultimate hop popping (PHP) is in use, the

265     PHP LSR that recognizes the cSPL MAY choose not to pop the cSPL and

266     the following Flow-ID label, otherwise the egress LSR would be

267     excluded from the performance measurement.



Jim> I do not think the above paragraph is precise enough. The PHP may or may not POP the cSPL and Flow-ID label. How is this determined? What is the consequence of each choice? You allude to it in the last part of the paragraph but you do not expand on how or why the PHP LSR makes that decision. This needs further specification.



338     Note that for this example, the two Flow-ID values appearing in a

339     label stack MUST be different.  In other words, the Flow-ID label

340     applied to the MPLS transport and the Flow-ID label applied to the

341     MPLS service share the same value space.  Also, note that the two



Jim> share the same value space? You just said that they MUST be different. What do you mean by the same value space or should this read “different” label space?



370     *  The processing node may also pop the XL, FLI and FL from the MPLS



Jim> may? or MAY? what is the decision process on whether to POP or not?



371         label stack.  The egress node pops the whole MPLS label stack, and



Jim> shouldn’t this be “The egress node MUST pop …”


Thanks!

Jim