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 <bess-boun...@ietf.org> on behalf of stephane.litkow...@orange.com
<stephane.litkow...@orange.com>
Sent: Monday, October 22, 2018 4:24:35 PM
To: draft-ietf-bess-l3vpn-y...@ietf.org; bess@ietf.org
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.
___________________________________________________________________________
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
