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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[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]> 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]>
>>> 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]>
>>>> > *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] <jmh@joelhalpern..com> <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
>>>> >
>>>> >
>>>>  --------------------------------------------------------------------
>>>> >
>>>>
>>>> _______________________________________________
>>>> spring mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>