[mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr

[[e-mail]]

Hi Rakesh,
Thank you for the response.
Please see inline with [XM-2]>>>.

Original


From: RakeshGandhi(rgandhi) <[e-mail]>
To: 肖敏10093570;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;
Date: 2024年05月16日 21:20
Subject: Re: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr



Hi Xiao Min,
 
Thank you for your comments. Please see replies inline with <RG2>…
 


From: [e-mail] <[e-mail]>
 Date: Tuesday, May 14, 2024 at 11:08 PM
 To: [e-mail] <[e-mail]>
 Cc: [e-mail] <[e-mail]>
 Subject: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr


Hi Rakesh,

 Thank you for the reply.
Please see inline.

Original

From: RakeshGandhi <[e-mail]>



To: 肖敏10093570;



Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;



Date: 2024年05月15日 06:07



Subject: Re: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr




Hi Xiao Min,


 

Thank you for the review comments.


 

Please see replies inline with <RG>...



 

On Tue, May 7, 2024 at 4:24 AM <[e-mail]> wrote:


Hi all,
 
I've read the latest version of the draft, which introduces two new TLVs - Return Path TLV and Block Number TLV.
With regard to the Return Path TLV, its usage is clear to me, RFC 9503 defines a similar STAMP TLV extension.
However, to the Block Number TLV, its usage is not clear to me. The first paragraph of section 7.2 seems to combine this TLV with Alternate-Marking Method defined in RFC 9341, though I can't figure out how they're combined.



 

<RG> RFC 9341, Section 3.1, first paragraph defines packet loss measurement using block number (copied text below). 


   "The basic idea is to virtually split traffic flows into consecutive    blocks: each block represents a measurable entity unambiguously    recognizable by all network devices along the path.  By counting the    number of packets in each block and comparing the values measured by    different network devices along the path, it is possible to measure    if packet loss occurred in any single block between any two points." 
<RG> This draft defines Block number TLV to carry the above block number associated with the traffic counters.
   "The packet loss measurement using Alternate-Marking Method defined in    [RFC9341] MAY use Block Number (BN) for data correlation for the data    traffic flow under measurement.  To be able to correlate the transmit    and receive traffic counters of the matching Block Number, the Block    Number of the traffic counters is carried in the LM query and    response messages." [XM]>>> As far as I know, the existing implementations of Alternate-Marking Method rely on the external NMS/controller, which is responsible for the correlation of data (e.g., counter of the same block of packets) collected from each node along the path. As specified in section 4.3 of RFC 9341, a protocol-based distributed solution is also possible, and I believe that's the case for this document. Then, I still have several comments as below.
<RG2> Yes, this is protocol-based distributed solution as defined in RFC9341.
* This draft is not clear on how the LM query sending node decides the Block Number. In one existing implementation I know, the node calculates the Block Number as the modulo of the node's absolute time since PTP epoch and the marking period. Also note that in the data planes of Alternate-Marking Method, whether RFC 9343 or draft-ietf-mpls-inband-pm-encapsulation, there is no any kind of Block Number field.
<RG2> It is up to the implementation on how to assign and increment block number to the block of packets. The procedure for block number-based loss is defined in RFC9343, section 3.1. As described in RFC 9343, implementation details of the block number are out of scope. Do you mean the draft-ietf-mpls-rfc6374-sr should indicate this?
[XM-2]>>> The draft-ietf-mpls-rfc6374-sr should specify how to calculate the block number, because the two endpoints exchanging LM messages must use the same method to calculate the block number. Take it for example, if the LM 
query sending node calculates the Block Number as the modulo of the node's absolute time since *PTP epoch* and the marking period, while the LM response sending node calculates the Block Number as the modulo of the node's absolute time since *NTP epoch* and the marking period, then the mechanism specified in this draft doesn't work.



<RG2> The draft-ietf-mpls-inband-pm-encapsulation defines how to color the traffic to provide a solution for RFC 9341, section 4.1, as described in the last paragraph. Do you mean the draft-ietf-mpls-rfc6374-sr should refer to the draft-ietf-mpls-inband-pm-encapsulation to state how to color the data traffic for loss measurement?
[XM-2]>>> Yes, I believe draft-ietf-mpls-inband-pm-encapsulation is a helpful reference to the reader.


* This draft is not clear on the benefit of using Alternate-Marking Method vs Direct Loss Measurement Method of RFC 6374. Please note that for two-way loss measurement the Alternate-Marking Method requires time synchronization between the two endpoints, while Direct LM Method defined in RFC 6374 doesn't require that. 
<RG2> Alternate marking is used for direct (i.e. loss) measurement as defined in Section 3.1 of RFC 9343. The probe messages defined in RFC 6374 are simply used to collect the counters and extensions in this draft to collect the block number associated with the counters.
<RG2> As RFC9343 already defines the method including time-synchronization, there was no need to add it in this draft. Do you see any text to be added in the draft?
[XM-2]>>> Direct Loss Measurement in RFC 6374 works well without Alternate Marking. By introducing Alternate Marking, the costs include coloring the data traffic and time synchronization between the two endpoints, then what's the benefits is still not clear, is the LM result more accurate or something else? I believe some text regarding the identified costs and benefits should be added. 


* This draft may need to mention that it provides a protocol-based distributed solution of Alternate-Marking Method, not a conflict with a centralized solution using the NMS/controller.
<RG2> Agree.
* This draft introduces the Block Number TLV that's not included in RFC 9503, then it seems we need to write a new draft defining a similar STAMP TLV extension.
<RG2> Happy to collaborate with you on similar extensions for STAMP.
[XM-2]>>> Happy to collaborate with you too.


An alternative way is to take out the Block Number TLV from this draft and think more about it, and after that the proposal may be brought up in IPPM first.
<RG2> Well, RFC6374 is MPLS -based active measurement protocol that is developed by MPLS WG. RFC 6374 can be used with alternate marking for loss measurement, hence this draft.
<RG2> STAMP (RFC 8762) is IP-based active measurement protocol developed by IPPM WG. Sure, we can think about how to do this for STAMP protocol in IPPM WG.
[XM-2]>>> That's fine to me if you prefer not to take this way.


Cheers,
Xiao Min


Thanks,
Rakesh
 
 
<RG> How about updating the text as follows?    "The packet loss measurement using Alternate-Marking Method defined in    [RFC9341] is based on dividing the traffic flow into consecutive blocks and
   counting the number of packets in each block. A block number is used to    identify the transmit and receive counters in each block and compare for measuring loss.    The LM query and response messages carry the transmit and receive counters along with the     block number when using the AMM defined in [RFC9341] for loss measurement."

[XM]>>> Thank you for the proposed text change. Please see my further comments above.

Cheers,
Xiao Min Thanks, Rakesh 
 

 
Best Regards,
Xiao Min

Original

From: TonyLi <[e-mail]>



To: mpls <[e-mail]>;



Date: 2024年04月30日 23:52



Subject: [mpls] WG last call: draft-ietf-mpls-rfc6374-sr




_______________________________________________
 mpls mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/mpls
 

[WG chair hat: on]


 

Hi all,


 

This starts a 2 week working group last call on draft-ietf-mpls-rfc6374-sr.



 
 

This last call ends at 12:01PM PDT, Tues. May 14th.



 
 

Please send all comments to the mailing list.



 
 

Thanks,



Tony



 
 





 


_______________________________________________
 mpls mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]