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

[[e-mail]]

Hi Rakesh,

Thank you for the new text.
Just one comment, it seems to me this mechanism works without requiring the data packets to carry block number, is my understanding correct? If yes, please tweak the text to indicate that.
Cheers,
Xiao Min


Original


From: RakeshGandhi <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年05月24日 09:59
Subject: Re: [mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr




Thank you Xiao Min for providing great inputs and helping to improve the work.

Does the following new text capture the summary of the discussions? I am also attaching the updated draft for review.

thanks,
Rakesh (for authors)


6.4.  Block Number for Counters

   The packet loss measurement using Alternate-Marking Method (AMM)
   defined in [RFC9341] MAY use Block Number (BN) for data correlation
   for the traffic flow under measurement.  The block number is used to
   divide the traffic flow into consecutive blocks and counting the
   number of packets transmitted and received in each block for loss
   measurement as defined in Section 3.1 of [RFC9341].

   As described in Section 4.3 of [RFC9341], protocol-based distributed
   solution to exchange values of counters on the nodes can be used for
   loss measurement as specified in this document using the messages
   defined in [RFC6374].

   The querier node assigns block number to the block of data packets of
   the traffic flow under measurement.  The querier counts the number of
   packets transmitted in each block.  The mechanism for assignment of
   block number and alternating its value is a local decision on the
   querier and it is outside the scope of this document.

   The querier can use the procedure defined in
   [I-D.ietf-mpls-inband-pm-encapsulation], for example, for marking the
   data packets of the traffic flow under measurement.

   The responder counts the number of received packets in each block
   using the block number in the received data packets.  The querier and
   responder maintain separate sets of transmit and receive counters,
   one set for each block.

   The LM query and response messages defined in [RFC6374] are used to
   measure the packet loss for the block of data packets transmitted
   with the previous block number while data packets carry alternate
   block number.  Specifically, LM query and response messages carry the
   transmit and receive counters (which is not actively changing for the
   block number under measurement) along with the block number of the
   counters to correlate for loss measurement.

   "The assumption of the block number mechanism is that the measurement
   nodes are time synchronized" as specified in Section 4.3 of [RFC9341]
   is not employed by the procedure described in this document for
   accurate loss measurement.







On Thu, May 23, 2024 at 9:27 PM <[e-mail]> wrote:


Hi Rakesh,

Thank you for the productive discussion.
I agree we have converged.
Looking forward to the updated draft. :-)

Cheers,
Xiao Min


Original

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




Thanks Xiao Min for your comments. Looks like we have converged on the issues. I will update the draft accordingly.
Please see inline with <RG5>....



On Thu, May 23, 2024 at 3:34 AM <[e-mail]> wrote:


Hi Rakesh,

Thank you for the prompt response.
Please see inline with [XM-4]>>>.

Original

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



Hi Xiao Min,

Thank you for your replies. please see inline with <RG4>.





On Wed, May 22, 2024 at 5:14 AM <[e-mail]> wrote:


Hi Rakesh,
Thank you for the replies.
Snipping to the unresolved comments, please see inline with [XM-3]>>>.

Original

From: RakeshGandhi <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年05月22日 10:09
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 <RG3>....





On Fri, May 17, 2024 at 2:24 AM <[e-mail]> wrote:


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.
















<RG3> The responder derives the block number of the RX counter from the data traffic, e.g. data traffic using the method in draft-ietf-mpls-inband-pm-encapsulation. 
<RG3> For example, when using 1 bit for loss marking defined in draft-ietf-mpls-inband-pm-encapsulation, querier and responder would have two sets of TX and RX counters, one set for marking 0 and one set for marking 1.
<RG3> Querier can change the marking based on local policy (out of scope of the document). 
<RG3> LM query would carry the counters for marking 1 (which is not changing) while data traffic is using marking 0 and vice versa.
[XM-3]>>> In order to understand your solution described above, I have some questions as below.
* Do you mean that the LM query carries the TX counter of the block immediately before the block LM query falls into?









<RG4> Querier would collect the TX and RX counters in the LM query message which is not changing at the time of the collection for accurate loss measurement, so yes.
 




* Is there an assumption that the LM query interval is the same as the data traffic coloring period?








<RG4> Yes. 

 



* Is there still requirement for time synchronization between the LM querier and the LM responder?









<RG4> For the LM query and response messages in RFC 6374, the loss measurement works without querier and responder in clock sync.

[XM-4]>>> Many thanks for the clear answers. Based on your answers and explanations, I'm sure the Block Number in your solution is far different from what I thought it be. The Block Number in your solution is a relative value, while the Block Number that I thought and described in section 4.3 of RFC 9341 is an absolute value, that's why RFC 9341 section 4.3 says "The assumption of this BN mechanism is that the measurement nodes are time synchronized". With that said, I suggest you to add more solution details to the draft in question, otherwise I'm afraid the LM querier and the LM responder can't interwork due to different understandings on Block Number.









<RG5> Thanks for pointing to the text in RFC 9341. 
<RG5> I believe responders deriving the block number from the local clock may not yield accurate loss measurement due to (1) The clocks sync have errors (e.g. Class-B can be off by 70 nsec) and (2) packets on wire may belong to a different block.
<RG5> Deriving the block number for the RX counter from the block number in data packets itself will provide accurate loss measurement.
<RG5> We can add text in the draft to indicate this.

Thanks,
Rakesh







Cheers,
Xiao Min

Thanks,
Rakesh


 




 
Cheers,
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]