Re: [bess] Comments on L3VPN yang
I'm also wondering if the RPF should not sit in the MPLS module as it could be used for any types of labels advertised to a neighbor. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of stephane.litkow...@orange.com Sent: Monday, October 22, 2018 15:25 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. _ 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 em
Re: [bess] Comments on L3VPN yang
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 on behalf of 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@i
[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. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess