Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt Thu, 13 May 2021 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A73893A13A6 for <>; Thu, 13 May 2021 14:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HvPC8MgTtZXu for <>; Thu, 13 May 2021 14:05:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B0B23A13AF for <>; Thu, 13 May 2021 14:05:11 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 5D5676B4C6F3A94BF515; Fri, 14 May 2021 05:05:08 +0800 (CST)
Received: from ([]) by with SMTP id 14DL53MN018229; Fri, 14 May 2021 05:05:03 +0800 (GMT-8) (envelope-from
Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Fri, 14 May 2021 05:05:02 +0800 (CST)
Date: Fri, 14 May 2021 05:05:02 +0800
X-Zmail-TransId: 2afa609d947e022fd92a
X-Mailer: Zmail v1.0
Message-ID: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 14DL53MN018229
Archived-At: <>
Subject: Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 May 2021 21:05:17 -0000

Dear Authors, 

thank you for your kind consideration of our discussion and for thoughtfully addressing comments. I find the document well aligned with RFCs 8762 and 8962. I have several questions I hope you can help me understand.

As I understand it, the Return Path TLV and its sub-TLVs may direct the reflected STAMP packet to a node other than the Session-Sender of that test session. Is that correct? If it is, what is that node in STAMP? RFCs 8762 and 8962 don't define how a separate system, different from the STAMP Session-Sender acts as the receiver of the reflected STAMP test packet. I think that there are many questions related to such an arrangement that must be clarified before the proposed mechanism can be seen as technically viable.

In the draft, you've noted that STAMP does not require the control channel to instantiate a test session. I agree but would point out that that doesn't negate the need to prevent overloading the Session-Reflector with too many test packets. I couldn't find a reference to the STAMP YANG data model in the document. Do you envision that it must be used in the SR environment? If not, how a Session-Reflector is protected from the excess of test packets?

In the first paragraph of Section 3, you've described a case of encapsulation as "an MPLS Segment List with IPv4 address from 127/8 range". Could you clarify how the packet encapsulated if the source has no IPv4 but only an IPv6 address? And what you see as a benefit of selecting the destination address from the 128/8 range compared to using one particular address?

Figure 1 presents the format of Destination Node Address TLV. the Address Family, as I understand it, can be IPv4 or IPv6. As there's no mention that the TLV can include sub-TLVs, the value in the Length field can be used to identify the address family. If so, Reserved and Address Family fields seem unnecessary.

It appears that the Security Considerations section needs more details on mitigating the threat of DoS attack using the Return Path TLV and sub-TLV.

I much appreciate the work done by the authors and hope that we can discuss and address the issues listed above. In the meantime, I cannot support the adoption of the document by the IPPM WG.


Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


Original Mail

From: Tommy Pauly <>
 Sent: viernes, 7 de mayo de 2021 22:44
 Subject: Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt




This draft has been discussed and debated at length before, and the chairs would like to get input from the WG on their thoughts on this version of the document and its direction. Given the interaction with other working groups, we’d like to make progress on this in a timely fashion.


Please do send your thoughts and feedback to the list, particularly if you support this work, or if you have concerns new or existing.





On May 3, 2021, at 9:42 AM, Rakesh Gandhi <> wrote:


Hi WG,

This revision contains following updates:

Welcome Richard as a co-author

Merge Segment List Sub-TLVs

Various editorial changes


Welcome your review comments and suggestions.



Rakesh (for co-authors)



On Thu, Apr 29, 2021 at 7:03 PM <> 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-gandhi-ippm-stamp-srpm-03.txt
         Pages           : 12
         Date            : 2021-04-29
    Segment Routing (SR) leverages the source routing paradigm.  SR is
    applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
    (SRv6) data planes.  This document specifies RFC 8762 (Simple Two-Way
    Active Measurement Protocol (STAMP)) extensions for SR networks, for
    both SR-MPLS and SRv6 data planes by augmenting the optional
    extensions defined in RFC 8972.
 The IETF datatracker status page for this draft is:
 There are also htmlized versions available at:
 A diff from the previous version is available at:
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at
 Internet-Drafts are also available by anonymous FTP at:
 ippm mailing list

 ippm mailing list