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

[Greg Mirsky <[e-mail]>]

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