Re: [Lime] I-D Action: draft-ietf-lime-yang-connection-oriented-oam-model-04.txt

Greg Mirsky <gregimirsky@gmail.com> Wed, 31 January 2018 06:36 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 528B61315D3; Tue, 30 Jan 2018 22:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 JmcfrM9dy2HT; Tue, 30 Jan 2018 22:36:42 -0800 (PST)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 C8C8B1315D0; Tue, 30 Jan 2018 22:36:41 -0800 (PST)
Received: by mail-lf0-x22a.google.com with SMTP id t139so19013905lff.0; Tue, 30 Jan 2018 22:36: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:content-transfer-encoding; bh=CtuXBv/0treN2vJV4D+u5MwwY20YHEJSw1GWNqQv0Cw=; b=VBorMXkT6Ag2vH7Pz5MGs6y7fCePNsosuuMMUx+wnSL8f9YQXYR++RMx4eujeuF2D3 GFCw4eJoqwRldGWyenygqxhVShW5ZtgaiSc1nr1s+kBgjJKj2NDrzoSAvAk9Ezlhb+DH g3ghsr0AgGUAYCCIBOdXIuG3goY6l9K5jXXchC4K8r8r3tnyoYY9iCdxKbqlO0Tx9Rp1 Swk0Zx+esTsceTiWY40f2ulb4H3X+3KnIIoGKpChHnJFdnAatX2mZwe9yKzdvQLuLl7r lkSLzG0+QGLaqzOWS0WlHRQ86vQh5tr+MdoldS3nDB9n8FjwAtsND/OkxUKfwyrWQ3ms vwQA==
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:content-transfer-encoding; bh=CtuXBv/0treN2vJV4D+u5MwwY20YHEJSw1GWNqQv0Cw=; b=X9hS7ORP/wL5ZrWDOY4rWaMHELUBeD0WpbgEkjy4pTZddMu8Nl1SX+rvFPf2IOvN7z WZmaOsrUvYPzJhffAvSPbTIoLMSt0HbDoQOM/QD6y/Sxp/kyA6PljKu4x/iqf+axJmla A5a2ckzbhdsKa3Hb6c0PZOpRVD6kZ6NdC7qPFthJAe4xdhTOSvEE6erIewfVmIofPLhP p1pe0sak+RXXctUceGEzSYWTvIIq4VIc98KncyxcvAcHLIUSAMMUvopcWW8I4PO1AvoF 1dGYDeQQPJWYngbnMpV3TfwJE+jQt+bYWbZxepXYn9cZOroTS1GN6RK4V+vjCpGwiu8d 9ZNg==
X-Gm-Message-State: AKwxytdBvIM8eRwodnUggo0Z2//cJmisoclqWkt2tE1CvgCcieuky8ak eBNri5BQA9XHz3x0/SKcn0MMJ981/QzJm0EwLv8=
X-Google-Smtp-Source: AH8x227sk8ZAyhWbPUHeA2jXwMRYtokknKULQ6g9J9rMJGxu+N2Z4q5ofbteVpcv8fnTa3upmEoOj6KLKdNkzKnnTU8=
X-Received: by 10.25.143.12 with SMTP id r12mr19424516lfd.30.1517380599792; Tue, 30 Jan 2018 22:36:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.83.91 with HTTP; Tue, 30 Jan 2018 22:36:39 -0800 (PST)
In-Reply-To: <E6BC9BBCBCACC246846FC685F9FF41EA2B8B347C@DGGEML504-MBS.china.huawei.com>
References: <E6BC9BBCBCACC246846FC685F9FF41EA2B8B347C@DGGEML504-MBS.china.huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 30 Jan 2018 22:36:39 -0800
Message-ID: <CA+RyBmWU9a8N1z9FKNgmq+ucTK3gKuiqTSGxaeDCtZ=34anOdg@mail.gmail.com>
To: wangzitao <wangzitao@huawei.com>
Cc: "lime@ietf.org" <lime@ietf.org>, "lime-chairs@ietf.org" <lime-chairs@ietf.org>, Benoit Claise <bclaise@cisco.com>, Carl Moberg <calle@tail-f.com>, Qin Wu <bill.wu@huawei.com>, Deepak Kumar <dekumar@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/mN79wIyHNKDEzqHYOIlbyokPkmM>
Subject: Re: [Lime] I-D Action: draft-ietf-lime-yang-connection-oriented-oam-model-04.txt
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 31 Jan 2018 06:36:45 -0000

Hi Michael, Authors, et. al,
thank you for your dedication to this work. Please kindly consider my
comments below.
- this document introduces YANG data model of connection-oriented OAM
protocols. I couldn't find the definition or reference to normative
definition of the connection-oriented OAM. As we've discussed, I
believe that the definition of the channel forwarding in G.800 in
section 6.3.1, specifically for connection-oriented packet switching,
is the one we can use similarly to the definition of connectionless
OAM in draft-ietf-lime-yang-connectionless-oam. And the fact that both
documents share one source of definitions, in my view, is advantage of
consistent dictionary.
- "This is the base identy of technology types which are
TRILL,MPLS-TP,vpls etc" Had VPLS been characterized as CO-PS? Not to
get into the discussion, perhaps stop after MPLS-TP be acceptable. And
I encourage to omit other references to VPLS in the document:
            - "... or for VPLS this can be per VPLS instance [RFC6136]."
            - " a VRF for VPLS,"
- what is the benefit to have specific ipv4-address and ipv6-address
in 'choice mep-address' rather than ip-address imported from
inet:ip-address?
- I think that 'leaf packet-size' is related to packet padding, not
the actual size of the test packet as there's always minimum size
determined by the corresponding technology and thus the packet size
cannot be smaller than the minimum size of, for example, LBM. Current
range for the leaf packet-size in rpc continuity-check is 0...10000
and in rpc continuity-verification the range is 64 ... 10000 (why such
inconsistency?). Test packet of 0 bytes doesn't seem practical while
test packet with 0 bytes of padding/payload does. And though we'd like
to use default for zero-touch (almost zero-touch), this is very
technology-specific parameter (compare Ethernet LBM and MPLS LSP
Ping).


Nits:
- s/interface)/interface)./
- consistency in using YANG vs. Yang throughout the document should be achieved.
- s/../maintenance-domain]/co-oam:mas/co-oam:ma[/../maintenance-domain]/co-oam:mas/co-oam:ma/
- s/CoS field in MPLS-TP/TC field in MPLS-TP/

Regards,
Greg

On Tue, Jan 30, 2018 at 12:58 AM, wangzitao <wangzitao@huawei.com>; wrote:
> Hi WG,
>
> This version addressed the issues arose by AD review and Yangdoctors early review.
> More details please review the document.
>
> Best Regards!
> -Michael
>
> -----邮件原件-----
> 发件人: Lime [mailto:lime-bounces@ietf.org] 代表 internet-drafts@ietf.org
> 发送时间: 2018年1月30日 16:44
> 收件人: i-d-announce@ietf.org
> 抄送: lime@ietf.org
> 主题: [Lime] I-D Action: draft-ietf-lime-yang-connection-oriented-oam-model-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Layer Independent OAM Management in the Multi-Layer Environment WG of the IETF.
>
>         Title           : Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols
>         Authors         : Deepak Kumar
>                           Qin Wu
>                           Michael Wang
>         Filename        : draft-ietf-lime-yang-connection-oriented-oam-model-04.txt
>         Pages           : 53
>         Date            : 2018-01-30
>
> Abstract:
>    This document presents a base YANG Data model for connection oriented
>    OAM protocols.  It provides a technology-independent abstraction of
>    key OAM constructs for such protocols.  The model presented here can
>    be extended to include technology specific details.  This guarantees
>    uniformity in the management of OAM protocols and provides support
>    for nested OAM workflows (i.e., performing OAM functions at different
>    levels through a unified interface)
>
>    The YANG model in this document conforms to the Network Management
>    Datastore Architecture defined in
>    [I-D.ietf-netmod-revised-datastores].
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lime-yang-connection-oriented-oam-model-04
> https://datatracker.ietf.org/doc/html/draft-ietf-lime-yang-connection-oriented-oam-model-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lime-yang-connection-oriented-oam-model-04
>
>
> 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/
>
> _______________________________________________
> Lime mailing list
> Lime@ietf.org
> https://www.ietf.org/mailman/listinfo/lime
> _______________________________________________
> Lime mailing list
> Lime@ietf.org
> https://www.ietf.org/mailman/listinfo/lime