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

[Rakesh Gandhi <[e-mail]>]

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