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
