Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt Mon, 17 May 2021 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E4693A42E5 for <>; Mon, 17 May 2021 13:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 CgSG2gOlaEuv for <>; Mon, 17 May 2021 13:01:28 -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 1E7243A42E3 for <>; Mon, 17 May 2021 13:01:27 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 41431416C8AA93FE56D; Tue, 18 May 2021 04:01:26 +0800 (CST)
Received: from ([]) by with SMTP id 14HK1LIH042338; Tue, 18 May 2021 04:01:21 +0800 (GMT-8) (envelope-from
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Tue, 18 May 2021 04:01:20 +0800 (CST)
Date: Tue, 18 May 2021 04:01:20 +0800
X-Zmail-TransId: 2af960a2cb90aeb55a96
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 14HK1LIH042338
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: Mon, 17 May 2021 20:01:34 -0000

Hi Rakesh,

thank you for your expedient and thoughtful responses to the comments. I have added in-line several follow-up questions under tag GIM>>. I greatly appreciate your and other authors thoughts on them.


Greg Mirsky

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


Original Mail

Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;;;
Date: 2021/05/14 08:14
Subject: Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt

Hi Greg,

Thank you for your review comments. Please see replies inline with <RG>…


From: ippm <> on behalf of <>
 Date: Thursday, May 13, 2021 at 5:06 PM
 To: <>, <>
 Subject: Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt

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.

<RG>There is no change in STAMP definition for Session-Sender and Session-Reflector. The reply test packet is transmitted back to the Session-Sender.

GIM>> Thank you for clarifying that for me. 

<RG> We are ok to add text to clarify that “the reply test packet MAY be transmitted to the Session-Sender to a different destination address on the Session-Sender node using Return Path TLV.”

GIM>> Perhaps slighty modified wording can be added:

When transmitting the reflected STAMP test packet, the Session-Sender MUST follow the procedure defined in Section 4.3 [RFC8762].

I think that it will be sufficient and a developer can decide which of Session-Sender's addresses or SIDs used. Would you agree?

Now, as the Session-Reflector may receive explicit route to use for the reflected packet, it seems that that information must be verified by the Session-Reflector to avoid it being used as the attack vector. Also, and that is related to our discussion about the Security Considerations section, the integrity of the information specifying the route for the reflected packet requires protection. I think that RFC 8962 provides tools that can be used in this case.

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

<RG> There is no change in STAMP behavior.
GIM>> Thank you for clarifying it to me. As that is the intention of the proposed mechanism, what is the behavior of the Session-Reflector that receives a STAMP test packet with one of the introduced TLVs? I think that that need to be specified to demonstrate that there's no changes to the behavior defined in RFC 8762. <RG> We are ok to add reference to draft-ietf-ippm-stamp-yang. 
・         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?

<RG> “The address can be IPv6 address, encapsulated in SRH”. We are ok to add that as an example.

・         And what you see as a benefit of selecting the destination address from the 128/8 range compared to using one particular address?

<RG> “Session-Sender may select an IPv4 address from 127/8 range for testing ECMPs.”

GIM>> RFC 6790  and RFC 8662 defined the Entropy Label and its applicability in Segment Routing respectively. The Flow label is recommended to be used in IPv6 and SRv6 ECMP cases. I believe that we can safely choose a single address. Also, which address be used in IPv6 network?

<RG> We are ok to add this sentence.

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

<RG> This format is similar to the TLV defined in RFC 6374 Section 3.5.2, with Length and Address Family.

<RG> Having, said that, we are ok to remove these two fields.

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

<RG> How about following text in the Security Considerations Section?


   “The STAMP extensions defined in this document may be used for    potential "proxying" attacks.  For example, a Session-Sender    may specify a return path that has a destination different from that    of the Session-Sender.  But normally, such attacks will not happen in an    SR domain where the Session-Senders and Session-Reflectors belong to the same    domain.  In order to prevent using the extension defined    in this document for proxying any possible attacks, the return path    has destination to the same node where the forward path    is from.“
 GIM>> I think that one scenario, "man-in-th-middle" (MIM) might break the assumption "normally" and must be considered in this section.





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