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

[[e-mail]]

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.

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]