Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03

Greg Mirsky <gregimirsky@gmail.com> Tue, 31 January 2017 18:06 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3A6129513; Tue, 31 Jan 2017 10:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 Bohq6tDh07oo; Tue, 31 Jan 2017 10:06:41 -0800 (PST)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 AD979129474; Tue, 31 Jan 2017 10:06:41 -0800 (PST)
Received: by mail-ot0-x22a.google.com with SMTP id 73so271981008otj.0; Tue, 31 Jan 2017 10:06:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0OVsQhewjxl/d9z+toQZTkDoD21gMVFpvrpmJhfzWuA=; b=YbFGViV2YVRYUCn7feaVZbo6cxj9DU1yHCQ5nad6VVVqmODEziKmjxi8ojcu7UINps mp78WMKcWGeoMw9jiHqIZUU1NOt98mvbypwqMuApRtLivpedJ49PU+0pS5aIkC6nNpOf G1++dKHAccrqBtAg9jbY6JjeCvHon+wmj/mdaDdJ6GVm66FI0TmqY/qW1Rny8nigsmzx ZJyJnmdoYKAPK+g6DKhBZhJ9yPWYP71ebUR9rH8m8e4bRe2op9PKl6H1NtMwJVUvMmeb MsfhysY7ZnCBFwUEzYaFUiOP4HW1iSpEw9SKudT8+akjwQhSxeQu2ulsiiJsrRBX7Tqz atVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0OVsQhewjxl/d9z+toQZTkDoD21gMVFpvrpmJhfzWuA=; b=IXUqYXRxMclpUjDWWVOmu9QQNMZtjSCVIjjCiIitXXZfan17/DXYeol9puCLy3HXpq WfycIn8ZWqOQQK6m/YA2gnUDiykwzeb9qTmL4LP7YVtrfTxZiCs98txCoLNdQexbnfa+ C70j2qRf43jXlul9nXRplImrSAtWIaUuDws9JayfLHeUvOJA1AZgnQKqJpB1LnZMZ6tE QMbm3G3QugC6ymTecEonGlI+ffK+ov5AlLjAsTbtbsXbieXFENhP8fFhRiMrcL2R5XiW 8SYqT3zrhO6vwXzD1Ke11rEh2+1lVR9f2r4gOHVB3qH2bBlN/lqfSXsY9vagfogATcrI /crg==
X-Gm-Message-State: AIkVDXJnkAi4ZX90AhoWyDG0mOzXnvlX5VKV6mVpkEHtKJdvRB/QbBWg9fXoTcEQB2hCbl5XgHXBe/H1WsbjoA==
X-Received: by 10.157.17.5 with SMTP id g5mr4520561ote.118.1485886000949; Tue, 31 Jan 2017 10:06:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Tue, 31 Jan 2017 10:06:40 -0800 (PST)
In-Reply-To: <BLUPR0501MB2051BD77E1AE017AF9C614CFAE7E0@BLUPR0501MB2051.namprd05.prod.outlook.com>
References: <BLUPR0501MB2051BD77E1AE017AF9C614CFAE7E0@BLUPR0501MB2051.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 31 Jan 2017 10:06:40 -0800
Message-ID: <CA+RyBmWQcBC3nrCRfvgL6RRpXnubBe25LSsWViY8c8SoL4wLKg@mail.gmail.com>
To: Ron Bonica <rbonica@juniper.net>
Content-Type: multipart/alternative; boundary=001a1145009e43749e054767cbb8
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/Bx6A0eqPRT4qXU8e_caXm4EElQA>
Cc: "draft-ietf-lime-yang-connectionless-oam.all@ietf.org" <draft-ietf-lime-yang-connectionless-oam.all@ietf.org>, "lime@ietf.org" <lime@ietf.org>
Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-03
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2017 18:06:52 -0000

Dear Authors, LIME WG Chairs, et.al,
please consider my comments as part of WG LC discussion.

   -

   3.1 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.1>;.
TP Address

   - I think that this topic requires more discussion. In what case, which
      network technology developed at IETF MAC may identify test point?
      - FEC is the most common case among listed. In fact, FEC unlikely
      fits into this list if we understand it as group of IP packets which are
      forwarded in the same manner over the same path, and with the same
      forwarding treatment. In other words, we have the same destination, same
      next hop, egress interface and CoS marking (note that some of these
      parameters may be as wild card).
      - IP Address, whether v4 or v6, does not sufficiently define the Test
      Point and must be associated with the parameter that defines forwarding
      treatment of a test packet addressed to the Test Point, e.g.
DSCP for IP or
      TC for MPLS. True, often CoS parameter is set by default but that doesn't
      exclude it from the list of parameters that define the Test Point
      - I don't know of a case when this is true "a pair of source,
      destination addresses, and interface (Useful for BFD)". Could you please
      elaborate, give an example?
      - "System-id to represent the device or node" Like in Segment
      Routing? Example, reference would be helpful.
   -

   3.2 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.2>;.
Tools

   - "performance measurement" As I understand, model of performance
      measurement OAM is outside the scope of this document.
      - I think this section would be the proper place do discuss proactive
      and on-demand OAM tools, give examples of each and how they being used in
      network operations.
   -

   3.3 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.3>;.
OAM-layers

   - "each layer has its own OAM protocols"
         - s/protocols/protocol/
         - I think that that is not necessarily the case, e.g. BFD may be
         used in IP/MPLS underlay and L3VPN overlay.
      - "OAM-layers is referred to a list of upper layer, lower layer that
      are related to current test point. This allow users to easily navigate up
      and down to efficiently troubleshoot a connectivity issue at different
      layer."
         - Something is missing in the first sentence.
         - s/this allow/this allows/
         - Connectionless network does not include connection as element of
         its architecture and thus there's no mis-connection defect.
Perhaps you
         were referring to loss of continuity defect here.
      - I don't agree with the proposed use of OAM level. If we consider
      OAM of a service that traverses multiple administrative domains, then
      Service OAM must be at the same level regardless of domain. Service OAM
      would be the outmost top level. Each operator may enable OAM
test points in
      its respective segment so that each of segment would be at the same OAM
      level, e.g. Link OAM at the very bottom with Segment OAM between Service
      and Link OAM levels.
   -

   3.5 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>;.
Test Point Locations

   - The last sentence is hard to parse and it leaves impression of
      circular reference with the definition of Test Point Location Information
      definition in the previous section.
   - "... data model is made generic enough to allow active, passive and
   hybrid OAMs to do the retrieval"
      - This being mentioned in reference to Path Discovery Data and
      Continuity Check Data. I'd imagine that an OAM mechanism, would it be
      active, passive or hybrid, produces the data but the retrieval
of data done
      using non-OAM protocol, e.g. RPC, gRPC or else.
   -

   3.8 <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.8>;.
OAM data hierarchy

   - I think that "oper" as name for the container that holds operational
      information is confusing. Could it be extended, more self-explanatory?
      - I there are more than two types of TP (IPv4 or IPv6), e.g.
      System-id, why container *oper* for continuity-check statistics holds
      only for IPv4 and IPv6 types of TP?
      - as-number-location may be part of tp-address, but as identifier of
      a Test Point? Could you please give an example.
      - I believe that connection-oriented-location as part of tp-address
      grouping is not correct.
      - As connectionless network does not use notion of connection, OAM in
      connectioless network does not include tools to conduct connectivity
      verification and to detect mis-connection defect. Hence there's no
      definition of in and out of mis-connection defect for connectionless
      networks.
      - I don't agree with the list of values the 'tp-address-type-value'
      leaf may take. As noted earlier, MAC unlikely to be used as address of a
      test point in connectionless network and so FEC identifier


Nits:

   - cc - is missing from Terminology section
   -  FEC is missing from Terminology section
   - [lime retrieval methods] appears as reference but has no real document
   it points to

I don't support publication of this version.

Regards,
Greg

   -


On Thu, Jan 19, 2017 at 8:12 AM, Ron Bonica <rbonica@juniper.net>; wrote:

> Folks,
>
> This message begins a Working Group Last Call on draft-ietf-lime-yang-connectionless-oam-03.
> Please submit comments by February 3, 2017.
>
>
>   Ron
>
> _______________________________________________
> Lime mailing list
> Lime@ietf.org
> https://www.ietf.org/mailman/listinfo/lime
>