Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Thanks you Greg for detailed review comments.
Sorry for the delay in replying.
We can further discuss off-line this week in Yokohama if needed.

Please see replies in line with <RG>…

From: Greg Mirsky <[e-mail]>
Date: Thursday, February 2, 2023 at 9:13 AM
To: Rakesh Gandhi (rgandhi) <[e-mail]>
Cc: Tommy Pauly <tpauly=[e-mail]>, IETF IPPM WG <[e-mail]>, Henrik Nydell <[e-mail]>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
Hi Rakesh,
thank you for posting the new version, it helps to track our discussion. I have several notes on the updates and their possible impact on the existing STAMP RFCs:

  *   The example in the last paragraph in Section 3.2 brings some concerns:

     *   you use the Direct Measurement TLV from RFC 8792 as an example of using the new V flag. Is it your intention to use this draft uprating RFC 8792? If that is the case, please mark the draft accordingly.
     *   Furthermore, I cannot understand the relationship you are referring to in the example. The Stateless mode of a STAMP's Session-Reflector is not expected to affect counters that a system maintains outside the STAMP implementation. Thus, I'm not at all convinced that a Session-Reflector in the Stateless mode will benefit from the proposed V flag.

<RG> Ok, authors agree to move the behavior of the V-flag for TLVs in RFC 8972 to a separate draft in future and limit the V flag applicability to the TLVs in this draft only to contain the scope of this draft.

  *   Based on the abovementioned reasons, the only application of the new flag introduced in the draft is to verify the consistency of the control plane and the data plane from the Session-Reflector's PoV. That is clearly outside the scope of STAMP as defined in RFC 8762. At the same time, verifying consistency between the control plane and the data plane is part of the functionality of, for example, RFC 7110 Return Path Specified LSP Ping<https://datatracker.ietf.org/doc/rfc7110/>. For an SR-MPLS environment, an operator can use the non-FEC TLV encoding of MPLS Link Switched Elements defined in draft-ietf-spring-bfd<https://datatracker.ietf.org/doc/draft-ietf-spring-bfd/>. Thus, I conclude that there's no technical need for the Verification flag, and for two-way performance measurements, STAMP can be used in combination with the existing Fault Management OAM tools.
<RG> The V flag is for verifying the fields in the “STAMP packets” and replying to the Sender accordingly as described in the draft. We can sync-up off-line in Yokohama if needed.

  *   Regarding the choice of the destination IP address in an ECMP environment. If it is in an IP/MPLS network, then the MPLS WG recommends using the Entropy Special Purpose Label as the indicator that the next MPLS LSE includes the value (Entropy Label) that can be used to load-balance flows. Also, the example only suggests that load balancing be achieved using the IPv4 address family. What can be recommended for an IPv6 case? I imagine that in the IPv6 case, load balancing can be achieved using the Flow Label in the IPv6 header. If you agree, and the scope of the draft is a Source Routing domain, I propose to simplify the specification and use a single IPv4 loopback address, e.g., 127.0.0.1.
<RG> We have updated the section 4 in the published draft to further clarify the usage.

  *   What is the expected behavior of a Session-Reflector received Reply Requested on the Same Link request? It is not clear as the document lists several options - "physical interface, virtual link, or Link Aggregation Group (LAG) [IEEE802.1AX], or LAG member". How does the Session-Reflector that received that instruction choose between, for example, LAG and a LAG member?
<RG> Ok, we have added following text to cover LAG member:
When using LAG member links, STAMP extension for Micro-Session ID TLV defined in [I-D.ietf-ippm-stamp-on-lag] can be used to identify the link.

  *   The last paragraph in Section 5.1.2 mentions that the Return Segment List sub-TLV can communicate a p2mp segment list. If that is the case, the Session-Reflector will effectively transmit the reflected STAMP packet to multiple receivers. What is the purpose of that behavior? What are the requirements for the systems that terminate that p2mp SR tunnel? Using a p2mp SR list appears as a dangerous attack vector.
<RG> Ok, we have removed the P2MP text to contain the scope of this draft.

Thanks,
Rakesh

I'm looking forward to continuing our talk. I hope that other experts in the IPPM WG will share their thoughts.

Regards,
Greg


On Tue, Jan 31, 2023 at 5:49 AM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thank you for your further review comments.

Please see replies inline with <RG>..

From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Monday, January 30, 2023 at 7:36 PM
To: Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>>
Cc: Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>>, IETF IPPM WG <[e-mail]<mailto:[e-mail]>>, Henrik Nydell <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
Hi Rakesh,
thank you for sharing the updated version. Please find my notes about the updates and the draft below:

  *   Section 3 now describes some optional behavior handling the U flag. I agree that these options are valid but must point out that other behaviors are possible. For example, a Session-Sender will continue transmitting test packets despite receiving the U flag set in the reflected packet. I imagine an intelligent implementation will merely ignore the TLV with the U flag set and report that, along with the collected and calculated performance metric and/or operational data. It seems logical to expect that an implementation of STAMP that supports RFC 8972 and this draft would set both U and V flags. Thus, as this is an implementation choice, I think introducing the V flag that effectively duplicates part of cases already addressed by the U flag is unnecessary.
<RG> In case of U flag, the unsupported TLV will never work (until node upgraded) whereas in case of V flag, the TLV (as supported) should work, so need to troubleshoot the networking failure😊  Yes, the sessions can still continue to transmit packets in both cases.

  *   The reference to RFC 9256 is helpful, but I couldn't find that the RFC defines the use of a loopback address. As there is no requirement to use the loopback IP address, I don't think the document should make it such.
<RG> It is the Null Endpoint.
“ https://datatracker.ietf.org/doc/rfc9256/
8.8.1.  Color-Only BGP Destination Steering
...

The null endpoint is 0.0.0.0 for IPv4 and :: for IPv6 (all bits set

to the 0 value).”

  *   An example of using an IPv4 loopback address in an ECMP environment is unclear. Wouldn't using a routable IP address be better for an operator?
<RG> Added additional text in Section 4, paragraph 2.

  *   Thank you for adding details describing fields if the Destination Address TLV. Do you think that the Length field description can further benefit from specifying valid values for it? And similar question for the Length field in Section 5.1.2.
<RG> Updated.

  *   Thank you for clarifying interpretations of fields in Section 5.1.1, that helps. Do you think that the Length field might be set to a value that is invalid?
<RG> Updated.

  *   Section 5.1.1 defines the Control Code 0x01 as "Reply Requested on the Same Link". Is that a physical or logical link?
<RG> Updated.
I appreciate the work the authors put in addressing my comments. I hope that the authors will also address Henrik Nydell's comments, particularly, adding considerations for interworking between STAMP and TWAMP Light systems when using the new STAMP TLVs and sub-TLVs.

<RG> Added in Section 6. Thanks Henrik for the review.
FYI: updated drafts can be found at:
URL:            https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-07.txt
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-srpm-07

Thanks,
Rakesh


Looking forward to our continued discussion.

Regards,
Greg



On Wed, Jan 25, 2023 at 10:31 AM Rakesh Gandhi (rgandhi) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Greg for reviewing the document and providing the comments.

Attaching the updated draft and the diff file.

Please see replies inline with <RG>…


From: ippm <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, January 11, 2023 at 7:39 PM
To: Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-stamp-srpm
Dear All,
I realized that I have several additional questions:

  *   What is reflected by the Length field in the TLVs defined in the draft? As I can see it, the field is two-octet long. Can its value be any number between 0 and 65535?
<RG> Added Length field description in the updated draft for all TLVs and sub-TLVs.

  *   Also, it seems like there too few descriptions of the fields of the defined in the draft TLVs.
<RG> Added in the updated draft for all TLVs and Sub-TLVs. Please let me know if any field is still missed.

  *   Returning to the Verification flag discussion. In Section 4 of RFC 8972 we defined three flags that have a single TLV scope. Among these flags is Unrecognized (U) defined as follows:
      U (Unrecognized):  A one-bit flag.  A Session-Sender MUST set the U
      flag to 1 before transmitting an extended STAMP test packet.  A
      Session-Reflector MUST set the U flag to 1 if the Session-
      Reflector has not understood the TLV.  Otherwise, the Session-
      Reflector MUST set the U flag in the reflected packet to 0.
It seems like the Urecognized flag can be used to indicate functional mismatch between the request expressed in the STAMP test packet by the Session-Sender and STAMP capability of the Session-Reflector. Hence, I don't see a use case to introduce the Verification flag.
<RG> Added additional details in the first paragraph in the updated draft in Section 3.
<RG> Please see further replies below.
Regards,
Greg


On Wed, Jan 11, 2023 at 1:17 PM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Dear Authors,
thank you for your work on this document. I read the latest version and have several questions and notes:

  *   It seems like the rationale for introducing the Verification flag is to differentiate between the Stateful and Stateless modes of a Session-Reflector. Is that correct?
<RG> Both modes. It is clarified in the updated draft in Section 3.1.

  *   I think using configuration information or other out-of-band discovery of STAMP capabilities is more appropriate than a Session-Reflector dropping a test packet if one of several requested actions cannot be completed.
<RG> Ok.

  *   It is operationally more valuable to return information to the sender, indicating success or failure in performing the requested action. Dropping the reflected STAMP test packet because of the failure of the Session-Reflector to perform one of the requested actions does not provide useful feedback to the Session-Sender, as it cannot be easily differentiated by the Session-Sender from a lost packet.
<RG> Ok, removed the “drop the packet” texts in the updated draft in Section 3.1.

  *   If there's a belief that some STAMP extensions need further specification for the Session-Reflector Stateless mode, a new document should be presented.
<RG> I don’t see any need for that.

  *   It is not clear to me why in the case of SRv6, the Session-Sender will use the loopback as the destination IPv6 address rather than the actual IPv6 address of the Session-Reflector.
<RG> Added a text for this in the updated draft Section 4, second paragraph.

  *   Nit:
probably s/that is supports/that it supports/
also s/may not reach the intended/may reach an unintended/

<RG> Fixed in the updated draft.

Many thanks Greg for the detailed review.

Thanks,
Rakesh


Regards,
Greg

On Tue, Jan 3, 2023 at 12:29 PM Tommy Pauly <tpauly=[e-mail]<mailto:[e-mail]>> wrote:
Hello IPPM,

This email starts a Working Group Last Call for draft-ietf-ippm-stamp-srpm. As discussed at IETF 115, this document has already received its early allocation and has been stable for some time with no open issues.

https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-06.html
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/

Please review the document and provide feedback to the mailing list on any comments you have, and if you think the document is ready to progress. The last call will end on Friday, January 20.

Best,
Tommy & Marcus
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm