[bess] Revew of draft-ietf-bess-evpn-yang-07

Qin Wu <bill.wu@huawei.com> Thu, 23 May 2019 02:59 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F22E812013F for <bess@ietfa.amsl.com>; Wed, 22 May 2019 19:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j-Y7YfAPlTNP for <bess@ietfa.amsl.com>; Wed, 22 May 2019 19:59:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 3B14D12004A for <bess@ietf.org>; Wed, 22 May 2019 19:59:48 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 462F77C1A948A15AF923 for <bess@ietf.org>; Thu, 23 May 2019 03:59:46 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com ( by LHREML713-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 23 May 2019 03:59:45 +0100
Received: from NKGEML513-MBX.china.huawei.com ([]) by nkgeml412-hub.china.huawei.com ([]) with mapi id 14.03.0415.000; Thu, 23 May 2019 10:59:39 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "bess@ietf.org" <bess@ietf.org>
CC: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Thread-Topic: Revew of draft-ietf-bess-evpn-yang-07
Thread-Index: AdUREV6jKozWOOnmQEq5yCY+ffjk9Q==
Date: Thu, 23 May 2019 02:59:38 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA4948732@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA4948732nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/OZEsfJtC6qnRpfxV95jgieDKA8U>
Subject: [bess] Revew of draft-ietf-bess-evpn-yang-07
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: Thu, 23 May 2019 02:59:54 -0000

Hi, folks:
Have a quick review of draft-ietf-bess-evpn-yang-07, I am confused about EVPN adding dependency to L2VPN YANG. A few quick comments as follows:

1.       Section 1, last paragraph:

Try to understand the relation between L2VPN YANG and EVPN YANG. Is ethernet-segment model is specific to EVPN? It looks Ethernet segment can also be used to model pseudowire which is defined in L2VPN model?

Is L2VPN model a base model while EVPN model is extension to L2VPN model? If this is true, can we move etherent-segment model into L2VPN model draft and consolidate with pseudowire model?

2.       Section 1, last paragraph said:

"That interface can be a physical interface,

   a bundle interface or virtual interface. The latter includes

   attachment-circuit and pseudowire.


What does the latter refer to?

Bundle interface or virtual interface or both

3.       Section 3.3 module ietf-evpn

If EVPN model is extension to L2VPN model, I believe these common attributes should be moved to L2VPN model draft? Make sense? Also It will be great to align with ietf-bgp-l3vpn, change the name into ietf-bgp-evpn

4.       Section 3.3, schema tree

Why bgp-parameters are repeated in both ietf-evpn or Ethernet-segment? Is there any rationale behind?

Not sure vpls-constraint attribute is specific to EVPN? Why not define it in the L3VPN model draft?

Confusing the relationship between L2VPN and EVPN.

I would suggest both L2VPN and EVPN augment from Network Instance model and add L2VPN and EVPN specific parameters to address this confusion.