[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 <xiao.min2@zte.com.cn> wrote:

> Hi Rakesh,
>
>
> Thank you for the response.
>
> Please see inline with [XM-2]>>>.
> Original
> *From: *RakeshGandhi(rgandhi) <rgandhi@cisco.com>
> *To: *肖敏10093570;rgandhi.ietf@gmail.com <rgandhi.ietf@gmail.com>;
> *Cc: *mpls@ietf.org <mpls@ietf.org>;
> *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: *xiao.min2@zte.com.cn <xiao.min2@zte.com.cn>
> *Date: *Tuesday, May 14, 2024 at 11:08 PM
> *To: *rgandhi.ietf@gmail.com <rgandhi.ietf@gmail.com>
> *Cc: *mpls@ietf.org <mpls@ietf.org>
> *Subject: *[mpls] Re: WG last call: draft-ietf-mpls-rfc6374-sr
>
> Hi Rakesh,
>
>
> Thank you for the reply.
>
> Please see inline.
>
> Original
>
> *From: *RakeshGandhi <rgandhi.ietf@gmail.com>
>
> *To: *肖敏10093570;
>
> *Cc: *tony.li@tony.li <tony.li@tony.li>;mpls@ietf.org <mpls@ietf.org>;
>
> *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 <xiao.min2@zte.com.cn> 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.

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

<RG3> Ack.

>
> * 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.
>
>
> <RG3> Yes, alternate marking gives precise loss measurement.

> * 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.
>

<RG3> Great, thanks!

>
> 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.
>
>
>
<RG3> Ok, thanks!

Regards,
Rakesh

> 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 <tony.li@tony.li>
>
> *To: *mpls <mpls@ietf.org>;
>
> *Date: *2024年04月30日 23:52
>
> *Subject: [mpls] WG last call: draft-ietf-mpls-rfc6374-sr*
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> 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 -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org
>
>
>
>
>