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

[Greg Mirsky <[e-mail]>]

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

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]>
wrote:

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