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

From: Ole Troan <[email-masked]>
Date: Wed, 4 Dec 2019 21:53:24 +0100

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Dec 2019 16:37:15 -0500

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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Dec 2019 17:21:38 -0500

Dear Authors, et al.,
please find my comments, as WG LC comments, questions to this document
below.

   - The Abstract and Introduction describe the document as "defines
   building blocks for Operations, Administration, and Maintenance (OAM) in
   Segment Routing Networks with IPv6 Dataplane (SRv6)". I believe it would be
   helpful to demonstrate that the existing mechanisms used in IPv6 to
   demultiplex and realize OAM functions, e.g., using the well-known
   destination UDP port number, are not sufficient and require the
   introduction of new methods, e.g., O bit in SRH.
   - This document introduces the O-flag into SRH as the building block for
   OAM in SR networks with IPv6 data plane. It appears that the functions that
   are realized using the O-flag are already supported by the existing OAM
   protocols that enable fault management (e.g., variations of Echo
   Request/Reply, BFD) and performance monitoring (e.g., STAMP). Also, the use
   of the new "building block for OAM" in SRv6 splits the SR OAM suit into two
   functionally separate toolsets - one for SR-MPLS and another for SRv6.
   - The document defines the support of O-flag as OPTIONAL. In that case,
   what is the benefit of advertising the support of O-flag by an SR node
   (even though the advertisement itself is optional)?
   - The document uses the term "accurate timestamp" without the discussion
   or definition of what level of accuracy is required or expected, methods to
   acquire an accurate timestamp, format(s) that must or may be used to record
   a timestamp, and what are possible implications of not providing an
   accurate timestamp.
   - The document asserts that to support "Many scenarios require punting
   of SRv6 OAM packets at the desired nodes in the network" can be done only
   with using OAM Endpoint with Punt function. I believe that TTL/Hop Count
   Expired had been used successfully to achieve the same result. what is the
   apparent need to introduce functional duplication to already existing OAM
   technique?  How a packet would be processed if both O-flag and the OAM SID
   End.OP are present (the specification only recommends setting O-flag to 0
   when End.OP SID is present)?
   - Section 3.4 introduces function OAM Endpoint with Timestamp and Punt.
   At the same time, processing the O-flag, defined, as:

            a. Make a copy of the packet.
            b. Send the copied packet, along with an accurate timestamp

Is the difference in making or not making a local copy significant enough
to have two mechanisms to achieve essentially the same result? How a packet
will be processed if both O-flag and the OAM SID End.OTP are present (the
specification only recommends to set O-flag to 0 when END.OTP SID is
present) ?

   - Section 3.5 states that:

   SRH TLV plays an important role in carrying OAM and Performance
   Management (PM) metadata.

I cannot find any other text that illustrates how SRH TLV plays any role in
FM and/or PM OAM.

   - It is stated in Section 4:

   This section describes how OAM mechanisms can be implemented using
   the OAM building blocks described in the previous section.

As this is the Standard document, using the normative language would be
very much desirable. Then it would be clearer whether the use of not only
O-flag but of OAM SIDs as well is optional or mandatory.

   - I've noticed that functions used as an example in the document are all
   part of active OAM functions. At the same time, the defined processing of
   the O-flag is very much similar to the operation of in-situ OAM. But I
   don't find any reference to in-situ OAM mechanism, nor discussion of
   whether both can be used in combination or are mutually exclusive.
   - In Section 4.1.2 the identification of an OAM (active OAM or some
   other kind of OAM) packet defined as:

   The OAM packets are identified either by setting the O-flag in SRH or
   by inserting the END.OP/ END.OTP SIDs at an appropriate place in the
   SRH.

Is the use of any of these methods required for any OAM? If that is the
case, then the normative language must be used. Also, is it required to use
any of these methods for, for example, BFD control packets or STAMP test
packets? Isn't using assigned by IANA port number sufficient to identify
active IP OAM packets? Wouldn't the same be applicable in SRv6 OAM?

   - I have a question on how a local node selects an application that is
   to receive a punted packet (whether marked by O-flag that includes one of
   OAM SIDs)? The document provides examples where the destination is either
   ICMPv6 or a traceroute (?) process. Is that an exhaustive list?

I greatly appreciate your kind consideration and am looking forward to the
productive discussion.

Regards,
Greg

On Wed, Dec 4, 2019 at 3:53 PM Ole Troan <[email-masked]> 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)
> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list.
> two reviewers to do a complete review of the document.  Please let the
> chairs know if you are willing to be a reviewer.
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 6 Dec 2019 02:34:11 +0000

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 <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
Date: Wednesday, December 4, 2019 at 4:37 PM
To: Ole Troan <[email-masked]>, 6man WG <[email-masked]>, SPRING WG <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Yours,
Joel

[email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Dec 2019 21:42:21 -0500

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:
> 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 <[email-masked]> on behalf of "Joel M. Halpern" 
> <[email-masked]>
> *Date: *Wednesday, December 4, 2019 at 4:37 PM
> *To: *Ole Troan <[email-masked]>, 6man WG <[email-masked]>, SPRING 
> WG <[email-masked]>
> *Subject: *Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
> 
>          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)
> 
>     two reviewers to do a complete review of the document.  Please let
>     the chairs know if you are willing to be a reviewer.
> 
>     [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Dec 2019 22:00:52 -0500

Sorry, minor typo.  SRH, not NSH, in the 4th paragraph.
Joel

On 12/5/2019 9:42 PM, Joel M. Halpern wrote:
>> *To: *Ole Troan <[email-masked]>, 6man WG <[email-masked]>, 
>> SPRING WG <[email-masked]>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Dec 2019 16:14:24 +0800

Hello Ole and all,

I re-read this version again with the following comments for the WGLC.

1. Section 4.2.2.2, the penultimate bullet.
The sentence "The traceroute process at node N4 checks if its local SID (B:2:C31) is locally programmed" should be "The traceroute process at node N4 checks if its local SID (B:4:C52) is locally programmed".

2. Requirements Language
[RFC8174] should be added as a nomative reference.

3. Section 3.5 SRH TLV
This section only tells us SRH TLV is defined in ietf-6man-segment-routing-header, nothing else. I think this section should be removed.

4. Section 4.3 Monitoring of SRv6 Paths
This section is a story or a use case. No specification is defined in this section. It should be removed or moved to an appendix.

5. Section 2.1 Abbreviations
ICMPv6 is defined in RFC4443. Why does this draft use it as multi-part ICMPv6 defined in RFC4884. This is confusing.

6. Section 4.1.3 Error Reporting
ICMPv6 is defined in ICMPv6 related RFCs. Does this section want to extend ICMPv6? If yes, I don't think this doc is the appropriate place. If no, why do we need this section? to emphasize the things that a router should do?

With all the commets above, I don't think this doc is mature enough to pass the WGLC.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Ole Troan
Date: 2019-12-05 04:53
To: 6man WG; SPRING WG
CC: 6man Chairs
Subject: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>
Hello,

                         
 
as a Proposed Standard.  

 
 
Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Wed, 18 Dec 2019 21:07:10 +0000

Ole,

I have reviewed version-02 of this document and believe that it still has the following major issues:

- Section 3.1.1 assumes implementation details (e.g., that the implementation has an OAM process) but fails to describe any externally observable behavior. The externally observable behaviors are described, incompletely, in Sections 4.1.2 and 4.2.2.

- Section 3.5 seems to be incomplete. What TLV are we talking about and what role does it play?

- Section 4 talks about future revisions of this document. Aren't we in WGLC?

- Section 4.1.2.1 - When the ping succeeds, what does the success message look like? An ICMP Echo Response? What is the source address? A SID?

- Section 4.1.2.2 - Does this work with PSP?

- Section 4.2.2.1 - Do we need to examine flags even when SL == 0?

                                                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: Wednesday, December 4, 2019 3:53 PM
To: 6man WG <[email-masked]>; SPRING WG <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Subject: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hello,

                         
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-22No-zDm$ 

as a Proposed Standard.  

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.

Thanks,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-2-1yR5ZL$
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 18 Dec 2019 22:28:15 +0100

Hi Ron,

Thank you, the last call for this document will stay open until the issues raised are closed.
Currently we are awaiting a new revision from the authors. I expect a few more rounds on this one.

Best regards,
Ole

> On 18 Dec 2019, at 22:07, Ron Bonica <[email-masked]> wrote:
> 
> Ole,
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 19 Dec 2019 00:01:16 +0000

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" <[email-masked]>
Date: Thursday, December 5, 2019 at 10:01 PM
To: "Zafar Ali (zali)" <[email-masked]>, 6man WG <[email-masked]>, SPRING WG <[email-masked]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Thanks

Regards … Zafar

*From: *ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of "Joel M. Halpern"
<[email-masked]<mailto:[email-masked]>>
*Date: *Wednesday, December 4, 2019 at 4:37 PM
*To: *Ole Troan <[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>,
SPRING WG <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Yours,

Joel

    Hello,

         As agreed in the working group session in Singapore, this
    message starts a new two week 6MAN Working Group Last Call on
advancing:

         Pages    : 23

         Date     : 2019-11-20

    as a Proposed Standard.

    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

    The last call will be forwarded to the spring working group, with
    discussion directed to the ipv6 list.

    Thanks,

    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 19 Dec 2019 00:19:40 +0000

Hi Greg,

Many thanks for your detailed comments. Much appreciated.

Please see comments in-line and how the new version addresses your comments.
I also look forward to our offline discussion on Friday.

Please note we have been also maintaining the latest version of the draft in the 6man-Github.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Thursday, December 5, 2019 at 5:22 PM
To: Ole Troan <[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man WG <[email-masked]>, 6man Chairs <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Dear Authors, et al.,
please find my comments, as WG LC comments, questions to this document below.

  *   The Abstract and Introduction describe the document as "defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6)". I believe it would be helpful to demonstrate that the existing mechanisms used in IPv6 to demultiplex and realize OAM functions, e.g., using the well-known destination UDP port number, are not sufficient and require the introduction of new methods, e.g., O bit in SRH.
[ZA] If you look at section 4 of the draft, it explains how existing probing mechanisms are used and why extensions are needed. In the new revision posted, we have added additional information on why the O-bit in SRH is defined (for telemetry purpose). Please have a look at the latest revision as we have tried to address your comment.

  *   This document introduces the O-flag into SRH as the building block for OAM in SR networks with IPv6 data plane. It appears that the functions that are realized using the O-flag are already supported by the existing OAM protocols that enable fault management (e.g., variations of Echo Request/Reply, BFD) and performance monitoring (e.g., STAMP).
[ZA] The O-bit is for telemetry use. In the new revision posted, we have added additional normative text on O-bit processing to clarify this point.  Please have a look at the latest revision.

  *   Also, the use of the new "building block for OAM" in SRv6 splits the SR OAM suit into two functionally separate toolsets - one for SR-MPLS and another for SRv6.
[ZA] SRv6 uses IPv6 data plane and hence applicability of the IPv6 OAM tools is discussed.

  *   The document defines the support of O-flag as OPTIONAL. In that case, what is the benefit of advertising the support of O-flag by an SR node (even though the advertisement itself is optional)?
[ZA] To let the other nodes/ controller know if the O-bit is supported by a local node.

  *   The document uses the term "accurate timestamp" without the discussion or definition of what level of accuracy is required or expected, methods to acquire an accurate timestamp, format(s) that must or may be used to record a timestamp, and what are possible implications of not providing an accurate timestamp.
[ZA] We have addressed this comment by replacing “accurate” with “a”. It is really up to the local implementation and draft does not add any requirements.

  *   The document asserts that to support "Many scenarios require punting of SRv6 OAM packets at the desired nodes in the network" can be done only with using OAM Endpoint with Punt function. I believe that TTL/Hop Count Expired had been used successfully to achieve the same result.
[ZA] Yes, and tracerouting is done using TTL/ HC. Please see section 4.

  *   what is the apparent need to introduce functional duplication to already existing OAM technique?  How a packet would be processed if both O-flag and the OAM SID End.OP are present (the specification only recommends setting O-flag to 0 when End.OP SID is present)?
[ZA] Good point. The restriction really does not exist and the new version corrects the text.

  *   Section 3.4 introduces function OAM Endpoint with Timestamp and Punt. At the same time, processing the O-flag, defined, as:
            a. Make a copy of the packet.
            b. Send the copied packet, along with an accurate timestamp
Is the difference in making or not making a local copy significant enough to have two mechanisms to achieve essentially the same result? How a packet will be processed if both O-flag and the OAM SID End.OTP are present (the specification only recommends to set O-flag to 0 when END.OTP SID is present) ?

[ZA] Good point. The restriction really does not exist and the new version corrects the text.

  *   Section 3.5 states that:
   SRH TLV plays an important role in carrying OAM and Performance
   Management (PM) metadata.
I cannot find any other text that illustrates how SRH TLV plays any role in FM and/or PM OAM.

[ZA] Indeed, the current draft does not define any TLV for OAM purposes. However, section was added as future drafts may define OAM TLVs.
However, based on your comments, the section has been removed in the new revision.

  *   It is stated in Section 4:
   This section describes how OAM mechanisms can be implemented using
   the OAM building blocks described in the previous section.
As this is the Standard document, using the normative language would be very much desirable. Then it would be clearer whether the use of not only O-flag but of OAM SIDs as well is optional or mandatory.

[ZA] Based on your comment, modified the text in the document to add normative language. Specifically:
o    In the new revision, we have added normative text at the beginning of 3.1.1 where O-bit is defined.
o    Sections 3.3 and 3.4 adds normative texts for OAM SIDs.
o    4.1.2 and 4.2.2 further adds additional normative text for Ping and traceroute use-cases, respectively.

  *   I've noticed that functions used as an example in the document are all part of active OAM functions. At the same time, the defined processing of the O-flag is very much similar to the operation of in-situ OAM. But I don't find any reference to in-situ OAM mechanism, nor discussion of whether both can be used in combination or are mutually exclusive.
[ZA] Based on your comment, we have removed the relevant section.

  *   In Section 4.1.2 the identification of an OAM (active OAM or some other kind of OAM) packet defined as:
   The OAM packets are identified either by setting the O-flag in SRH or
   by inserting the END.OP/ END.OTP SIDs at an appropriate place in the
   SRH.
Is the use of any of these methods required for any OAM? If that is the case, then the normative language must be used. Also, is it required to use any of these methods for, for example, BFD control packets or STAMP test packets? Isn't using assigned by IANA port number sufficient to identify active IP OAM packets? Wouldn't the same be applicable in SRv6 OAM?

[ZA] Normative language has been added to address your comment. 4.1.2 and 4.2.2 further adds additional normative text for Ping and traceroute use-cases, respectively.

  *   I have a question on how a local node selects an application that is to receive a punted packet (whether marked by O-flag that includes one of OAM SIDs)? The document provides examples where the destination is either ICMPv6 or a traceroute (?) process. Is that an exhaustive list?
[ZA] The list is not exhaustive. Furthermore, O-bit is for telemetry use

I greatly appreciate your kind consideration and am looking forward to the productive discussion.

[ZA] Likewise, many thanks for your comments.

Thanks

Regards … Zafar

Regards,
Greg

On Wed, Dec 4, 2019 at 3:53 PM Ole Troan <otroan@employees..org<mailto:[email-masked]>> wrote:
Hello,

  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

as a Proposed Standard.

Thanks,

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 18 Dec 2019 19:29:01 -0500

Zafar, thank you for taking steps to address my concerns.  There seem to 
be several issues remaining.  I am not sure I spotted them all, as the 
ones I see may be masking other issues.

[Side note to the chairs:  I have no idea how to enter a general 
discussion of this sort as a pull request.  I do not understand the 
desired behavior well enough to propose specific text.]

First, the draft still has as its focus "punt to the control processor". 
  But "Punt to the control process" is not an external observable.  It 
is not a subject for standardization.  What needs to be standardized is 
the behavior to be applied to the packet, not who applies it.  Heck, if 
someone implements all this logic in their fast path (or if they have 
only one path and therefore can not punt anywhere) it should still be 
possible to conform to whatever RFC we agree to for OAM processing.

Second, there appears to be no description of any case where the O bit 
is used.  All of the examples seem to use the END.OP and END.OTP 
processing instructions.  Since the O_bit definition is clear that the 
upper layer protocol is NOT to be processed, what is the processing to 
be performed when the O bit is set?

Related to the above, given that the O-bit definition and the END.OP / 
END.OTP both over-write the S01 step, what is to happen if both are true?

Minor:
     I presume that both over-writes for the S01 step of the SRH are 
intended to retain the base document "When an SRH is processed" text? 
If so, given that they say they replace that step, the caveat needs to 
be included.

    It looks like one side-effect of END.OP is that once could actually 
establish communication (TCP or UDP) with a node by addressing it at its 
END.OP SID?  (Presumably from another node inside the SR Domain?)

     Also, it looks like END.OP and END.OTP both cause termination of 
the SID processing.  I believe it would be helpful to be more explicit 
about this.

Yours,
Joel

On 12/18/2019 7:01 PM, Zafar Ali (zali) wrote:
> 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" <[email-masked]>
> *Date: *Thursday, December 5, 2019 at 10:01 PM
> *To: *"Zafar Ali (zali)" <[email-masked]>, 6man WG <[email-masked]>, 
>         *From: *ipv6 <[email-masked]
>         <mailto:[email-masked]>> on behalf of "Joel M. Halpern"
> 
>         <[email-masked] <mailto:[email-masked]>>
> 
>         *To: *Ole Troan <[email-masked]
>         <mailto:[email-masked]>>, 6man WG <[email-masked]
>         <mailto:[email-masked]>>,
> 
>         SPRING WG <[email-masked] <mailto:[email-masked]>>
> 
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
>              Administrative Requests:
>         https://www.ietf.org/mailman/listinfo/ipv6
> 
>             
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 19 Dec 2019 00:32:40 +0000

Hi Zhenqiang,

Many thanks for your comments.
We have been maintaining the latest version of the draft in the Github to address all comments.
However, we just posted revision 3.

Add editorial comments has been fixed.
For non-editorial comments, please see in-line.

Thanks

Regards … Zafar

From: spring <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday, December 6, 2019 at 3:14 AM
To: Ole Troan <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 6man Chairs <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hello Ole and all,

2. Requirements Language

3. Section 3.5 SRH TLV

[ZA] Indeed, the current draft does not define any TLV for OAM purposes. However, section was added as future drafts may define OAM TLVs. However, based on your comments, the section has been removed in the new revision.

[ZA] It is a use case.

[ZA] Fixed the Section 2.1 Abbreviations. However, please note that the draft consistently mentions the RFC4443. Furthermore, the RFC4884 is equally applicable.

[ZA] No the section does not extend the ICMPv6. Inclusion is useful for the reader of the draft (for completeness). However, based on your comment we have removed the section.

Thanks

Regards … Zafar

<snip>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Dec 2019 19:45:19 -0500

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Dec 2019 10:56:14 +0100

Hi Joel,

> 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 <[email-masked]> wrote:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Dec 2019 06:49:23 -0800

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 <[email-masked]> wrote:

> 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.
>
>
>> > We have been maintaining the latest version of the draft in the Github..
>> >
>> >         <[email-masked] <jmh@joelhalpern..com> <mailto:
>> [email-masked]>>
>> >

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 19 Dec 2019 09:57:34 -0500

Hi Greg, Joel,

FYI, END.OTP is used with TWAMP Light (RFC 5357) (and STAMP) in
draft-gandhi-spring-twamp-srpm and 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 <[email-masked]> wrote:

>>> > 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:
>>> >
>>> >         Can you please point to specific text in the draft for which
>>> the
>>> >         draft
>>> >
>>> >         <[email-masked] <jmh@joelhalpern...com> <mailto:
>>> [email-masked]>>
>>> >
>>> >                   Title    : Operations, Administration, and
>>> Maintenance
>>> >         (OAM) in
>>> >
>>> >              To improve document quality and ensure that bugs are
>>> caught
>>> >         as early
>>> >

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Dec 2019 07:04:15 -0800

Hi Rakesh,
thank you for pointing to this interesting proposal. But, as I understand
RFC 5357 and Appendix I, timestamp collection is already part of the TWAMP.
Why there's the need to duplicate what is being documented in RFC 5357?

Regards,
Greg

On Thu, Dec 19, 2019 at 6:57 AM Rakesh Gandhi <[email-masked]>
wrote:

>>> 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.
>>>
>>>> >   * 4.1.2 and 4.2.2 further adds additional normative text for Ping
>>>> and
>>>> >     traceroute use-cases, respectively.
>>>> >
>>>> >     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
>>>> >
>>>> >     Note that in most OAM, we define the behavior that is required,
>>>> and
>>>> >     then
>>>> >
>>>> >         needs to define normative behavior for the "node punt
>>>> processor
>>>> >         look
>>>> >
>>>> >              Editorial suggestions can be sent to the author. This
>>>> last
>>>> >         call will
>>>> >

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 19 Dec 2019 16:06:39 +0100

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 <[email-masked]> wrote:

>>> Github..

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Dec 2019 07:20:02 -0800

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Dec 2019 10:21:36 -0500

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:
> draft-gandhi-spring-twamp-srpmand RFC 6374 in 
> On Thu, Dec 19, 2019 at 9:49 AM Greg Mirsky <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Robert,
>     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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         Hi Joel,
> 
>         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:
>         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
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>              > 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.
>              >   * 4.1.2 and 4.2.2 further adds additional normative
>             text for Ping and
>              > *From: *"Joel M. Halpern" <[email-masked]
>             <mailto:[email-masked]>>
>              > *To: *"Zafar Ali (zali)" <[email-masked]
>             <mailto:[email-masked]>>, 6man WG <[email-masked]
>             <mailto:[email-masked]>>,
>              >     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
>              >
>              >     the control process is to do with the packet.  And
>             particularly
>              >     since in
>              >
>              >     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
>              >
>              >         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
>              >
>             <mailto:[email-masked]>
>              >         <mailto:[email-masked]
>             <mailto:[email-masked]>>> on behalf of "Joel M. Halpern"
>              >
>              >         <[email-masked]
>             <mailto:jmh@joelhalpern...com> <mailto:[email-masked]
>             <mailto:[email-masked]>>>
>              >
>             <mailto:[email-masked]>
>              >         <mailto:[email-masked]
>             <mailto:[email-masked]>>>, 6man WG <[email-masked]
>             <mailto:[email-masked]>
>              >         <mailto:[email-masked] <mailto:[email-masked]>>>,
>              >
>              >         SPRING WG <[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>>
>              >
>              >         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
>              >
>              >         behavior requires that the node "punt processor"
>             look past the
>              >         SRH and
>              >
>              >         make determinations based on the content.  This
>             needs to be
>              >         described
>              >
>              >                   Title    : Operations, Administration,
>             and Maintenance
>              >         (OAM) in
>              >
>              >                   Author   : Z. Ali, C. Filsfils, S.
>             Matsushima, D.
>              >         Voyer, M. Chen
>              >
>              >                   Filename :
>              >              Substantive comments and statements of
>             support for
>              >         publishing this
>              >
>              >              Editorial suggestions can be sent to the
>             author. This last
>              >         call will
>              >
>              >              To improve document quality and ensure that
>             bugs are caught
>              >         as early
>              >
>              >              The last call will be forwarded to the
>             spring working
>              >         group, with
>              >
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >
>              >              Administrative Requests:
>             <mailto:[email-masked] <mailto:[email-masked]>>
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >
>              >         Administrative Requests:
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >
>              >     Administrative Requests:
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 19 Dec 2019 17:27:47 +0000

Hi Greg,

The END.OTP SID is NOT defined or to be used for in-situ OAM.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Thursday, December 19, 2019 at 10:21 AM
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> - END.OTP

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 <[email-masked]<mailto:robert@raszuk..net>> wrote:
Hi Greg,

Nope not at all.

   Geneve, IPv6, or IPv4.  Specification details for these different

   transport protocols are outside the scope of this document.

Thx

R.

On Thu, Dec 19, 2019 at 3:49 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel,

>  However, there is no defined behavior that I know of that can make use

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 <[email-masked]<mailto:[email-masked]>> 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.

Yours,
Joel

On 12/18/2019 7:01 PM, Zafar Ali (zali) wrote:
> We have been maintaining the latest version of the draft in the Github...
>
> *From: *"Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
> *To: *"Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>,
>         *From: *ipv6 <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>> on behalf of "Joel M. Halpern"
>
>         <[email-masked]<mailto:jmh@joelhalpern...com> <mailto:[email-masked]<mailto:[email-masked]>>>
>
>         *To: *Ole Troan <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>>, 6man WG <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>>,
>
>         SPRING WG <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
>
>              Administrative Requests:
>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>

[email-masked]<mailto:[email-masked]>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Dec 2019 12:35:23 -0500

I am probably missing something.
As far as I can tell, the draft does not give any clue as to what the 
END.OTP behavior is to be used for.  Without such description, how is 
the reader to know that it is "NOT ... to be used for in-situ OAM."

Yours,
Joel

On 12/19/2019 12:27 PM, Zafar Ali (zali) wrote:
> *From: *ipv6 <[email-masked]> on behalf of Greg Mirsky 
> <[email-masked]>
> *Date: *Thursday, December 19, 2019 at 10:21 AM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *SPRING WG <[email-masked]>, 6man WG <[email-masked]>
> *Subject: *Re: [spring] 6man w.g. last call for 
> <draft-ietf-6man-spring-srv6-oam> - END.OTP
> 
> 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 
> 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
> 
>         Geneve, IPv6, or IPv4. * Specification details for these different*
> 
>     *   transport protocols are outside the scope of this document.*
> 
>         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
> 
>             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.
> 
>             there are real efforts and working code which goes beyond
>             that already in place. Example:
>             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.
> 
>                  > 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
>                  >     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
>                  >
>                  >     the control process is to do with the packet. 
>                 And particularly
>                  >     since in
>                  >
>                  >     Note that in most OAM, we define the behavior
>                 that is required, and
>                  >     then
>                  >
>                  >         needs to define normative behavior for the
>                 "node punt processor
>                  >         look
>                  >
>                 <mailto:jmh@joelhalpern...com>
>                 <mailto:[email-masked] <mailto:[email-masked]>>>
>                  >
>                  >         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
>                  >
>                  >         behavior requires that the node "punt
>                 processor" look past the
>                  >         SRH and
>                  >
>                  >         make determinations based on the
>                 content.  This needs to be
>                  >         described
>                  >
>                  >                   Title    : Operations,
>                 Administration, and Maintenance
>                  >         (OAM) in
>                  >
>                  >              To improve document quality and ensure
>                 that bugs are caught
>                  >         as early
>                  >

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Dec 2019 09:43:47 -0800

Hi Zafar,
thank you for your clarification, most helpful. If END.OTP is not intended
to be used in conjunction with iOAM in UIPv6, may I suggest to add a text
which will make that explicit. For example,

END.OTP MUST NOT be used in IPv6 packets that include iOAM. If END.OTP and
iOAM are both present in the IPv6 packet, END.OTP processing MUST be
skipped and only iOAM MUST be processed. An implementation MUST use
mechanisms, e.g., logging, to inform an operator of the conflict between
OAM functions.

Regards,
Greg

On Thu, Dec 19, 2019 at 9:27 AM Zafar Ali (zali) <[email-masked]> wrote:

> *From: *ipv6 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> 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>
> proposed END..OTP function.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Dec 19, 2019 at 7:06 AM Robert Raszuk <[email-masked]
> <robert@raszuk..net>> wrote:
>
> Hi Greg,
>
>
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 20 Dec 2019 15:46:10 +0000

Hi Greg, Joel,

We can add clarification text.

Happy Holidays!

Thanks

Regards … Zafar

From: Greg Mirsky <[email-masked]>
Date: Thursday, December 19, 2019 at 12:44 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, SPRING WG <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> - END.OTP

Hi Zafar,
thank you for your clarification, most helpful. If END.OTP is not intended to be used in conjunction with iOAM in UIPv6, may I suggest to add a text which will make that explicit. For example,
END.OTP MUST NOT be used in IPv6 packets that include iOAM. If END.OTP and iOAM are both present in the IPv6 packet, END.OTP processing MUST be skipped and only iOAM MUST be processed. An implementation MUST use mechanisms, e.g., logging, to inform an operator of the conflict between OAM functions.

Regards,
Greg

On Thu, Dec 19, 2019 at 9:27 AM Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks

Regards … Zafar

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 19, 2019 at 10:21 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>, 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam> - END.OTP

Hi Robert,

Regards,
Greg

Nope not at all.

Thx

R.

Regards,
Greg

Thx,
r.

Yours,
Joel