Hi Rakesh, the common understanding of the TWAMP and TWAMP Light by IPPM WG is reflected in draft-ietf-ippm-port-twamp-test <https://datatracker.ietf.org/doc/draft-ietf-ippm-port-twamp-test/> (soon to be published as RFC 8545). The work on STAMP is progressing and the base specification, draft-ietf-ippm-stamp <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/>, is in WG LC through March 15. Much appreciate your review and comments. Also, much interested in your comments on draft-mirsky-ippm-stamp-option-tlv <https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/>. I believe that there's a good reason for us to work together on STAMP extensions that address specific SR scenarios.
Regards, Greg On Sun, Mar 3, 2019 at 6:17 AM Rakesh Gandhi (rgandhi) <rgan...@cisco.com> wrote: > Thank you Greg for the thorough review of the document and your comments. > > > > Please see in line with <RG>… > > > > *From: *Greg Mirsky <gregimir...@gmail.com> > *Date: *Thursday, February 28, 2019 at 7:05 PM > *To: *"draft-gandhi-spring-twamp-s...@ietf.org" < > draft-gandhi-spring-twamp-s...@ietf.org>, spring <spring@ietf.org>, IETF > IPPM WG <i...@ietf.org> > *Subject: *Comments on draft-gandhi-spring-twamp-srpm > *Resent-From: *<alias-boun...@ietf.org> > *Resent-To: *"=SMTP:rgandhi@cisco. com" <rgan...@cisco.com>, < > cfils...@cisco.com>, <daniel.vo...@bell.ca> > *Resent-Date: *Thursday, February 28, 2019 at 7:05 PM > > > > Dear Authors, > > I've read the draft and would share my comments with SPRING and IPPM WGs: > > > - Section 3.1.1 > > > - what is introduced in this section? Note, that in OWAMP 'O' stands > for 'one-way', i.e., the receiver collects the measurement results. RFC > 4656 defines Client Fetch command to retrieve, possibly by the > Session-Sender, the measurement results. > > <RG> Idea is that the user provisions the UDP port and the attributes > (e.g. timestamp format, authentication mode/type, etc. associated with the > UDP port) on both endpoints of SR paths. These configurations are used to > interpret *WAMP(Light) payloads to provide delay and loss measurements. The > motivation is to eliminate the control-channel signaling - the spirit of SR. > > - note that RFCs 4656 and 5357 defined the use only of NTP format for > timestamps. The use of PTP format was introduced by RFC 8186 for TWAMP > only > as optional, not as the default mode. The default format for TWAMP-Test > is > still NTP format. You may consider using the mechanism defined for > TWAMP-Control to change the default to PTP format. > > <RG> As mentioned above, the motivation of this work is to move away from > the control-channel signaling to boot-strap PM sessions. So, we are not > extending the control-channel signaling. > > - Section 3.1.2 > > > - a new format for Session-Sender's TWAMP-Test message introduced. > Note, that the format for Session-Sender TWAMP-Test message is the same > as > defined in RFC 4656. If you want to define a new TWAMP-Test optional > format > it first must be negotiated through TWAMP-Control protocol as has been > done > for all TWAMP extensions. > - how the format you've proposed is different from the one proposed > earlier in draft-xiao-ippm-twamp-ext-direct-loss > <https://tools.ietf.org/html/draft-xiao-ippm-twamp-ext-direct-loss-01> > . > - Your intention, if I understand correctly, is > to support direct-mode loss > measurement. draft-xiao-ippm-twamp-ext-direct-loss > proposed that earlier and with proper TWAMP-Control extension. > After the IPPM WG agreed to work on STAMP, > authors of draft-xiao-ippm-twamp-ext-direct-loss and STAMP agreed to > work > together and now the direct-mode loss measurement is part of > draft-mirsky-ippm-stamp-option-tlv > > <https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/?include_text=1> > . > > <RG> Your understanding is correct. Thank you for the background and > pointing to the LM TLV. We can analyze to see if we can leverage the TLV. > Again, we are not extending the control-channel signaling. > > - the last bullet in the section refers to PSID but I couldn't find a > PSID field in any of the displayed formats, authenticated or not. Is it > for > further versions? > > <RG> Ok, we will add the definition/detail in the next revision. > > - Section 3.1.4.1 > > > - what is illustrated in this sub-section? That TWAMP-Test message > with IP/UDP encapsulation can be carried over SR-MPLS tunnel? > > <RG> It shows how the measurement packet is carried over SR-MPLS Policy. > > - Section 3.1.4.2 > > > - same question as above. > > <RG> It shows how the measurement packet is carried over SRv6 Policy and > what END function is used for timestamp and punting the packet. > > - Section 4 > > > - is the formula to calculate the packet loss using the direct-mode > measurement is worth repeating in RFC? > > <RG> It is good to have it at the early stage of the document. We can > remove it later in the process. > > - Section 5 > > > - without the discussion of the impact on the Session-Sender that > reflected test packets may have, I cannot agree with the assumption: > > The procedures for delay and loss measurement described in this > > document for Point-to-Point (P2P) SR-MPLS Policies are also equally > > applicable to the Point-to-Multipoint (P2MP) SR Policies. > > > > <RG> Yes, we can elaborate it in the next revision. Idea it that the > querier uses the source address of the responders (i.e. leafs) to identify > the measurements to each leaf. > > > - Section 7 > > > - OWAMP and TWAMP use HMAC-SHA1 for integrity protection. If your > intent is to use HMAC-SHA-256 in the authenticated mode for OWAMP and/or > TWAMP, then it may be supported as an optional extension with the proper > extension in their respective control protocols. Should note that the > use of HMAC-SHA-256 for STAMP was discussed at IPPM WG meeting in > Bangkok > and now is documented in the latest version of STAMP. > > <RG> Thanks for sharing this information. We will update the draft > accordingly. This is also a property of the UDP port configured and both > methods can be used. As mentioned earlier, we are moving away from using > the control-channel signaling. > > Many thanks for the detailed review and feedbacks. > > Rakesh > > > > Regards, > > Greg > > > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
