Re: [bess] Comments on L3VPN yang

[Alexander Vainshtein <[e-mail]>]

Hi all,
I fully agree with Stephane's point "the label mode should sit within the VRF and not at the BGP level. Each VRF may have a different flavor".  One relevant use case is the VRF that provides inet-subnet forwarding i EVPN with Symmetric IRB - it must use per-VRF label allocation policy with the label in question being advertised ad Label2 in MAC/IP Advertisement routes rgardless of how other VRFs allocate their labels.

My 2c.

Thumb typed by Sasha Vainshtein

________________________________
From: BESS <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Monday, October 22, 2018 4:24:35 PM
To: [e-mail]; [e-mail]
Subject: [bess] Comments on L3VPN yang

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.


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________