[bess] Comments on L3VPN yang

<stephane.litkowski@orange.com> Mon, 22 October 2018 13:24 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 D5381128D0C; Mon, 22 Oct 2018 06:24:52 -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 S7_Sqm8fFPSy; Mon, 22 Oct 2018 06:24:50 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D38128BAC; Mon, 22 Oct 2018 06:24:50 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 42dy1D5RcRz8t2B; Mon, 22 Oct 2018 15:24:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 42dy105BPyzCqkM; Mon, 22 Oct 2018 15:24:36 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0415.000; Mon, 22 Oct 2018 15:24:36 +0200
From: <stephane.litkowski@orange.com>
To: "draft-ietf-bess-l3vpn-yang@ietf.org" <draft-ietf-bess-l3vpn-yang@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Comments on L3VPN yang
Thread-Index: AdRqBnUNK3UHt6S0RS+mAKKFMAypbw==
Date: Mon, 22 Oct 2018 13:24:35 +0000
Message-ID: <11203_1540214688_5BCDCF94_11203_280_1_9E32478DFA9976438E7A22F69B08FF924B311A6A@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_9E32478DFA9976438E7A22F69B08FF924B311A6AOPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/B-OFZDn2KhEcUqVCWjy2HbQMCac>
Subject: [bess] Comments on L3VPN yang
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 13:24:53 -0000

Hi Authors,

Please find some comments on the current model:

-          I don't understand the "advertise-as-vpn" leaf under global-imports, what is the use case ?

-          Same question for "bgp-valid-route" leaf

-          Why do you have a long list of protocols within the global-imports ? Isn't it the goal of the route-policy referenced earlier ? Moreover I do not think that it is a good idea to use the enum type here as protocol names ,when referring to, should not change across all routing configurations within a node.

-          Export to global may also require a policy to filter

-          Some description fields are just "."

-          How do you plan the tunnel policy to be used ?

-          Would be great to have RTs configurable for both IPv4/IPv6 without redefining the config for each address family.

-          While I think the "forwarding-mode" under interface is a good thing, it looks really a Cisco like config statement that other implementations do not have. Wouldn't it be better  to have a knob to enable mpls packet processing on an interface ; maybe in the MPLS yang model ?

-           What is the goal of the "route-policy" within "retain-route-targets" under the BGP peer AFI/SAFI ? I usually two use case (auto policy => import RTs are derived from VRF configuration, or keep all), what is the use case you want to address here ?

-          What is the "vpn-prefix-limit" within "retain-route-targets" under the BGP peer AFI/SAFI ? Is it a generic BGP prefix-limit ? If yes, we need to keep it generic within the BGP model.

-          IMO, the label mode should sit within the VRF and not at the BGP level. Each VRF may have a different flavor.

-          Why do you define bgp-label-mode and routing-table-limit for ipv4 unicast and ipv6 unicast ? Does not seem to be L3VPN related.

-          For iBGP PE-CE, notion of independent domain with attr-set usage seems to miss in the model

-          Unequal cost path loadbalancing option is missing from the VRF config

-          Do we need a config statement to enable local import/export between local VRFs ?

-          I suppose that IGP/BGP configuration in VRF is inherited from core routing model.

-          Do you have to enrich routing policy model with ability to set/delete/match RTs, SoOs ?

-          Do we have to create/enrich RIB-in/RIB-out/Loc-RIB entries for BGP L3VPN prefixes ?

-          What about PIC Edge/PE-CE link protection configuration ?

-          Need notification for the route table limit alert

-          Do we have operational states with number of IPv4 and IPv6 routes within the instance ?

-          Do we have everything to support Carrier's of Carrier case ?


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.