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.

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

Regards,
Greg

On Thu, Jul 7, 2022 at 8:41 AM Marcus Ihlar <marcus.ihlar=
40ericsson.com@dmarc.ietf.org> 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 <rgandhi.ietf@gmail.com>
> *Sent:* Wednesday, 6 July 2022 13:49
> *To:* IETF IPPM WG <ippm@ietf.org>
> *Cc:* IPPM Chairs <ippm-chairs@ietf.org>
> *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 <internet-drafts@ietf.org> 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
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>