Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard
wangzitao <wangzitao@huawei.com> Thu, 08 February 2018 00:56 UTC
Return-Path: <wangzitao@huawei.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 AEF5B12711B; Wed, 7 Feb 2018 16:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level:
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 KwPx45xWby8I; Wed, 7 Feb 2018 16:56:55 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C0F124207; Wed, 7 Feb 2018 16:56:55 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EE715D89A21E9; Thu, 8 Feb 2018 00:56:51 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 8 Feb 2018 00:56:52 +0000
Received: from DGGEML504-MBS.china.huawei.com ([169.254.11.87]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0361.001; Thu, 8 Feb 2018 08:56:50 +0800
From: wangzitao <wangzitao@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
CC: IETF-Announce <ietf-announce@ietf.org>, Benoit Claise <bclaise@cisco.com>, Ronald Bonica <rbonica@juniper.net>, "lime-chairs@ietf.org" <lime-chairs@ietf.org>, "lime@ietf.org" <lime@ietf.org>, "draft-ietf-lime-yang-connection-oriented-oam-model@ietf.org" <draft-ietf-lime-yang-connection-oriented-oam-model@ietf.org>
Thread-Topic: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard
Thread-Index: AdOgd1fuDkn0DQd+Tjea0v+m6Jv9KQ==
Date: Thu, 08 Feb 2018 00:56:49 +0000
Message-ID: <E6BC9BBCBCACC246846FC685F9FF41EA2B8B5B66@DGGEML504-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.78.152]
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2B8B5B66DGGEML504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/hu4VrUHZ87TlafqJArCZR7LVxpI>
Subject: Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard
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: Thu, 08 Feb 2018 00:56:59 -0000
Thanks Greg for these comments. It make sense. And we already prepared a new version to address this comments, and it will be uploaded soon . Best Regards! -Michael 发件人: Greg Mirsky [mailto:gregimirsky@gmail.com] 发送时间: 2018年2月7日 23:06 收件人: ietf@ietf.org 抄送: IETF-Announce <ietf-announce@ietf.org>; Benoit Claise <bclaise@cisco.com>; Ronald Bonica <rbonica@juniper.net>; lime-chairs@ietf.org; lime@ietf.org; draft-ietf-lime-yang-connection-oriented-oam-model@ietf.org 主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> (Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard Dear Authors, et. al, thank you for your dedication to this work. Please kindly consider my comments, as I've shared them January 31st, for the IETF LC : - 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/ On Mon, Feb 5, 2018 at 11:07 PM, The IESG <iesg-secretary@ietf.org<mailto:iesg-secretary@ietf.org>> wrote: The IESG has received a request from the Layer Independent OAM Management in the Multi-Layer Environment WG (lime) to consider the following document: - 'Generic YANG Data Model for Connection Oriented Operations, Administration, and Maintenance(OAM) protocols' <draft-ietf-lime-yang-connection-oriented-oam-model-04.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org<mailto:ietf@ietf.org> mailing lists by 2018-02-19. Exceptionally, comments may be sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connection-oriented-oam-model/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6905: Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) (Informational - IETF stream) _______________________________________________ Lime mailing list Lime@ietf.org<mailto:Lime@ietf.org> https://www.ietf.org/mailman/listinfo/lime