Re: I-D Action: draft-ietf-6man-spring-srv6-oam-06.txt

["Zafar Ali (zali)" <[e-mail]>]

Hi Greg,

Many thanks for sending these comments (earlier sent privately to the authors).
Many thanks for having a WebEx call to help close them. Much appreciated.

As discussed, offline, the revision 6 was published to address your and other outstanding comments on the mailer.
We will send a diff summary for the WG.

Thanks

Regards … Zafar

From: Greg Mirsky <[e-mail]>
Date: Monday, July 13, 2020 at 5:12 PM
To: "Zafar Ali (zali)" <[e-mail]>, 6MAN <[e-mail]>
Subject: Fwd: I-D Action: draft-ietf-6man-spring-srv6-oam-06.txt

Dear All,
updates in the published version include those addressing my comments below:
·  Abstract refers to "controller-based OAM mechanisms for SRv6 networks". What are other OAM mechanisms? How these can be distinguished?
·  The document is titled OAM in SRv6 but in the Introduction the scope seems to be set much narrower
This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in an SRv6 network.
Ping and traceroute are important OAM tools but these are only part of what can be considered as comprehensive OAM toolset, the set that must include additional Fault of Management and the whole set of the Performance Monitoring OAM tools.
·  In the description of the reference model node N7 isn't listed either as SRv6 capable or as not supporting SRv6. Is it needed at all?
·  how processing of O-bit is different from iOAM Direct Exporting mode described in draft-ietf-ippm-ioam-direct-export<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>
·  is the support of IPFIX required for a node supporting O-bit? The document notes "this document assumes IP Flow Information Export (IPFIX) protocol [RFC7011] is used for exporting the traffic flow information".
·  Does the following text equally applies to a segment endpoint or the final destination of the SRv6 tunnel:
   The OAM process MUST NOT process the copy of the packet or respond to
   any upper-layer header (like ICMP, UDP, etc.) payload to prevent
   multiple evaluations of the datagram.
·  the ICMP Echo request/reply mechanism does not "query liveliness of a remote IP address" but verifies that there's a path over the network that provides bidirectional communication between two IP entities. The targetted IP entity might be not reachable for the given IP entity but that cannot be concluded that it is not reachable for another IP entity, i.e., not lively at all.
·  Section 3.3 is very close to the descriptions of iOAM Direct Exporting<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/> and Postcard Based Telemetry<https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/> drafts. If there are important differences, these, I think, should be highlighted. Otherwise, as it appears, we have three proposals that effectively achieve the same with minor technical differences. Had the use cases for O-bit in SRH been presented and discussed at IPPM WG?
·  Some grammar needs adjustment in
   In the recent past, network operators are interested in performing
   network OAM functions in a centralized manner.
Perhaps
   In the recent past, network operators demonstrated interest in performing
   network OAM functions in a centralized manner.
·  I don't know how the control plane is related to OAM but the following text seems to imply such connection:
    ... the document
   describes a procedure that can be used to perform path continuity
   check between any nodes within an SR domain from a centralized
   monitoring system, with minimal or no control plane intervene on the
   nodes.
·  I think that there is an issue with the method described in section 3.4. Failures of links from N100 to N2 and from N5 to N100 are indistinguishable from failures along the path N2-N3-N4-N5.

Regards,
Greg

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, Jul 13, 2020 at 1:41 PM
Subject: I-D Action: draft-ietf-6man-spring-srv6-oam-06.txt
To: <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>>



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
        Authors         : Zafar Ali
                          Clarence Filsfils
                          Satoru Matsushima
                          Daniel Voyer
                          Mach Chen
        Filename        : draft-ietf-6man-spring-srv6-oam-06.txt
        Pages           : 22
        Date            : 2020-07-13

Abstract:
   This document describes how the existing IPv6 OAM mechanisms can be
   used in an SRv6 network.  The document also introduces enhancements
   for OAM mechanisms for SRv6 networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-06
https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-spring-srv6-oam-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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