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 <https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08> and iOAM in IPv6 <https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-00> drafts? As I understand it, the data draft already includes the mechanism to trigger the timestamp collection on a node by setting the appropriate flags in the IOAM-Trace-Type field. And the IOAM-Trace-Type field is part of iOAM in IPv6 encapsulation. If that is the case, I don't see the gap that needs to be closed but the duplication of functionality by the proposed END.OTP function.
Regards, Greg On Thu, Dec 19, 2019 at 7:06 AM Robert Raszuk <rob...@raszuk.net> wrote: > 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: > > Scope: This document defines the data fields and associated data > types for in-situ OAM. The in-situ OAM data field can be transported > by a variety of transport protocols, including NSH, Segment Routing, > Geneve, IPv6, or IPv4. * Specification details for these different > transport protocols are outside the scope of this document.* > > > I think current SR OAM draft fills that gap. > > Thx > R. > > > On Thu, Dec 19, 2019 at 3:49 PM Greg Mirsky <gregimir...@gmail.com> wrote: > >> 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 local to a networking node is applied to a data flow, in other >> words, the timestamp value is not stored in the forwarded downstream data >> packet, which performance metric your expect to produce? Or is the >> expectation to use the Alternate Marking methodology, as described in RFC >> 8321, in combination with the local timestamping? If the product of the >> timestamping operation is stored in the data packet, then how is that >> different from what is already described in the iOAM draft you've >> referenced? 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? >> >> Regards, >> Greg >> >> On Thu, Dec 19, 2019 at 1:56 AM Robert Raszuk <rob...@raszuk.net> wrote: >> >>> 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 quality of the path based >>> on packets timestamps ? Yes routers may never be involved in such >>> processing, but other network monitoring components do. >>> >>> Sure current networking in this regard is in stone ages, but there are >>> real efforts and working code which goes beyond that already in place. >>> Example: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08 >>> >>> So there is huge value in defining packet timestamping in all >>> oam documents IETF produces these days and it would be rather disservice to >>> remove such important option. >>> >>> Thx, >>> r. >>> >>> >>> On Thu, Dec 19, 2019 at 1:45 AM Joel M. Halpern <j...@joelhalpern.com> >>> wrote: >>> >>>> 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 use >>>> of this timestamp. Until such a behavior is defined, what is the value >>>> in defining the END.OTP behavior? (Taken in the extreme, until there >>>> is >>>> such a definition, any implementation which treated END.OTP as END.OP >>>> would seem to be indistinguishable from proper operation in terms of >>>> behavior on the wire.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/18/2019 7:01 PM, Zafar Ali (zali) wrote: >>>> > Hi Joel, >>>> > >>>> > Thanks for your review. >>>> > >>>> > The processing details were embedded in the Section 4. >>>> > >>>> > We brought them up in the Section 3 and also added additional >>>> normative >>>> > language in Section 4. >>>> > >>>> > We have been maintaining the latest version of the draft in the >>>> Github.. >>>> > >>>> > However, we also posted the latest diffs, which addresses your >>>> comments >>>> > as follows: >>>> > >>>> > * In the new revision, we have added normative text at the beginning >>>> > of 3.1.1 where O-bit is defined. >>>> > * Sections 3.3 and 3.4 adds normative texts for OAM SIDs. >>>> > * 4.1.2 and 4.2.2 further adds additional normative text for Ping >>>> and >>>> > traceroute use-cases, respectively. >>>> > >>>> > Latest version is kept in the Github and also uploaded as >>>> > https://www.ietf.org/staging/draft-ietf-6man-spring-srv6-oam-03.txt. >>>> > >>>> > Thanks >>>> > >>>> > Regards … Zafar >>>> > >>>> > *From: *"Joel M. Halpern" <j...@joelhalpern.com> >>>> > *Date: *Thursday, December 5, 2019 at 10:01 PM >>>> > *To: *"Zafar Ali (zali)" <z...@cisco.com>, 6man WG <i...@ietf.org>, >>>> > SPRING WG <spring@ietf.org> >>>> > *Subject: *Re: 6man w.g. last call for >>>> <draft-ietf-6man-spring-srv6-oam> >>>> > >>>> > Sorry, minor typo. SRH, not NSH, in the 4th paragraph. >>>> > >>>> > Joel >>>> > >>>> > On 12/5/2019 9:42 PM, Joel M. Halpern wrote: >>>> > >>>> > The normative behavior for the bits in various places says that >>>> the >>>> > >>>> > packet is punted to the control process. In and of itself, that >>>> is >>>> > fine. >>>> > >>>> > However, in order for that to be useful, the control process has >>>> to >>>> > know >>>> > >>>> > what to do with the packet when it gets there. In the classic >>>> case of >>>> > >>>> > router redirect, this is coupled with definition of various >>>> content to >>>> > >>>> > be processed by the router control logic. >>>> > >>>> > In the case of this document, there is no normative definition of >>>> what >>>> > >>>> > the control process is to do with the packet. And particularly >>>> > since in >>>> > >>>> > many of the cases described the packet that is punted still has >>>> an SRH, >>>> > >>>> > normal packet processing would simply reach the same "punt" >>>> step. With >>>> > >>>> > nowhere to punt it. >>>> > >>>> > You asssume in the examples that some forms of parsing that >>>> bypass the >>>> > >>>> > NSH will take place. But processing does not take place by >>>> instinct or >>>> > >>>> > magic. It takes place because we write RFCs that describe what >>>> has to >>>> > >>>> > happen. Without some definition of the required parsing, and I >>>> believe >>>> > >>>> > (although I am guessing due to the lack of description) we also >>>> need >>>> > >>>> > some normative description of what the control process is required >>>> > to do. >>>> > >>>> > Note that in most OAM, we define the behavior that is required, >>>> and >>>> > then >>>> > >>>> > indicate where it is permitted to use the control plane to >>>> achieve it. >>>> > >>>> > This results in a clear specification, and implementation >>>> flexibility. >>>> > >>>> > Yours, >>>> > >>>> > Joel >>>> > >>>> > On 12/5/2019 9:34 PM, Zafar Ali (zali) wrote: >>>> > >>>> > Hi Joel, >>>> > >>>> > I did not understand your comment. >>>> > >>>> > Can you please point to specific text in the draft for which >>>> the >>>> > draft >>>> > >>>> > needs to define normative behavior for the "node punt >>>> processor >>>> > look >>>> > >>>> > past the SRH and make determinations based on the content."? >>>> > >>>> > Thanks >>>> > >>>> > Regards … Zafar >>>> > >>>> > *From: *ipv6 <ipv6-boun...@ietf.org >>>> > <mailto:ipv6-boun...@ietf.org>> on behalf of "Joel M. >>>> Halpern" >>>> > >>>> > <j...@joelhalpern.com <j...@joelhalpern..com> <mailto: >>>> j...@joelhalpern.com>> >>>> > >>>> > *Date: *Wednesday, December 4, 2019 at 4:37 PM >>>> > >>>> > *To: *Ole Troan <otr...@employees.org >>>> > <mailto:otr...@employees.org>>, 6man WG <i...@ietf.org >>>> > <mailto:i...@ietf.org>>, >>>> > >>>> > SPRING WG <spring@ietf.org <mailto:spring@ietf.org>> >>>> > >>>> > *Subject: *Re: 6man w.g. last call for >>>> > <draft-ietf-6man-spring-srv6-oam> >>>> > >>>> > I re-read this draft, and I am afraid it is currently >>>> > under-specified. >>>> > >>>> > In order for the various examples to work, there is assumed >>>> > behavior by >>>> > >>>> > the processor to which packets are punted. I could not find >>>> > where this >>>> > >>>> > normative behavior is described explicitly. It appears that >>>> the >>>> > >>>> > behavior requires that the node "punt processor" look past the >>>> > SRH and >>>> > >>>> > make determinations based on the content. This needs to be >>>> > described >>>> > >>>> > explicitly. And it needs some discussion of why it is >>>> legitimate to >>>> > >>>> > look past the SRH when the SRH does not show SL=0. >>>> > >>>> > Yours, >>>> > >>>> > Joel >>>> > >>>> > On 12/4/2019 3:53 PM, Ole Troan wrote: >>>> > >>>> > Hello, >>>> > >>>> > As agreed in the working group session in >>>> Singapore, this >>>> > >>>> > message starts a new two week 6MAN Working Group Last >>>> Call on >>>> > >>>> > advancing: >>>> > >>>> > Title : Operations, Administration, and >>>> Maintenance >>>> > (OAM) in >>>> > >>>> > Segment Routing Networks with IPv6 Data plane (SRv6) >>>> > >>>> > Author : Z. Ali, C. Filsfils, S. Matsushima, D. >>>> > Voyer, M. Chen >>>> > >>>> > Filename : draft-ietf-6man-spring-srv6-oam-02 >>>> > >>>> > Pages : 23 >>>> > >>>> > Date : 2019-11-20 >>>> > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/ >>>> > >>>> > as a Proposed Standard. >>>> > >>>> > Substantive comments and statements of support for >>>> > publishing this >>>> > >>>> > document should be directed to the mailing list. >>>> > >>>> > Editorial suggestions can be sent to the author. This >>>> last >>>> > call will >>>> > >>>> > end on the 18th of December 2019. >>>> > >>>> > To improve document quality and ensure that bugs are >>>> caught >>>> > as early >>>> > >>>> > as possible, we would require at least >>>> > >>>> > two reviewers to do a complete review of the >>>> > document. Please let >>>> > >>>> > the chairs know if you are willing to be a reviewer. >>>> > >>>> > The last call will be forwarded to the spring working >>>> > group, with >>>> > >>>> > discussion directed to the ipv6 list. >>>> > >>>> > Thanks, >>>> > >>>> > Bob & Ole, 6man co-chairs >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > IETF IPv6 working group mailing list >>>> > >>>> > i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org> >>>> > >>>> > Administrative Requests: >>>> > https://www.ietf.org/mailman/listinfo/ipv6 >>>> > >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > IETF IPv6 working group mailing list >>>> > >>>> > i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org> >>>> > >>>> > Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> > IETF IPv6 working group mailing list >>>> > >>>> > i...@ietf.org <mailto:i...@ietf.org> >>>> > >>>> > Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> > >>>> > >>>> -------------------------------------------------------------------- >>>> > >>>> >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> i...@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
