Re: [ippm] draft-ietf-ippm-stamp-srpm - request for Early Allocation of IANA code-points

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

Thank you, Greg, for your review comments and suggestions. Please see replies in line with <RG>…

From: ippm <[e-mail]> on behalf of Greg Mirsky <[e-mail]>
Date: Thursday, July 7, 2022 at 10:48 PM
To: Marcus Ihlar <marcus.ihlar=[e-mail]>
Cc: IPPM Chairs <[e-mail]>, IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] draft-ietf-ippm-stamp-srpm - request for Early Allocation of IANA code-points
Hi Marcus and Rakesh,
thank you for reminding me to read and comment on the draft. Below, pelase, find my notes and questions:

  *   it is not clear how the Verification flag benefits operation. RFC 8762 defines that
   By default, STAMP uses symmetrical packets, i.e., the size of the
   packet transmitted by the Session-Reflector equals the size of the
   packet received by the Session-Reflector.
Thus, a STAMP Session-Reflector that does not support a particular STAMP Extension will return that TLV in the reflected packet unchanged or as all zeros.

<RG> This is for the STAMP Session-Reflector that supports the STAMP SR Extension as described in the draft, where the TLV includes an instruction for the Session-Reflector to follow.  It provides feedback to the Session-Sender if the Session-Reflector was able to follow that instruction.  The use-case is: Session-Reflector supported the TLV and it was well formed, STAMP test packet was processed but the additional instruction in the TLV was not followed.  The Session-Reflector can decide what to do with the test packet reply, process and record the results, count the verification error, or reject the test packet.

  *   Furthermore, if an extended STAMP test packet includes multiple TLVs and some have the V flag set, then what is the behavior of the STAMP Session-Reflector?
<RG> The V flag is specific to a TLV. If verification check fails for a TLV, drop the test packet or return check failed error for that TLV as described in the draft.  The action of the Session-Reflector would be determined by the type of instruction in the TLV.  A critical failure to process, like wrong destination could be to discard, or a choice could be made to return the test packet to the Session-Reflector to stop the test session.

  *   It appears that the use case for the Destination Address TLV is based on the assumption of the particular encapsulation of the STAMP test packet in MPLS. Is there a document that defines how STAMP is used over an MPLS network (similar to what RFC 5884 is for BFD specification in RFC 5880)? Had MPLS WG discussed it and agreed to?
<RG> The scope of the document is SR and there is a companion document in SPRING (draft-ietf-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-ietf-spring-stamp-srpm/>).

  *   Also on the Destination Address TLV. RFC 8972 defined STAMP Session Identifier (SSID) that, in combination with the Source IP address, uniquely identifies the STAMP test session and is sufficient to demultiplex them. Hence, it is not clear why the Destination Address TLV is needed.
<RG> The destination address in the TLV contains the actual destination address of the Session-Reflector, which is part of the STAMP session.

  *   I've got a question about the behavior of a STAMP Session-Reflector if there's no Return Path TLV in the received STAMP test packet. And while I understand the concept of network programmability, I'd imagine that for the given STAMP test session, downstream and upstream paths must remain unchanged (at least are expected to be unchanged and a noticeable change in packet delay will probably be correlated to a change in paths). If my assumption is correct, it seems that defining the return path can be achieved through a local policy by identifying the STAMP test session using SSID and the Source IP address tuple.
<RG> There are two behaviors on the Session-Reflector as per RFC 8762.  A Session-Reflector that requires configuration that must match all Session-Sender attributes SA, DA, SourceUdpPort, DestUdpPort, and possibly SSID (assuming the SSID is configurable and not auto-generated).  In the case of configuration, local policy could be used to direct the packet by creating additional states on the Session-Reflector.  In the case of promiscuous operation, the stateless Session-Reflector would require an indication of how to return test packet on the specific path, for example, in an ECMP environment.

  *   In addition, a question about Figure 5. The Segment field is 32 bit-long while an MPLS label - 20 bit-long. How an MPLS label is encoded in the Segment field?
<RG> It is a 32-bit LSE.

  *   And, finally, on the requested IANA actions. A new sub-registry Return Path Sub-TLV Type is requested in the document. As I understand the requested early IANA allocation, it is left outside for now. What is the rationale for that?
<RG> This registry also should be included in early allocation.
Thanks,
Rakesh (for co-authors)
Regards,
Greg

On Thu, Jul 7, 2022 at 8:41 AM Marcus Ihlar <marcus.ihlar=[e-mail]<mailto:[e-mail]>> wrote:
Hi Rakesh,
Thank you for the request.
Could you please verify that you are referring to both: Destination Node Address TLV and Return Path TLV?

To the IPPM WG:
If you strongly object to requesting an early allocation of the IANA codepoints in draft-ietf-ippm-stamp-srpm please let us know by replying to this email.
Please also indicate the reason for your objection.

BR
Marcus

From: Rakesh Gandhi <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, 6 July 2022 13:49
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: IPPM Chairs <[e-mail]<mailto:[e-mail]>>
Subject: draft-ietf-ippm-stamp-srpm - request for Early Allocation of IANA code-points

Hi Chairs,

We like to request early allocation of the IANA code points to facilitate interop testing. Please let us know of the next steps.

Thanks,
Rakesh (for co-authors)


On Tue, Jul 5, 2022 at 5:31 PM <[e-mail]<mailto:[e-mail]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.

        Title           : Simple TWAMP (STAMP) Extensions for Segment Routing Networks
        Authors         : Rakesh Gandhi
                          Clarence Filsfils
                          Daniel Voyer
                          Mach(Guoyi) Chen
                          Bart Janssens
                          Richard Foote
  Filename        : draft-ietf-ippm-stamp-srpm-04.txt
  Pages           : 17
  Date            : 2022-07-05

Abstract:
   Segment Routing (SR) leverages the source routing paradigm.  SR is
   applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
   (SRv6) forwarding planes.  This document specifies RFC 8762 (Simple
   Two-Way Active Measurement Protocol (STAMP)) extensions for SR
   networks, for both SR-MPLS and SRv6 forwarding planes by augmenting
   the optional extensions defined in RFC 8972.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-srpm-04


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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