[Last-Call] Re: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniele,


Thanks for your review and thoughtful comments.

Please see inline.

Original
From: DanieleCeccarelliviaDatatracker <noreply@xxxxxxxx>
To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;
Cc: draft-ietf-mpls-inband-pm-encapsulation.all@xxxxxxxx <draft-ietf-mpls-inband-pm-encapsulation.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;mpls@xxxxxxxx <mpls@xxxxxxxx>;
Date: 2024年08月23日 20:34
Subject: Opsdir last call review of draft-ietf-mpls-inband-pm-encapsulation-14
Reviewer: Daniele Ceccarelli
Review result: Has Issues

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?

[XM]>>> At the request of the MPLS WG chairs, the text you quoted was added to version -11 of this document. After that, this document passed WGLC and there was unanimous consensus to publish it as an RFC. Considering there are existing interoperable implementations of this document, while the MNA solution of performance measurement with alternate marking method is still at the early stage without WG draft and known implementation, it's worth publishing this document.


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

[XM]>>> That's defined in this document first. Propose to change the text as below.

OLD

Flow-based MPLS performance measurement encapsulation with alternate marking method has the following format:

NEW

This document defines the Flow-based MPLS performance measurement encapsulation with alternate marking method, 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?

[XM]>>> Yes, this can always be the case. Will use the text you suggested and delete the "unless...".


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

[XM]>>> No, Figure 2 provides an example the FL is not placed at the bottom of the MPLS label stack.


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

[XM]>>> This is possible and it's already been implemented. Propose to add below new text to the end of the TC definition.

NEW

Considering the FL is not used as a forwarding label, the repurposing of the TC for the FL is feasible and viable.


- Examples section highly appreciated 

- Section 4,5 and 6 clear

[XM]>>> Thank you.


Cheers,

Xiao Min

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux