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

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

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]>
> *Date: *Thursday, December 5, 2019 at 10:01 PM
> *To: *"Zafar Ali (zali)" <[e-mail]>, 6man WG <[e-mail]>, 
> SPRING WG <[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]>> on behalf of "Joel M. Halpern"
> 
>         <[e-mail] <mailto:[e-mail]>>
> 
>         *Date: *Wednesday, December 4, 2019 at 4:37 PM
> 
>         *To: *Ole Troan <[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>
> 
>         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]>
> 
>              Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
> 
>             
>         --------------------------------------------------------------------
> 
>         --------------------------------------------------------------------
> 
>         IETF IPv6 working group mailing list
> 
>         [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]>
> 
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     --------------------------------------------------------------------
>