Re: [bess] LxVPN and EVPN yang models
Qin Wu <bill.wu@huawei.com> Thu, 23 May 2019 03:11 UTC
Return-Path: <bill.wu@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 717E812011B; Wed, 22 May 2019 20:11:24 -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 A3lM4I89tdZ5; Wed, 22 May 2019 20:11:22 -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 D1E24120025; Wed, 22 May 2019 20:11:21 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9DABFB43735029F909D8; Thu, 23 May 2019 04:11:19 +0100 (IST)
Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 23 May 2019 04:11:19 +0100
Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 23 May 2019 04:11:19 +0100
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 23 May 2019 04:11:18 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.182]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Thu, 23 May 2019 11:10:54 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "draft-ietf-bess-evpn-yang@ietf.org" <draft-ietf-bess-evpn-yang@ietf.org>, "draft-ietf-bess-l2vpn-yang@ietf.org" <draft-ietf-bess-l2vpn-yang@ietf.org>, "draft-ietf-bess-l3vpn-yang@ietf.org" <draft-ietf-bess-l3vpn-yang@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: LxVPN and EVPN yang models
Thread-Index: AdURFGFHiFmGPodWRx2ZN3M0IfJPaQ==
Date: Thu, 23 May 2019 03:10:54 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAA4948770@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.31.203]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA4948770nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3Bh7O8wnJFimDXHASOUn8_N95gE>
Subject: Re: [bess] LxVPN and EVPN yang models
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 03:11:25 -0000
I agree with Stephane for the following suggestion, it will be great to see these three draft can factor out common building block or all augment from Network instance model separately, without any dependency on each other? Factoring out common building block will be a good approach, one a good example is resolve dependency between TEAS topology model and TE tunnel model, to move TE topo forward, common TE type have been factored out. All Augment from Network instance model without dependency also make sense to me. I want to hear authors’ feedback on the above two proposed approaches. -Qin 发件人: BESS [mailto:bess-bounces@ietf.org] 代表 stephane.litkowski@orange.com 发送时间: 2018年10月22日 20:29 收件人: draft-ietf-bess-evpn-yang@ietf.org; draft-ietf-bess-l2vpn-yang@ietf.org; draft-ietf-bess-l3vpn-yang@ietf.org 抄送: bess@ietf.org 主题: [bess] LxVPN and EVPN yang models Hi Authors, Speaking as individual, after reading the last versions of your module, I still have several concerns about the consistency of the modeling across all models. There are common components between all the models that could be shared or at least modeled in the same way: - Model name: L3VPN uses ietf-bgp-l3vpn while others use ietf-evpn or ietf-l2vpn - Route-target import/export and route-distinguisher: o Under bgp-parameters/common/rd-rt/ for EVPN o Under bgp-auto-discovery for L2VPN (that could make sense here but it is weird in term of config consistency => maybe better to have a bgp-auto-discovery Boolean or maybe the discovery-type is enough to know that bgp-auto-discovery is used ?) o Under ipv4 or ipv6 for l3vpn RTs but rd is at top level. That could make sense but again the configuration is slightly different from other AFI/SAFIs. Having different imp/exp for IPv4 and IPv6 is a valid use case, but you should also allow to have the same config for both without defining per AFI/SAFI config. - RIB route limits could also be modeled the same way - Modelization of route entries in the RIB could be modeled in the same way across model - Attachment to the NI: o I don’t understand how EVPN is integrated in L2VPN. It seems that you add a pointer (reference) to an EVPN instance which is in a completely different tree. That looks really strange and make EVPN instance configuration completely different from an L3VPN instance or L2VPN instance. Do you plan to reuse the config parameters from L2VPN or do you prefer creating a completely different tree ? If you prefer a completely different tree why not creating an EVPN ni-type ? Can’t we have one model defining some bgp-vpn containers possibly as a separate module that could be reused across all models ? Happy to hear your feedback. Brgds, Stephane _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [bess] LxVPN and EVPN yang models stephane.litkowski
- Re: [bess] LxVPN and EVPN yang models Lizhenbin
- Re: [bess] LxVPN and EVPN yang models Qin Wu