Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt

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

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

From: ippm <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Thursday, May 13, 2021 at 5:06 PM
To: tpauly=[e-mail] <tpauly=[e-mail]>, [e-mail] <[e-mail]>
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.

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

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

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

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


Thanks,
Rakesh



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.



Regards,

Greg Mirsky



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


[cid:image001.gif@01D748B2.45C47340]
[cid:image002.gif@01D748B2.45C47340]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail

From: Tommy Pauly <tpauly=[e-mail]>
Sent: viernes, 7 de mayo de 2021 22:44
To: IETF IPPM WG <[e-mail]>
Subject: Re: [ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt

Hi IPPM,

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.

Best,
Tommy



On May 3, 2021, at 9:42 AM, Rakesh Gandhi <[e-mail]<mailto:[e-mail]>> 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.

Thanks,
Rakesh (for co-authors)


On Thu, Apr 29, 2021 at 7:03 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-gandhi-ippm-stamp-srpm-03.txt
        Pages           : 12
        Date            : 2021-04-29

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-gandhi-ippm-stamp-srpm/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-gandhi-ippm-stamp-srpm-03
https://datatracker.ietf.org/doc/html/draft-gandhi-ippm-stamp-srpm-03

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.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