[bess] some comments on evpn yang data model
wangzitao <wangzitao@huawei.com> Tue, 11 June 2019 02:15 UTC
Return-Path: <wangzitao@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5D1200CD; Mon, 10 Jun 2019 19:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Y6FTN16y3yQr; Mon, 10 Jun 2019 19:15:08 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2AD1E120071; Mon, 10 Jun 2019 19:15:08 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4AC303F9CAD9874A52AF; Tue, 11 Jun 2019 03:15:06 +0100 (IST)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 11 Jun 2019 03:15:05 +0100
Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.89]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0439.000; Tue, 11 Jun 2019 10:15:02 +0800
From: wangzitao <wangzitao@huawei.com>
To: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-yang@ietf.org" <draft-ietf-bess-evpn-yang@ietf.org>
Thread-Topic: some comments on evpn yang data model
Thread-Index: AdUf+qkqxFZrv3MbTH+ztMO6G+ye7Q==
Date: Tue, 11 Jun 2019 02:15:02 +0000
Message-ID: <E6BC9BBCBCACC246846FC685F9FF41EA2D9E931F@DGGEMM527-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.142.117]
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2D9E931FDGGEMM527MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/L6DUCWxEFPxDcU9D-cr1X5yFxvE>
Subject: [bess] some comments on evpn yang data model
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 02:15:10 -0000
Dear Authors, I have read the -07 version draft. And there are some comments. #1 ietf-pseudowires model expired. I ran this model on yangcatalog but received an unexpected error: ietf-ethernet-segment@2019-03-09.yang:21: error: module "ietf-pseudowires" not found in search path It seems that the "draft-ietf-bess-l2vpn-yang" which define the "ietf-pseudowires" expired. I noticed that some authors are also the authors of "draft-ietf-bess-l2vpn-yang" so please revive the l2vpn yang model draft. #2 The tree structure does not match the code. When I review the tree structure blocks, I wonder why there is only one route-target leaf under the "rd-rt" list. However, when I review the yang codes, this list is defined as: leaf route-distinguisher { type rt-types:route-distinguisher; description "Route distinguisher"; } uses rt-types:vpn-route-targets; description "A list of route distinguishers and " + "corresponding VPN route targets"; } The vpn-route-targets grouping defined in rt-types contains a vpn-target list. It seems that the schema tree is not updated synchronously. #3 Many lists are lack of key nodes, for example ethernet-auto-discovery-route list, mac-ip-advertisement-route list, inclusive-multicast-ethernet-tag-route list, etc. How do I retrieve these status data without a key value? Best Regards! -Michael