Re: [mpls] MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr

Hi Greg,

    In the contexts of the draft-gandhi-mpls-rfc6374-sr and my comments, one way means one way  Measurement Mode, out-of-band means out-of-band probe reply.

Best Regards,
Huaimo
________________________________
From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, June 12, 2020 10:06 PM
To: Huaimo Chen <huaimo.chen@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>; mpls@ietf.org <mpls@ietf.org>; mpls-chairs@ietf.org <mpls-chairs@ietf.org>; draft-gandhi-mpls-rfc6374-sr@ietf.org <draft-gandhi-mpls-rfc6374-sr@ietf.org>
Subject: Re: [mpls] MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr

Hi Huaimo,
thank you for your comments. Though I am not a co-author of the draft, I am very interested in the topic. I have a question related to your comments and conclusions below:

  *   you've noted "It seems that the Performance Measurement for a SR P2MP Path (or policy) is limited to one way and out-of-band. Should the document add some texts talking about these limitations?" If that truly is the case, i.e., the proposed OAM mechanism can only work as out-of-band, what is the value of the measurement results using the synthetic method of measurement? If, as you have noted, a test packet does not follow the monitored data flow, how trustworthy and useful the loss and delay measurement are achieved? I think that I cannot agree with your conclusion that the prosed PM OAM mechanism can only work as out-of-band tool, i.e., support direct measurement statistics by collecting counters. The fact that a test packet, as described in the draft, uses the precisely same policies as a data packet, in my view, ensures that it is in-band and shares the fate with the data flow, which is essential to obtaining useful performance measurements.

I much appreciate your consideration of my question.

Regards,
Greg

On Mon, Jun 8, 2020 at 8:52 PM Huaimo Chen <huaimo.chen@futurewei.com<mailto:huaimo.chen@futurewei.com>> wrote:
Hi All,

    I have reviewed the document and have the following comments.

    1.  The document is useful and technically sound. It can be considered for WG adoption.

    2.  The document seems talking about the Loss Measurement Message and Delay Measurement Message. Should it have some texts for Combined Loss/Delay Measurement Message?

    3.  There are a couple of IETF drafts about SR P2MP Path.. The document just mentions one of them and the Performance Measurement for a SR P2MP Path (or policy) is based on this one draft. Should the Performance Measurement for a SR P2MP Path (or policy) be general enough for all?

    4.  It seems that the Performance Measurement for a SR P2MP Path (or policy) is limited to one way and out-of-band. Should the document add some texts talking about these limitations?

    5.  The registry for the newly defined Return Path TLV Type and Block Number TLV Type is missing in the document. Is it the "MPLS Loss/Delay Measurement TLV Object" registry?

    6.  It seems that a new registry should be defined for the Sub-TLV types under the Return Path TLV in the document.

    7.  In section 5.1. and section 6.1., Should "For both SR Links and end-to-end measurement for SR-MPLS Policies" be changed to something like "For both SR Links and end-to-end SR-MPLS Policies measurements"?

    8.  In section 6.2., should something like a user case be added into the sentence "The Block Number TLV is Mandatory when used.."?

Best Regards,
Huaimo
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cb44dac159869454cf79b08d80f3e65b6%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637276107983736087&sdata=lI8R1QJaZiZnvrz3n%2BuLee7acwKtXvXRLF3BQf80EO8%3D&reserved=0>