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

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

Hi Greg,

Thank you for your further review comments.

Please see replies inline with <RG>..

From: Greg Mirsky <[e-mail]>
Date: Monday, January 30, 2023 at 7:36 PM
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 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