[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