Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, Joel, We can add clarification text. Happy Holidays! Thanks Regards … Zafar From: Greg Mirsky Date: Thursday, December 19, 2019 at 12:44 PM To: "Zafar Ali (zali)" Cc: Robert Raszuk , SPRING WG , 6man WG Subject: Re: [spring] 6man w.g. last call for - END.OTP Hi Za

Re: [spring] 6man w.g. last call for - END.OTP

*To: *Robert Raszuk > *Cc: *SPRING WG , 6man WG > *Subject: *Re: [spring] 6man w.g. last call for > - END.OTP > > > > Hi Robert, > > thank you for your quick response. Could you please help me understand how > this proposed mechanism complements what is defined in the com

Re: [spring] 6man w.g. last call for - END.OTP

Ali (zali) wrote: Hi Greg, The END.OTP SID is NOT defined or to be used for in-situ OAM. Thanks Regards … Zafar *From: *ipv6 on behalf of Greg Mirsky *Date: *Thursday, December 19, 2019 at 10:21 AM *To: *Robert Raszuk *Cc: *SPRING WG , 6man WG *Subject: *Re: [spring] 6man w.g. las

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, The END.OTP SID is NOT defined or to be used for in-situ OAM. Thanks Regards … Zafar From: ipv6 on behalf of Greg Mirsky Date: Thursday, December 19, 2019 at 10:21 AM To: Robert Raszuk Cc: SPRING WG , 6man WG Subject: Re: [spring] 6man w.g. last call for - END.OTP Hi Robert

Re: [spring] 6man w.g. last call for - END.OTP

Rakesh, I appreciate the pointers. However, I believe some clarification is in order. RFC 5357 does not use END.OTP. It does not mention END.OTP. It can't, since END.OTP did not exist when it was written. Your individual draft on twamp does reference END.OTP. This leads to two possible p

Re: [spring] 6man w.g. last call for - END.OTP

Hi Robert, thank you for your quick response. Could you please help me understand how this proposed mechanism complements what is defined in the combination of iOAM data and iOAM in IPv6

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, > I believe that iOAM already has defined a method to collect timestamps > and the method to trigger timestamping described in the draft we're > discussing is duplicating that. Would you agree? Nope not at all. The timestamping is needed in the SR paths in the outer header. iOAM says:

Re: [spring] 6man w.g. last call for - END.OTP

Hi Rakesh, thank you for pointing to this interesting proposal. But, as I understand RFC 5357 and Appendix I, timestamp collection is already part of the TWAMP. Why there's the need to duplicate what is being documented in RFC 5357? Regards, Greg On Thu, Dec 19, 2019 at 6:57 AM Rakesh Gandhi wro

Re: [spring] 6man w.g. last call for - END.OTP

Hi Greg, Joel, FYI, END.OTP is used with TWAMP Light (RFC 5357) (and STAMP) in draft-gandhi-spring-twamp-srpm and RFC 6374 in draft-gandhi-spring-rfc6374-srpm-udp, for performance delay measurement use-case. thanks, Rakesh On Thu, Dec 19, 2019 at 9:49 AM Greg Mirsky wrote: > Hi Robert, > coul

Re: [spring] 6man w.g. last call for - END.OTP

Hi Robert, could you please clarify your statement "there is huge value in defining packet timestamping in all oam documents IETF produces these days"? Is that applicable to Active OAM methods or to other OAM methodologies, including, Passive and Hybrid? If the timestamping operation is entirely lo

Re: [spring] 6man w.g. last call for - END.OTP

Hi Joel, > However, there is no defined behavior that I know of that can make use > of this timestamp. Not sure how to read that statement. Are you expecting IETF draft to tell vendor that computing delta of N values is needed ? Or is IETF draft needed to tell packet analyzers to evaluate the qu

Re: [spring] 6man w.g. last call for - END.OTP

If I am reading the draft correctly, the difference between END.OP and END.OTP is that an internal process is to attach in some internal location a timestamp to the packet. In the abstract, I understand why such cna be useful. However, there is no defined behavior that I know of that can make