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

Greg Mirsky <gregimirsky@gmail.com> Mon, 13 July 2020 21:13 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51D93A1070 for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 14:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level:
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJTtAS4_ZD7X for <ipv6@ietfa.amsl.com>; Mon, 13 Jul 2020 14:13:20 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D66D23A0B6B for <6man@ietf.org>; Mon, 13 Jul 2020 14:12:48 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id k15so10000108lfc.4 for <6man@ietf.org>; Mon, 13 Jul 2020 14:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ifb7QZZM/c/cnJTz1QkMCK5PzttAvsbnw6IS0awwCX0=; b=qCSXg9uPh67O+WVLV04TTb2AYvx+JIxsvkiQcGcxiTHh2R6vTb6dlfdmH2NnEgSQd1 UsEHyUhk4W3rAx/h5VwZ2zMNztmI9/6J0x7DDfWyeAhC8V/ql5zsM/CSIIPj/OBViL0J CA5sBGm//sgDssyjGDV0RNFqTUpkslCaSea7lSjPwaP+7Ga4OixDZIfBx6GIpvAq4RRI atA3hVoGiT4X1iYbmzG+QgIbRsmhOA61KmkOFRwpdOGUYSqOKlHw+NxcCb5wnAL9UUHA qIB8sEIHaFt0k9Uqr1ZleBCfgLglfv5kg1V3xku5j8GK6t/bVYCe1VqlI9xcUGX7aOYW zd6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ifb7QZZM/c/cnJTz1QkMCK5PzttAvsbnw6IS0awwCX0=; b=h+QZPAyzgu6CmHgUf4+P5cjZIT/WLwn6SuQUi3UCETUdymTNugDkRDwH5WqXmaJ6fx /bRHhg44rPvetv4huJwbZSUZTI87KkVwNrfTk9hysTN0EpZejqiGABdK7htGcwA4wuN7 eqrB8M4KP7QIK+Byn0yV3QJmzN1XGp53NSOU/zYcPNq9w1mReku+6k2u6LMzJAmbZapG bqlA8otXe4tCIdvPtHy2eRx5hAFvbeSqOw0vdsNX3D7Wv2tjNnT4QhH1I/7r/kOdxH5L R7BeJzmqHJodrPAqJeTO5/I7nNCWgcVzx4XKo79Xw/NLfe64kM0Y1i4P//ksSwo/L/II ugNQ==
X-Gm-Message-State: AOAM531WdHCMsMZrDFnKeiedFKNx5jho5efu55IVohdoMvLcmcdUVaT8 7H/dMwxbyMKe9Xq0fYtWIOLIM62DNx9Gpln6nTM=
X-Google-Smtp-Source: ABdhPJzfEIWtMBQn3gE91QuIfXYIOVcr/XKdXnOlF3tpRsHvSRGwx+KQac7INiVZOMNAJ8dz2vEqAIHnsdyRve0ubz4=
X-Received: by 2002:a05:6512:203b:: with SMTP id s27mr508163lfs.158.1594674766787; Mon, 13 Jul 2020 14:12:46 -0700 (PDT)
MIME-Version: 1.0
References: <159467281765.1501.12978719760842949807@ietfa.amsl.com>
In-Reply-To: <159467281765.1501.12978719760842949807@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 13 Jul 2020 14:12:35 -0700
Message-ID: <CA+RyBmWvMFPQQpX2HSAbC1qroDF-T=8Wwkcp10Gd6fS81W1J=w@mail.gmail.com>
Subject: Fwd: I-D Action: draft-ietf-6man-spring-srv6-oam-06.txt
To: "Zafar Ali (zali)" <zali@cisco.com>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000001b8ee05aa592726"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7dsnQwphdMTKX7Y1lRlcvQ3kKwo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2020 21:13:25 -0000

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: <internet-drafts@ietf.org>
Date: Mon, Jul 13, 2020 at 1:41 PM
Subject: I-D Action: draft-ietf-6man-spring-srv6-oam-06.txt
To: <i-d-announce@ietf.org>
Cc: <ipv6@ietf.org>



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.

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


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------