[bess] LxVPN and EVPN yang models

<stephane.litkowski@orange.com> Mon, 22 October 2018 12:29 UTC

Return-Path: <stephane.litkowski@orange.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 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: stephane.litkowski@orange.com
To: "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: 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: <https://mailarchive.ietf.org/arch/msg/bess/erWR7RUWkysZWiJ9KaVmVCwqk1A>
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 <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: Mon, 22 Oct 2018 12:29:43 -0000

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.