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

[[e-mail]]

Hi Rakesh,


thank you for responding to my question. 


As I understand your intention, the Session-Reflector is directed to use a Segment Route tunnel to the Session-Sender. But it is not clear to me how the Session-Reflector can construct a SID list from the single SID that identifies the Session-Sender. Would the Session-Reflector be calculating it for each test packet? That seems like a heavy additional computational task. I much appreciate it if you can clarify that for me.








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



Sender: RakeshGandhi(rgandhi)
To: gregory mirsky10211915;
CC: tpauly=[e-mail];[e-mail];
Date: 2021/05/25 16:32
Subject: Re: Re:[ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt






Hi Greg,


Thank you for your comments.


Please reply inline with <RG3>…


 


 



From: [e-mail] <[e-mail]>
 Date: Friday, May 21, 2021 at 6:47 PM
 To: Rakesh Gandhi (rgandhi) <[e-mail]>
 Cc: tpauly=[e-mail] <tpauly=[e-mail]>, [e-mail] <[e-mail]>
 Subject: Re:[ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt


Hi Rakesh,

thank you for the clarification. I have some follow-up thoughts, please find them below in-line tagged GIM2>>.

 

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



Sender: RakeshGandhi(rgandhi)



To: gregory mirsky10211915;



CC: tpauly=[e-mail];[e-mail];



Date: 2021/05/21 11:25



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




Thanks Greg for your review comments and suggestions.  


Please see replies inline with <RG2>…


 



From: [e-mail] <[e-mail]>
 Date: Thursday, May 20, 2021 at 12:38 AM
 To: Rakesh Gandhi (rgandhi) <[e-mail]>
 Cc: tpauly=[e-mail] <tpauly=[e-mail]>, [e-mail] <[e-mail]>
 Subject: Re:[ippm] I-D Action: draft-gandhi-ippm-stamp-srpm-03.txt


Hi Rakesh,

I've got a question and will greatly appreciate it if you can clarify for me:

as I understand it, the proposed TLVs are applicable in p2p SR policies as well as p2mp. Is that accurate? If so, how, for example, the Destination Node Address TLV is used by the Session-Reflector at the egress of an SR tunnel?

<RG2> Destination Node Address TLV can be used for P2P SR Policies only. Ok to add this text in the next revision.


Or the Return Segment List sub-TLV?

<RG2> Return Path Segment List can be used for P2MP, for example, by specifying just the Node SID of the Session-Sender.

GIM2>>Yes, I see. But, on the other hand, the Session-Sender is already identified through the Source IP address in the STAMP test packet received by the Session-Reflector. As I understand it, in the SRv6 domain, the STAMP test packet is encapsulated in IP/UDP with SRH. Right? In SR-MPLS, the STAMP test packet uses IP/UDP encapsulation, and the IP packet immediately follows the MPLS label stack. In both cases, the Source IP address is the address of the STAMP Session-Sender. If that is correct, adding the Node SID of the Session-Sender seems like an unnecessary duplication. What do you think?

<RG3> Without Return Path, the reply test packet may be transmitted via an IP path (existing STAMP Session-Reflector behaviour).  With specifying just Session-Sender Node SID in Return Path Segment List, the reply test packet is transmitted via an SR path by the Session-Reflector.

Thanks,

Rakesh

 

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



Sender: gregory mirsky10211915



To: [e-mail];



CC: tpauly=[e-mail];[e-mail];



Date: 2021/05/17 13:01



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




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

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.

 

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






 






Sender: RakeshGandhi(rgandhi)



To: gregory mirsky10211915;tpauly=[e-mail];[e-mail];



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

 


1.       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].

<RG2> Ok to add this text in the next update.

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.


2.       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.   <RG2> The change is that the Session-Reflector uses the Return Path TLV to reply if present.   <RG> We are ok to add reference to draft-ietf-ippm-stamp-yang. 
3.       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.


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

<RG2> Agree. For IPv6 it would be ::1/128. We can add this in the next revision. <RG> We are ok to add this sentence.


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


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


<RG2> We can add some text for this case in the next revision.


Thanks,


Rakesh


 


 


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


 






 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