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

[Robert Raszuk <[e-mail]>]

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
>> --------------------------------------------------------------------
>>
>