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

[Greg Mirsky <[e-mail]>]

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.
   - 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.
   - 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?
   - 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.
   - 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?
   - Section 5.1.1 defines the Control Code 0x01 as "Reply Requested on the
   Same Link". Is that a physical or logical link?

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.

Looking forward to our continued discussion.

Regards,
Greg




On Wed, Jan 25, 2023 at 10:31 AM Rakesh Gandhi (rgandhi) <[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]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Wednesday, January 11, 2023 at 7:39 PM
> *To: *Tommy Pauly <tpauly=[e-mail]>
> *Cc: *IETF IPPM WG <[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]> 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]> 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]
> https://www.ietf.org/mailman/listinfo/ippm
>
>