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

[Greg Mirsky <[e-mail]>]

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

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

> 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)" <[e-mail]>
> *Date: *Wednesday, December 18, 2019 at 7:19 PM
> *To: *Greg Mirsky <[e-mail]>, Ole Troan <[e-mail]
> >
> *Cc: *SPRING WG <[e-mail]>, 6man WG <[e-mail]>, 6man Chairs <
> [e-mail]>, "Zafar Ali (zali)" <[e-mail]>
> *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 <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Thursday, December 5, 2019 at 5:22 PM
> *To: *Ole Troan <[e-mail]>
> *Cc: *SPRING WG <[e-mail]>, 6man WG <[e-mail]>, 6man Chairs <
> [e-mail]>
> *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
> <[e-mail]>> wrote:
>
> Hello,
>
>   As agreed in the working group session in Singapore, this message starts
> a new two week 6MAN Working Group Last Call on advancing:
>
>   Title    : Operations, Administration, and Maintenance (OAM) in Segment
> Routing Networks with IPv6 Data plane (SRv6)
>   Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M.. Chen
>   Filename : draft-ietf-6man-spring-srv6-oam-02
>   Pages    : 23
>   Date     : 2019-11-20
>
>     https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
>
> as a Proposed Standard.
>
> Substantive comments and statements of support for publishing this
> document should be directed to the mailing list.
> Editorial suggestions can be sent to the author. This last call will end
> on the 18th of December 2019.
>
> To improve document quality and ensure that bugs are caught as early as
> possible, we would require at least
> two reviewers to do a complete review of the document.  Please let the
> chairs know if you are willing to be a reviewer.
>
> The last call will be forwarded to the spring working group, with
> discussion directed to the ipv6 list.
>
> Thanks,
> Bob & Ole, 6man co-chairs
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>