Return-Path: 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 85574130EBC; Mon, 22 Oct 2018 05:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 V_Cq8zuAFoGd; Mon, 22 Oct 2018 05:29:33 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168F0130E05; Mon, 22 Oct 2018 05:29:24 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 42dwnG2FHdz107M; Mon, 22 Oct 2018 14:29:22 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 42dwnG13bbzyQ2; Mon, 22 Oct 2018 14:29:22 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 14:29:21 +0200 From: To: "draft-ietf-bess-evpn-yang@ietf.org" , "draft-ietf-bess-l2vpn-yang@ietf.org" , "draft-ietf-bess-l3vpn-yang@ietf.org" CC: "bess@ietf.org" Thread-Topic: LxVPN and EVPN yang models Thread-Index: AdRp/umvjQ/bZC8BRRaWwfuUSZ1VTg== Date: Mon, 22 Oct 2018 12:29:21 +0000 Message-ID: <29707_1540211362_5BCDC2A2_29707_5_1_9E32478DFA9976438E7A22F69B08FF924B3118F1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924B3118F1OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 12:29:43 -0000 --_000_9E32478DFA9976438E7A22F69B08FF924B3118F1OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, Speaking as individual, after reading the last versions of your module, I s= till 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 i= s weird in term of config consistency =3D> maybe better to have a bgp-auto-= discovery Boolean or maybe the discovery-type is enough to know that bgp-au= to-discovery is used ?) o Under ipv4 or ipv6 for l3vpn RTs but rd is at top level. That could mak= e sense but again the configuration is slightly different from other AFI/SA= FIs. Having different imp/exp for IPv4 and IPv6 is a valid use case, but yo= u should also allow to have the same config for both without defining per A= FI/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 a= dd a pointer (reference) to an EVPN instance which is in a completely diffe= rent tree. That looks really strange and make EVPN instance configuration c= ompletely different from an L3VPN instance or L2VPN instance. Do you plan t= o reuse the config parameters from L2VPN or do you prefer creating a comple= tely different tree ? If you prefer a completely different tree why not cre= ating an EVPN ni-type ? Can't we have one model defining some bgp-vpn containers possibly as a sepa= rate 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_9E32478DFA9976438E7A22F69B08FF924B3118F1OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

 

Speaking as individual, after reading the last versi= ons 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 t= hat could be shared or at least modeled in the same way:

-     &= nbsp;    Model name: L3VPN uses ietf-bgp-l3vpn while others = use ietf-evpn or ietf-l2vpn

-     &= nbsp;    Route-target import/export and route-distinguisher:=

o   Under bgp-parameters/common/rd-rt/ for EVPN<= o:p>

o   Under bgp-auto-discovery for L2VPN (that cou= ld make sense here but it is weird in term of config consistency =3D> ma= ybe 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 a= t 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.

-     &= nbsp;    RIB route limits could also be modeled the same way=

-     &= nbsp;    Modelization of route entries in the RIB could be m= odeled in the same way across model

-     &= nbsp;    Attachment to the NI:

o   I don’t understand how EVPN is integra= ted in L2VPN. It seems that you add a pointer (reference) to an EVPN instan= ce which is in a completely different tree. That looks really strange and m= ake EVPN instance configuration completely different from an L3VPN instance or L2VPN instance. Do you plan to reuse t= he config parameters from L2VPN or do you prefer creating a completely diff= erent 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 mo= dels ?

 

Happy to hear your feedback.

 

Brgds,

 

Stephane

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_9E32478DFA9976438E7A22F69B08FF924B3118F1OPEXCLILMA4corp_--