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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 22 Feb 2020 01:06:57 +0000

Hi Greg,

I went back to your comments to verify the latest version in the GitHub addresses them (as marked by [ZA]).
This is with the exception of your question on handling of BFD control packets or STAMP test packets. Please see [ZA2] for the specifics.

One thing that stands out from your review comments is that we need a sub-section on the illustration on the use of O-bit. We are in the process of adding the O-bit usage illustration. Please see [ZA2] for more details.

Many thanks for taking an offline call, earlier. I will reach-out to you again to discuss your comments.

Thanks

Regards … Zafar

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wednesday, December 18, 2019 at 7:19 PM
To: Greg Mirsky <[email-masked]>, Ole Troan <[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man WG <[email-masked]>, 6man Chairs <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

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.
[ZA2] We are adding illustration on the use of the o-bit.
[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).
[ZA2] We are adding illustration on the use of the o-bit.
[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. The 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?

[ZA2] You are right that IANA assigned port number should be sufficient to identify active OAM packets. In order to process the OAM packets targeted to a SID, based on a local configuration, the net-pgm needs to allow processing of the OAM packets. What we need is a clarification in the net-pgm draft for the Upper Layer Processing. I’ve added NET-PGM editors (Spring is already CC’ed) to request this change.

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

  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
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 22 Feb 2020 20:13:56 -0800

Hi Zafar,
thank you for the update. I appreciate the efforts of all authors
addressing my comments. I'll carefully read and review the new version and
will share my comments as soon as possible.

Regards,
Greg

On Fri, Feb 21, 2020 at 5:07 PM Zafar Ali (zali) <[email-masked]> wrote:

> This is with the exception of your question on handling of BFD control
> packets or STAMP test packets. Please see [ZA2] for the specifics.
>
>
>
> One thing that stands out from your review comments is that we need a
> sub-section on the illustration on the use of O-bit. We are in the process
> of adding the O-bit usage illustration. Please see [ZA2] for more details.
>
>
>
> *From: *"Zafar Ali (zali)" <[email-masked]>
> *Date: *Wednesday, December 18, 2019 at 7:19 PM
> *To: *Greg Mirsky <[email-masked]>, Ole Troan <[email-masked]
> >
> *Cc: *SPRING WG <[email-masked]>, 6man WG <[email-masked]>, 6man Chairs <
> [email-masked]>, "Zafar Ali (zali)" <[email-masked]>
> *Subject: *Re: [spring] 6man w.g. last call for
> <draft-ietf-6man-spring-srv6-oam>
>
>
>
> Hi Greg,
>
>
>
> *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.,
>
>    - 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.
>
>    - 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.
>
> [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.
>
>    - 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:
>
> 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:
>
> [ZA] Indeed, the current draft does not define any TLV for OAM purposes.
> The section was added as future drafts may define OAM TLVs.
>
>    - It is stated in Section 4:
>
> 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:
>
> 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?
>
>
>
> [ZA2] You are right that IANA assigned port number should be sufficient to
> identify active OAM packets. In order to process the OAM packets targeted
> to a SID, based on a local configuration, the net-pgm needs to allow
> processing of the OAM packets. What we need is a clarification in the
> net-pgm draft for the Upper Layer Processing. I’ve added NET-PGM editors
> (Spring is already CC’ed) to request this change.
>
>
>
> [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?
>
> On Wed, Dec 4, 2019 at 3:53 PM Ole Troan <otroan@employees..org
> <[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.
>
> [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Feb 2020 18:11:47 +0800

Zafar, authors,

I think most of what you done is fine. There are still somr things
to do, e.g. align with 7322, rewrite the Abstract and work with the
authors of draft-ietf-6man-segment-routing-header to make their IANA 
considerations are correct from your point of view.

Then this

       The IPv6 address of the nth Link  between node X and Y at the X
       side is represented as 2001:DB8:X:Y:Xn::, e.g., the IPv6 address
       of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is
       link between N3 and N4) at node 3 is 2001:DB8:3:4:31::.

I'd like to drill down a bit more on this paragraph.

In the generic example "Xn" represents the n-th link between node
x and Y, right? And you need the first "X" in "X:Y:Xn" to identify
the node?

SInce the first X uniquely identify the node, why is X needed in
the second field.

In a specific case the 11th lik of node 3 and the 1st link of
node 31 would bive the same result - "311". You disambiguate by the
node number of the first "X".

So for the eleventh link of nod 3 to node y:

3:y:311

And for the first link of node 31 to node y:

31:y:311

Right?

So why should not 3:y:11 and 31:y:1 work.

/Loa

On 21/02/2020 13:41, Zafar Ali (zali) wrote:
> Hi Loa,
> 
> We have addressed most of your comments in the enclosed .txt file.
> 
> We have also uploaded updated XML file to the 6man/OAM repository (but 
> please use the enclosed .txt file for diffs. Somehow “Compare Editor's 
> Copy to Working Group Draft” is pointing to older diffs.
> 
> Details of how your comments are addressed are listed in the following 
> as well as in the enclosed updated diffs file that you shared earlier.
> 
> We plan to address the remaining comments very soon.
> 
> Many thanks again for detailed review.
> 
> Thanks
> 
> Regards … Zafar
> 
> *How comments were addressed*:
> 
> [LA1]The Abstract seems to be a bit ìbareî, it should be a stand-alone 
> text, this seem to pre-suppose an high level of familiarity with the topic.
> 
> [ZA] rewrite TBD.
> 
> [LA2]Dataplane or data pale,  us one both not both.
> 
> [ZA] Changed.
> 
> [LA3]îsomeî, this begs for an explanation of what has been left out and why.
> 
> [LA4]There is an RFC 7322, please make sure that you are following these 
> guidelines.
> 
> S for the placement of the ìRequirement Languageî, the style guide says 
> that it should be placed as a top level section after the Introduction, 
> however not even the RFC Editor follow that guidance, the Requirement 
> Language are most often placed as a subsection of the introduction.
> 
> [ZA] Changed the text to follow the RFC7322 guideline.
> 
> [LA5]There is a new template for this, BCP BCP 14 which consists of twp 
> RFCs ([RFC2119] [RFC8174]) should be referenced.
> 
> [ZA] Reference to [RFC8174] added.
> 
> [LA6]Thos is very sparse, and it is also a direct copy og the abstract 
> (or the other way around). I donít think this is allowed.
> 
> [ZA] rewrite TBD.
> 
> [LA7]I think you could remove this header and make îAbbreviationsî 
> section 1.1
> 
> [ZA] Fixed.
> 
> [LA8]RFC 8402 define this is as îSegemetns Leftî
> 
> [ZA] Good catch! Fixed.
> 
> [LA9]Also this document uses îSegments Leftî
> 
> [ZA] Fixed.
> 
> [LA10]Admittedly the topology is simple, but the figure could be much 
> clearer.
> 
> I agree that it is a good idea to define a simple topology and use it 
> throughout the document.
> 
> [ZA] Thanks. Any suggestion to simplify is welcomed.
> 
> [LA11]This could be a good place to explain the use of înode kî.
> 
> [ZA] Moved.
> 
> [LA12]Probably not a very strong point, ìclassicî is already a bit 
> ambivalent, and will be more so as the time goes by. Iíd say just drop 
> it, or make it ìnon-SRv6 IPv6 nodesî.
> 
> [ZA] Fixed.
> 
> [LA13]îNode kî is not in the reference topology.
> 
> [ZA] Node k is used to refer to all nodes collectively (e.g., to define 
> the IPv6 addressing scheme for them.). IMO this should be fine.
> 
> [LA14]If you are going to push the link number into the IPv6 address, it 
> would be better to start numbering from zero.
> 
> [ZA] There is no node 0 in the topology. The addressing example is based 
> on node names. IMO this should be fine.
> 
> [LA15]This three is redundant, the î3:4î in the two previous positions 
> uniquely identify the link,
> 
> [ZA] Actually it is not redundant as the last :3 represents the link 
> address at node 3 side. IMO this should be fine.
> 
> [LA16]After going through this a number of time Iím convinced that this 
> is correct. However, it takes quite an effort to go through a rather 
> cryptic text. Is it possible to clarify.
> 
> [ZA] Thanks for your feedback. Actually there was a typo and I fixed it.
> 
> [LA17]This îS1î means îSID1î, why do we need the ìSî as a special 
> notation when we already have ìSIDî
> 
> [ZA] Si is a notation that relates to a topology or service segment. 
> S[j] represents the SID pointed by the SL field in the SRH. S[j] is like 
> a index in sid-list in the SRH. IMO this should be fine.
> 
> [LA18]When we were specifying MPLS-TP we diid a lot of OAM work, 
> concepts like MIPs and MEPs were introduced. Do these concepts have any 
> bearing on SRv6 OAM?
> 
> [ZA] Thanks for your feedback. SRv6 OAM is in-line with OAM in IPv6 
> networks, which are not of transport nature.
> 
> [LA19]This is a double reference to the same document and strictly note 
> necessary The format of the second reference is also wrong and does not 
> appear in the reference list.
> 
> [ZA] Fixed.
> 
> [LA20]Well, if you do you need a subsection in the IANA Consideration. 
> The flag field is defined in ietf-6man-segment-routing-header, but it is 
> still a draft.
> 
> As this document stands now you canít find the IANA allocations. Partly 
> depending on that IANA not yet done the allocations, but also because if 
> they were done there is no clear reference to the registry. SRH.Flags is 
> not the name of the registry.
> 
> [ZA] Fixed.
> 
> [LA21]The notation îSRH.Flagsî is invented here, right?  
> draft-ietf-6man-segment-routing-header, and the SRV6 Networking 
> programming draft (which is referenced for terminology) simply talks 
> about SRH or ìSRH Flagsî.
> 
> [ZA] The SRH.Flags is defined in draft-ietf-6man-segment-routing-header. 
> The IANA registry for SRH.Flags is requested in 
> draft-ietf-6man-segment-routing-header. This document just defined a 
> flag to identify OAM packets.
> 
> [LA22]Why start with bit 2, why not 0 or 7?
> 
> [ZA] There is a long history. This O-flag flag were originally defined 
> in the
> 
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-11.
> 
> During the LC review, it was moved to OAM draft. But the position has 
> been already defined and used by the ASICs. Hence, keeping the same bit 
> position.
> 
> [LA23]We are allocating a flag from a registry defined in 
> draft-ietf-6man-segment- routing-header. Since this is still in IESG 
> review it will not be possible progress this document until the routing 
> header document is in the RFC Editors queue, and it canít become an RFC 
> until the document defining the registry is also an RFC.
> 
> I think the SRH flags registry should be properly named here, "Segment 
> Routing Header Flags"
> 
> [ZA] Yes, the SRH flags registry is named as "Segment Routing Header 
> Flags". Please see IANA section in the new revision.
> 
> [LA24]I think the should be either OAM, Operation Administration and 
> Maintenance; or O&M, OAM and Management.
> 
> See RFC 6291.
> 
> [ZA] Fixed.
> 
> [LA25]Note: Chapter 3 is well written and easy to understand
> 
> [ZA] Will fix it - TBD.
> 
> [LA26]Comment added after reading the entire section, the procedures and 
> mechanisms described is as far as I can judge well and clearly documented.
> 
> [ZA] Thanks.
> 
> [LA27]An Extreme nit, but I would call this îPing in SRv6 Networksî
> 
> [ZA] Fixed
> 
> [LA28]I said it before ñ I donít like ìClassicî, and I donít thnk it is 
> necessary or contribute significantly.
> 
> [ZA] We will think about renaming. TBD.
> 
> [LA29]I think this procedures is well and clearly documented.
> 
> [ZA] Thanks.
> 
> [LA30]As far as I can see this works.
> 
> [ZA] Thanks.
> 
> [LA31]We might want a reference.
> 
> [ZA] This should be fine as this is well know.
> 
> [LA32]At this point I start think of SRv6 as îconnection oriented.
> 
> [ZA] SRv6 enables source routing.
> 
> [LA33]I see no immediate technical problems here.
> 
> [ZA] Thanks
> 
> [LA34]I defer to the security experts on this section.
> 
> [ZA] Yes that is part of the review process.
> 
> [LA35]You need text in this section describing the allocation of the O-flag.
> 
> [ZA] Fixed.
> 
> [LA36]What are the registration procedures???
> 
> If I understand correctly we want to take one of the unused ICMPv6 Type 
> Numbers and create the ìICMP Type Numbers ñ SRv6 OAM messagesî registry.
> 
> But with all due respect the text is a bit tangled.
> 
> [ZA] Fixed the text. Thanks for the good catch.
> 
> [LA37]This allocation is in itself not problematic, but the registries 
> are not yet in place., weíll have to wait for the network programming 
> draft to progress.
> 
> [ZA] Agreed!
> 
> Thanks
> 
> Regards … Zafar
> 
> *Date: *Thursday, February 20, 2020 at 12:30 PM
> *To: *Loa Andersson <[email-masked]>, Brian E Carpenter 
> <[email-masked]>, Ole Troan <[email-masked]>, 6man WG 
> <[email-masked]>, SPRING WG <[email-masked]>
> *Cc: *6man Chairs <[email-masked]>, "Zafar Ali (zali)" 
> <[email-masked]>
> Hi Loa,
> Sorry, I could not get back to your other comments, earlier.
> 
> I am starting to look into all outstanding comments.
> 
> It will be great if you could send me copy of the word document diffs 
> (privately).
> 
> But either way, your comments are quite clear.
> 
> Many Thanks
> 
> Regards … Zafar
> 
> *Date: *Thursday, January 23, 2020 at 6:46 PM
> *To: *Loa Andersson <[email-masked]>, Brian E Carpenter 
> <[email-masked]>, Ole Troan <[email-masked]>, 6man WG 
> <[email-masked]>, SPRING WG <[email-masked]>
> *Cc: *6man Chairs <[email-masked]>, "Zafar Ali (zali)" 
> <[email-masked]>
> Loa,
> Many thanks.
> The comments in your email has been addressed in latest version in the 
> GitHub.
> 
> We are working to address the rest of your comments.
> 
> Thanks
> 
> Regards … Zafar
> 
> *From: *Loa Andersson <[email-masked]>
> *Date: *Wednesday, January 22, 2020 at 5:03 AM
> *To: *"Zafar Ali (zali)" <[email-masked]>, Brian E Carpenter 
> <[email-masked]>, Ole Troan <[email-masked]>, 6man WG 
> <[email-masked]>, SPRING WG <[email-masked]>
> *Cc: *6man Chairs <[email-masked]>
> Zafar,
> Tnx - 1 down 36 to go!
> Actually a bit more with the NITs output. Can you take a look at the
> 
> long lines next, it should be easy edits.
> 
> The first two long lines are in this paragraph:
> 
> 248     S01.1. IF SRH.Flags.O-flag is set and local configuration permits
> 
> 249            O-flag processing THEN
> 
> 250            a. Make a copy of the packet.
> 
> 251            b. Send the copied packet, along with a timestamp
> 
> 252               to the OAM process.      ;; Ref1
> 
> 253     Ref1: An implementation SHOULD copy and record the timestamp as
> 
> soon as
> 
> 254     possible during packet processing. Timestamp is not carried in
> 
> the packet
> 
> 255     forwarded to the next hop.
> 
> Line 253 has four characters "n as" outside the allowed 72 characters
> 
> Line 254 has the word "packet" outside the allowed 72 characters
> 
> This is inside the figure and I think that you can left shift the
> 
> enire figure, otherwise I don't see a problem with introducing line
> 
> breaks.
> 
> In figure 4:
> 
> 639     > traceroute srv6 B:4:C52 via segment-list B:2:C31
> 
> 641     Tracing the route to SID function B:4:C52
> 
> 642      1  2001:DB8:1:2:21 0.512 msec 0.425 msec 0.374 msec
> 
> 643         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=2)
> 
> 644      2  2001:DB8:2:3:31 0.721 msec 0.810 msec 0.795 msec
> 
> 645         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
> 
> 646      3  2001:DB8:3:4::41 0.921 msec 0.816 msec 0.759 msec
> 
> 647         SRH: (B:4:C52, B:4:OTP, B:2:C31; SL=1)
> 
> 649        Figure 4 A sample output for hop-by-hop traceroute to a SID
> 
> function
> 
> Line 649 has "tion" of "SID function" (fig numbring) outside the allowed
> 
> 72 characters, again should be easy to left shif or introduce line
> 
> breaks.
> 
> The reason I want to address this first is that it is easy, but also
> 
> a show stopper.
> 
> And last, thugh I hate to add late comments - abbreviations, I have not
> 
> gone through the entire document to look for unexpanded abbreviations,
> 
> but there is at least one "NPU". Which I read as Network Processing Unit,
> 
> what confuses me is that it is not in the RFC Editors abbreviation list
> 
> at all. I think there is an action point for the wg chairs to have it
> 
> introduced, and for the authros to expand, as well as going through the
> 
> document an d make sure that everthing that should be expanded is.
> 
> /Loa
> 
> On 22/01/2020 13:15, Zafar Ali (zali) wrote:
> 
>     Hi Loa,
> 
>     Many thanks for your follow-up.
> 
>     Based on your feedback, we have updated the version in the GitHub.
> 
>     Thanks
> 
>     Regards … Zafar
> 
>     *From: *Loa Andersson <[email-masked] <mailto:[email-masked]>>
> 
>     *Date: *Tuesday, January 21, 2020 at 9:59 PM
> 
>     *To: *"Zafar Ali (zali)" <[email-masked] <mailto:[email-masked]>>,
>     Brian E Carpenter
> 
>     <[email-masked] <mailto:[email-masked]>>,
>     Ole Troan <[email-masked] <mailto:[email-masked]>>, 6man WG
> 
>     <[email-masked] <mailto:[email-masked]>>, SPRING WG <[email-masked]
>     <mailto:[email-masked]>>
> 
>     *Cc: *6man Chairs <[email-masked] <mailto:[email-masked]>>
> 
>     Zafar,
>     Thanks for addressing this. However one thing remains. The text is now:
> 
>     "There MAY be additional segments preceding the END.OP/ END.OTP SID."
> 
>     I don't think there is a need for requirement language in that sentence,
> 
>     I read it as straightforward English:
> 
>     "There may be additional segments preceding the END.OP/ END.OTP SID."
> 
>     Would do very well.
> 
>     Can you explain the need for requirement language?
> 
>     /Loa
> 
>     On 22/01/2020 01:55, Zafar Ali (zali) wrote:
> 
>           Hi Brian,
> 
>           Many thanks for your comments. Much appreciated.
> 
>           The working copy of the new version in the repository
>     addresses your/
> 
>           Loa’s comment highlighted in your email.
> 
>     https://github.com/ietf-6man/srv6-oam
> 
>           Thanks
> 
>           Regards … Zafar
> 
>           *From: *spring <[email-masked]
>     <mailto:[email-masked]>
> 
>           <mailto:[email-masked]>
>     <mailto:[email-masked]%3e>> on behalf of Brian E Carpenter
> 
>           <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]%3e>>
> 
>           *Organization: *University of Auckland
> 
>           *Date: *Monday, January 20, 2020 at 2:57 PM
> 
>           *To: *Loa Andersson <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]> <mailto:[email-masked]%3e>>, Ole Troan
> 
>           <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]> <mailto:[email-masked]%3e>>, 6man
> 
>           WG <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]> <mailto:[email-masked]%3e>>, SPRING WG
> 
>           <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]> <mailto:[email-masked]%3e>>
> 
>           *Cc: *6man Chairs <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]>
>     <mailto:[email-masked]%3e>>
> 
>           To be clear about one of the points in the review, MAY NOT is not
> 
>           allowed by RFC2119 because it is totally ambiguous in English
>     (since it
> 
>           can mean either "must not" or "might not"). In any case the
>     phrase "MAY
> 
>           or MAY NOT" is not of any normative value. It presumably
>     simply means
> 
>           "MAY" in all cases in this draft.
> 
>           Regards
> 
>                 Brian
> 
>           On 20-Jan-20 20:54, Loa Andersson wrote:
> 
>                 WG,
> 
>                 I have reviewed the entire document.
> 
>                 First, I'm not an IPv6 expert.
> 
>                 As far as I can see the sued on
> 
>                 I have not used github, I had a couple of attempts to learn
> 
>           the tools,
> 
>                 but so far I have failed.
> 
>                 I have instead done what I use to do, use the review
>     tool with
> 
>           Word.
> 
>                 Since I sometimes have a pushback on the docx-format I save
> 
>           the result
> 
>                 as a .txt-file. Drawback is that all comment show up as
> 
>           refrences to a
> 
>                 list at the end of the document. But you can't get
>     everything.
> 
>                 /Loa
> 
>                 PS gives this output for this draft; it is quite a lot
>     and in
> 
>           itself are
> 
>                 so much that it is worth sending it bck to the authors and
> 
>           asking them
> 
>                 to fix it. Was the noits tool checked at all before starting
> 
>           the wglc?
> 
>                 idnits 2.16.02
> 
>                 /tmp/draft-ietf-6man-spring-srv6-oam-03.txt:
> 
>                      Checking boilerplate required by RFC 5378 and the IETF
> 
>           Trust (see
> 
>     https://trustee.ietf.org/license-info):
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         No issues found here.
> 
>                      Checking nits according to
> 
>     https://www.ietf.org/id-info/1id-guidelines.txt:
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         No issues found here.
> 
>                      Checking nits according to
> 
>     https://www.ietf.org/id-info/checklist :
> 
>          
>     ----------------------------------------------------------------------------
> 
>                      ** There are 3 instances of too long lines in the
> 
>           document, the
> 
>                 longest one
> 
>                         being 6 characters in excess of 72.
> 
>                      == There are 5 instances of lines with
> 
>           non-RFC3849-compliant IPv6
> 
>                 addresses
> 
>                         in the document.  If these are example
>     addresses, they
> 
>                 should be
> 
>                 changed.
> 
>                      Miscellaneous warnings:
> 
>          
>     ----------------------------------------------------------------------------
> 
>                      == The copyright year in the IETF Trust and authors
> 
>           Copyright Line
> 
>                 does not
> 
>                         match the current year
> 
>                      -- The exact meaning of the all-uppercase
>     expression 'MAY
> 
>           NOT'
> 
>                 is not
> 
>                         defined in RFC 2119.  If it is intended as a
>     requirements
> 
>                 expression, it
> 
>                         should be rewritten using one of the combinations
> 
>           defined in
> 
>                 RFC 2119;
> 
>                         otherwise it should not be all-uppercase.
> 
>                      == The expression 'MAY NOT', while looking like RFC
>     2119
> 
>                 requirements
> 
>                 text,
> 
>                         is not defined in RFC 2119, and should not be
> 
>           used.  Consider
> 
>                 using 'MUST
> 
>                         NOT' instead (if that is what you mean).
> 
>                         Found 'MAY NOT' in this paragraph:
> 
>                         To perform ICMPv6 ping to a target SID an echo
>     request
> 
>                 message is
> 
>                         generated by the initiator with the END.OP or
>     END.OTP
> 
>           SID in the
> 
>                         segment-list of the SRH immediately preceding the
> 
>           target SID.
> 
>                 There MAY
> 
>                         or MAY NOT be additional segments preceding the
>     END.OP/
> 
>                 END.OTP SID.
> 
>                      == The expression 'MAY NOT', while looking like RFC
>     2119
> 
>                 requirements
> 
>                 text,
> 
>                         is not defined in RFC 2119, and should not be
> 
>           used.  Consider
> 
>                 using 'MUST
> 
>                         NOT' instead (if that is what you mean).
> 
>                         Found 'MAY NOT' in this paragraph:
> 
>                         To traceroute a target SID a probe message is
> 
>           generated by the
> 
>                         initiator with the END.OP or END.OTP SID in the
> 
>           segment-list of
> 
>                 the SRH
> 
>                         immediately preceding the target SID.  There MAY or
> 
>           MAY NOT be
> 
>                 additional
> 
>                         segments preceding the END.OP/ END.OTP SID.
> 
>                      -- The document date (December 18, 2019) is 32 days
>     in the
> 
>                 past.  Is this
> 
>                         intentional?
> 
>                      Checking references for intended status: Proposed
>     Standard
> 
>          
>     ----------------------------------------------------------------------------
> 
>                         (See RFCs 3967 and 4897 for information about using
> 
>           normative
> 
>                 references
> 
>                         to lower-maturity documents in RFCs)
> 
>                      == Missing Reference: 'SL' is mentioned on line
>     190, but not
> 
>                 defined
> 
>                      -- Looks like a reference, but probably isn't: '2' on
> 
>           line 191
> 
>                      -- Looks like a reference, but probably isn't: '1' on
> 
>           line 191
> 
>                      -- Looks like a reference, but probably isn't: '0' on
> 
>           line 192
> 
>                      == Missing Reference: 'RFC7011' is mentioned on
>     line 230, but
> 
>                 not defined
> 
>                      == Missing Reference: 'I-D.ietf-idr-bgpls-srv6-ext' is
> 
>                 mentioned on line
> 
>                         241, but not defined
> 
>                      == Missing Reference: 'RFC792' is mentioned on line
>     701, but
> 
>                 not defined
> 
>                      == Missing Reference: 'RFC 8403' is mentioned on line
> 
>           660, but not
> 
>                 defined
> 
>                      == Unused Reference: 'RFC0792' is defined on line
>     823, but no
> 
>                 explicit
> 
>                         reference was found in the text
> 
>                      == Unused Reference: 'RFC8403' is defined on line
>     843, but no
> 
>                 explicit
> 
>                         reference was found in the text
> 
>                      == Outdated reference: A later version (-08) exists of
> 
>                         draft-ietf-spring-srv6-network-programming-06
> 
>                         Summary: 1 error (**), 0 flaws (~~), 12 warnings
>     (==), 5
> 
>                 comments
> 
>                 (--).
> 
>                         Run idnits with the --verbose option for more
>     detailed
> 
>                 information
> 
>                 about
> 
>                         the items above.
> 
>                 On 05/12/2019 04:53, 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
> 
>                     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,
> 
>     [email-masked] <mailto:[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]>
>     <mailto:[email-masked]>
> 
>                 Administrative Requests:
> 
>     https://www.ietf.org/mailman/listinfo/ipv6
> 
>          
>           _______________________________________________
> 
>           spring mailing list
> 
>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>     <mailto:[email-masked]>
> 
>     https://www.ietf.org/mailman/listinfo/spring
> 
>     -- 
> 
>     Loa Andersson                        email: [email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]>
> 
>     Senior MPLS Expert
> 
>     Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
>     _______________________________________________
> 
>     spring mailing list
> 
>     [email-masked] <mailto:[email-masked]>
> 
>     https://www.ietf.org/mailman/listinfo/spring
> 
> -- 
> 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> 
> Senior MPLS Expert
> 
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> 
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 25 Feb 2020 16:53:54 -0800

Hi Zafar, et al.,
I apologize for the unintended confusion but when I've said that I'll
review the updates I was under the impression (self-imposed) that a new
version has been published already. I'll be glad to review the updates in
the working version and share my notes if you can kindly send it my way. Or
I can wait for it to be published. Let me know what works for you best.

Regards,
Greg