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

[Rakesh Gandhi <[e-mail]>]

Thanks Xiao Min for the review.

Updated the text in the draft to clarify this.

HTML:     https://www.ietf.org/archive/id/draft-ietf-mpls-rfc6374-sr-10.html
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-rfc6374-sr-10

Also fixed several references in the draft related to this.

Thanks,
Rakesh



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

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