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

From: Huaimo Chen <[email-masked]>
Date: Tue, 9 Jun 2020 03:52:20 +0000

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 10 Jun 2020 09:03:19 -0400

Thank you Huaimo for the detailed review and your support for the adoption.
Attached please find the updated document and diffs that address your
comments.
Please see responses inline with <RG>..

>     1.  The document is useful and technically sound. It can be considered

<RG> Thank you.

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

<RG> Added section 6.3.

>
>     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?
>
> <RG> do you have a specific P2MP draft on mind that should also be
included in the example?

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

<RG> Updated section 7.

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

<RG> Updated IANA section.

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

<RG> Added in IANA section.

>     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"?
>

<RG> Corrected.

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

<RG> Expanded the sentence.

Thanks,
Rakesh

>
> Best Regards,
> Huaimo
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Jun 2020 19:06:20 -0700

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

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 13 Jun 2020 03:59:08 +0000

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 <[email-masked]>
Sent: Friday, June 12, 2020 10:06 PM
To: Huaimo Chen <[email-masked]>
Cc: Tarek Saad <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
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.

Regards,
Greg

On Mon, Jun 8, 2020 at 8:52 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

    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?

    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
[email-masked]<mailto:[email-masked]>
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>

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 13 Jun 2020 04:12:51 +0000

Hi Rakesh,

    Another SR P2MP draft is draft-shen-spring-p2mp-transport-chain.

Best Regards,
Huaimo
________________________________
From: Rakesh Gandhi <[email-masked]>
Sent: Wednesday, June 10, 2020 9:03 AM
To: Huaimo Chen <[email-masked]>
Cc: Tarek Saad <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [mpls] MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr

Thank you Huaimo for the detailed review and your support for the adoption.
Attached please find the updated document and diffs that address your comments.
Please see responses inline with <RG>..

On Mon, Jun 8, 2020 at 11:52 PM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

<RG> Thank you.

<RG> Added section 6.3.

<RG> do you have a specific P2MP draft on mind that should also be included in the example?

<RG> Updated section 7.

<RG> Corrected.

Thanks,
Rakesh

Best Regards,
Huaimo
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
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%7Cc31debd982dd4f82aba208d80d3eae44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637273910199487505&sdata=v46CNS9WsmAblNY5nj%2F7yd%2BdWh6sROXzJbDPtXcrTsc%3D&reserved=0>

---

From: Rakesh Gandhi <[email-masked]>
Date: Sat, 13 Jun 2020 10:07:16 -0400

Thanks Huaimo for the pointer.
We will refer to this draft as well.

Thanks,
Rakesh

On Sat, Jun 13, 2020 at 12:12 AM Huaimo Chen <[email-masked]>
wrote:

> ------------------------------
> *From:* Rakesh Gandhi <[email-masked]>
> *Sent:* Wednesday, June 10, 2020 9:03 AM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* Tarek Saad <[email-masked]>; [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>;
> [email-masked] <
> [email-masked]>
> *Subject:* Re: [mpls] MPLS-RT experts review for
> draft-gandhi-mpls-rfc6374-sr
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cc31debd982dd4f82aba208d80d3eae44%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637273910199487505&sdata=v46CNS9WsmAblNY5nj%2F7yd%2BdWh6sROXzJbDPtXcrTsc%3D&reserved=0>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 13 Jun 2020 08:38:11 -0700

Hi Huiamo,
thank you for your expedient and helpful response to my question. I agree
with your characterization of the proposed method for p2mp SR policies. Do
you see such a solution as sufficient and capable to support the necessary
performance monitoring?

Regards,
Greg

On Fri, Jun 12, 2020 at 8:59 PM Huaimo Chen <[email-masked]>
wrote:

> 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 <[email-masked]>
> *Sent:* Friday, June 12, 2020 10:06 PM
> 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.
>
> <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>
>
>

---

From: Yimin Shen <[email-masked]>
Date: Mon, 15 Jun 2020 00:03:51 +0000

Hi WG,

I was assigned as a reviewer for draft-gandhi-mpls-rfc6374-sr. I have now completed my review.

The document addresses packet loss and delay measurement for SR-MPLS, by building it on top of the mechanism specified by RFC 6374. This is a useful feature. The document is coherent and technically sound. I think it is ready for WG adoption.

In the meanwhile, I do have a few questions and comments, and hope they could be addressed by the authors.

[1] The document uses terms “SR link(s)” and “SR-MPLS link(s)” interchangeably. I’d like to suggest to change “SR link(s)” to “SR-MPLS link(s)”, for consistency and also as “SR links” include SRv6 links which are out of the scope.

[2] The term “SR-MPLS links” needs further clarification. Does it mean MPLS links (in an SR-MPLS environment), or there is something more specific ? Either case, please clarify whether the procedures for “SR-MPLS links” in this document are actually the same as those for MPLS links in RFC 6374, or high light the changes explicitly.

[3]  In sections 4.4 and 6.2, respectively:

   The Return Path TLV is Mandatory when used.  If responder does not

   support this TLV, it MUST return Error 0x17: Unsupported Mandatory

   TLV Object.

   The Block Number TLV is Mandatory when used.  If responder does not
   support this TLV, it MUST return Error 0x17: Unsupported Mandatory
   TLV Object.

Is it mandatory that both the sender and the responder must support this document ? Is it possible for a sender (supporting the document) to inter-op with a responder supporting only RFC 6374, i.e. a mixed mode ? If the mixed mode is allowed, it would deserve some text (or a section) to explain and clarify the procedures and applicabily.

Thanks,

-- Yimin Shen
Juniper Networks

From: Tarek Saad <[email-masked]>
Date: Wednesday, May 6, 2020 at 10:46 AM
To: Yimin Shen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr

[External Email. Be cautious of content]

Yimin, Xufeng, and Huaimo,

You have be selected as MPLS-RT reviewers for draft-gandhi-mpls-rfc6374-sr.

Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.

If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.

Are you able to review this draft by May 20, 2020? Please respond in a timely fashion if you cannot make it.

Regards,
Tarek
(as MPLS WG chair)

Juniper Business Use Only

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 15 Jun 2020 13:41:04 -0400

Thanks Yimin for the review and your comments.

Please see comments inline with <RG>..

On Sun, Jun 14, 2020 at 8:04 PM Yimin Shen <yshen=
[email-masked]> wrote:

> The document addresses packet loss and delay measurement for SR-MPLS, by
> building it on top of the mechanism specified by RFC 6374. This is a useful
> feature. The document is coherent and technically sound. I think it is
> ready for WG adoption.
>

<RG> Many thanks.

> [1] The document uses terms “SR link(s)” and “SR-MPLS link(s)”
> interchangeably. I’d like to suggest to change “SR link(s)” to “SR-MPLS
> link(s)”, for consistency and also as “SR links” include SRv6 links which
> are out of the scope.
>

<RG> Ok, updated the text in the document.

>
>
> [2] The term “SR-MPLS links” needs further clarification. Does it mean
> MPLS links (in an SR-MPLS environment), or there is something more specific
> ? Either case, please clarify whether the procedures for “SR-MPLS links” in
> this document are actually the same as those for MPLS links in RFC 6374, or
> high light the changes explicitly.
>

<RG> It is MPLS links, in an SR-MPLS environment. Updated the text in the
document.

> Is it mandatory that both the sender and the responder must support this
> document ?
>

<RG> These TLVs have Types allocated from the Mandatory Type range for RFC
6374. The support for them is optional.

> Is it possible for a sender (supporting the document) to inter-op with a
> responder supporting only RFC 6374, i.e. a mixed mode ? If the mixed mode
> is allowed, it would deserve some text (or a section) to explain and
> clarify the procedures and applicabily.
>

<RG> Added a new section 10 for Compatibility in the document.

Thanks,
Rakesh

>
> Thanks,
>
>
>
> -- Yimin Shen
>
> Juniper Networks
>
>
>
>
>
> *From: *Tarek Saad <[email-masked]>
> *Date: *Wednesday, May 6, 2020 at 10:46 AM
> *To: *Yimin Shen <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> *Subject: *MPLS-RT experts review for draft-gandhi-mpls-rfc6374-sr
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
>
>
>
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is
> the document technically sound?  We are interested in knowing whether the
> document is ready to be considered for WG adoption (ie, it doesn't have to
> be perfect at this point, but should be a good start).
>
>
>
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, comments may
> be sent privately to only the WG chairs.
>
>
>
> If you have technical comments you should try to be explicit about what
> *really* need to be resolved before adopting it as a working group
> document, and what can wait until the document is a working group document
> and the working group has the revision control.
>
>
>

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 17 Jun 2020 13:10:27 -0400

Hi Authors and WG,

I have reviewed the document draft-gandhi-mpls-rfc6374-sr and have the
following comments.

1. Using the existing mechanism defined by RFC 6374 for SR PM is natural,
logical, and worth proceeding.

2. The 2nd paragraph in Sec 2.3 describes the case P2MP, but the context is
the reference topology depicted as Figure 2, which does not clearly cover
the P2MP case. Some additional clarification or a different topology may
illustrate better.

3. In the last paragraph in Sec 4.2 describes the use of Destination
Address TLV. Does the statement “can be sent in the probe query message”
mean that this is optional? (Is this MAY or MUST?) An implementer would
like to know the clear requirement.

4. Sec 4.3.3. describes the loopback measure mode, which requires the
responder to collect timestamps t1 and t4. Such a behavior does not seem to
follow RFC 6374. Based on Sec 3.5.3. of RFC 6374, “no support for delay
measurement is required at the responder at all, other than the ability to
recognize a DM query that includes this object and return it unmodified.”

5. The last sentence of Sec 4.3.3. excludes the loopback mode for SR-MPLS
Links. Is there any reason for the exclusion?

6. Most of the document describes the procedures to use RFC 6374. The only
additions to RFC 6374 are Sec. 4.4. and Sec. 6.2., but these two sections
are embedded in the other sections on procedures and use cases. For an
implementer, I’d hope to see these two sections separated from others so
that it would be clear what are needed to implement on top of the protocol
defined in RFC 6374.

Thanks,

- Xufeng

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 18 Jun 2020 08:48:04 -0400

Thank you Xufeng for the review.
Please see replies inline with <RG>...

<RG> Many thanks.

>
> 2. The 2nd paragraph in Sec 2.3 describes the case P2MP, but the context
> is the reference topology depicted as Figure 2, which does not clearly
> cover the P2MP case. Some additional clarification or a different topology
> may illustrate better.
>

<RG> Moved the text to the relevant section 7 along with other P2MP texts
to avoid confusion.

> like to know the clear requirement.

<RG> Added  "MAY".

>
> 4.. Sec 4.3.3. describes the loopback measure mode, which requires the

<RG> The responder does not add t1 and t4 (as per Reference Topology). The
responder simply forwards the probe packet.

>
> 5.. The last sentence of Sec 4.3.3. excludes the loopback mode for
> SR-MPLS Links. Is there any reason for the exclusion?
>
>
>
<RG> Removed.

> that it would be clear what are needed to implement on top of the protocol

<RG> Keeping them at the current place provides context and continuity for
reading. It is highlighted in Abstract and Introduction that these two TLVs
are new.
I am afraid, moving them elsewhere may lose the context. Please advise if
you have a preference.

Thanks,
Rakesh

---

From: Xufeng Liu <[email-masked]>
Date: Sat, 27 Jun 2020 12:36:31 -0400

Thanks to Rakesh for having addressed my comments.
Best regards,
- Xufeng