Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> - END.OTP

["Joel M. Halpern" <[e-mail]>]

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 paths that make sense to me.  One way is to define that 
behavior as part of the SRv6 OAM draft.  In that case, the draft would 
define END.OTP and explain a case where it was useful.  So there would 
be a point in defining it.
Alternatively, and more realistically since there is not yet WG 
agreement on your draft, your SR OAM draft could define END.OTP.  In 
which case Zafar could simply remove it from the base draft.
A draft defining a distinction of internal behavior that is not 
externally visible is not providing value in that regard.  I have had 
this same discussion with folks in other working groups.  Defining a 
code point without giving it a usage is not clean standardization.

Yours,
Joel

On 12/19/2019 9:57 AM, Rakesh Gandhi wrote:
> Hi Greg, Joel,
> 
> FYI, END.OTP is used with TWAMP Light (RFC 5357) (and STAMP) in 
> draft-gandhi-spring-twamp-srpmand 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 <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>> 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" <[e-mail]
>             <mailto:[e-mail]>>
>              > *Date: *Thursday, December 5, 2019 at 10:01 PM
>              > *To: *"Zafar Ali (zali)" <[e-mail]
>             <mailto:[e-mail]>>, 6man WG <[e-mail]
>             <mailto:[e-mail]>>,
>              > SPRING WG <[e-mail] <mailto:[e-mail]>>
>              > *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 <[e-mail]
>             <mailto:[e-mail]>
>              >         <mailto:[e-mail]
>             <mailto:[e-mail]>>> on behalf of "Joel M. Halpern"
>              >
>              >         <[e-mail]
>             <mailto:jmh@joelhalpern...com> <mailto:[e-mail]
>             <mailto:[e-mail]>>>
>              >
>              >         *Date: *Wednesday, December 4, 2019 at 4:37 PM
>              >
>              >         *To: *Ole Troan <[e-mail]
>             <mailto:[e-mail]>
>              >         <mailto:[e-mail]
>             <mailto:[e-mail]>>>, 6man WG <[e-mail]
>             <mailto:[e-mail]>
>              >         <mailto:[e-mail] <mailto:[e-mail]>>>,
>              >
>              >         SPRING WG <[e-mail]
>             <mailto:[e-mail]> <mailto:[e-mail]
>             <mailto:[e-mail]>>>
>              >
>              >         *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
>              >
>              > [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>              >
>              >              Administrative Requests:
>              > https://www.ietf.org/mailman/listinfo/ipv6
>              >
>              >
>              >       
>               --------------------------------------------------------------------
>              >
>              >       
>               --------------------------------------------------------------------
>              >
>              >         IETF IPv6 working group mailing list
>              >
>              > [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>              >
>              >         Administrative Requests:
>             https://www.ietf.org/mailman/listinfo/ipv6
>              >
>              >       
>               --------------------------------------------------------------------
>              >
>              >   
>               --------------------------------------------------------------------
>              >
>              >     IETF IPv6 working group mailing list
>              >
>              > [e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail] <mailto:[e-mail]>>
>              >
>              >     Administrative Requests:
>             https://www.ietf.org/mailman/listinfo/ipv6
>              >
>              >   
>               --------------------------------------------------------------------
>              >
> 
>             _______________________________________________
>             spring mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/spring
> 
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
> 
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>