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

[[e-mail]]

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.









Regards,


Greg Mirsky






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









E: [e-mail] 
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]> 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]> 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.
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 
 _______________________________________________
 ippm mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/ippm



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