[dev] EVPN (and L3VPN) configuration

Vivek Venkatraman vivek at cumulusnetworks.com
Wed Jul 12 06:04:33 EDT 2017


Hi Philippe,

I am currently on vacation in India, hence the delay in responding to your
mail. Thank you for an in-depth review, please see inline. (For another
couple of weeks, additional responses from me are likely to be delayed).


On Mon, Jul 3, 2017 at 8:58 PM, Philippe Guibert <philippe.guibert at 6wind.com
> wrote:

> Hi Vivek,
>
> The note you made is very interesting, it gathers a lot of very relevant
> information.
> You described  how the symetric and assymetric cases of draft rfc works
> for frrouting.
> In addition to presenting this, you illustrated the new vty commands.
>
> So, I made some comments on both points.
> - on the first point,
> I would like to know why you restrict to sending RT2 with only L2 Label ?
>

A single label (or VNI) is all that is needed for EVPN-for-L2 (where the
gateway is a different device) or even when supporting routing/gateway
functionality (L2+L3) when operating in asymmetric mode. The second label
(or VNI) is needed only for routing/gateway functionality when operating in
symmetric mode.

There is no restriction envisioned in the implementation on a second label
(VNI). Rather, the plan is to support both modes of routing. For the
symmetric mode, in the case of VxLAN, the second label (VNI) is the "L3
VNI" and will be available through the proposed configuration (in this
mail).

Also, I would like FRR not to be restricted to VNI, since the draft
> theorically supports network overlays other than VXLAN (NVGRE, MPLS).
>

I agree, which is why I proposed some configuration/syntax for MPLS here.
Note that the Linux kernel doesn't yet have a good model for L2oMPLS.


>
> - on the second point,
> I agree on advertise-gateway issue.
> I am not totally convinced with enhancing l2vpn evpn <l3vni>
> I think more of having a generic MAC-VRF or IP-VRF context where we
> configure RD, RT, VNI, etc...In the vrf-policy case, MAC-VRF and IP-VRF
> would have the same vty node. Only layer command would distinguish ( layer
> 3 versus layer 2). I need to bring more elaborate example for RT2/RT5 case.
>

The "EVI" syntax I provided below was for the MAC-VRF. Given that an IP VRF
and a MAC VRF will be rather different (the former deals with routes and
next hops and will/can have OSPF/BGP neighbors etc., the latter deals with
MACs and possibly, ARP suppression), I feel the two should be kept
separate. Also, since EVPN-for-VxLAN provides a simple way of "auto
creating" the MAC VRFs (the VNI is fundamentally the VRF delimiter), we
should ensure the operator is not forced into a lot of unnecessary
configuration when 1 or 2 commands would do.

The CLI/UI I proposed in my mail was based on the above two principles.


>
> More comments below [Philippe]
>
>
>
> On Mon, Jun 26, 2017 at 5:59 AM, Vivek Venkatraman <vivek@
> cumulusnetworks.com> wrote:
>
>> Hi Lou, Philippe, All,
>>
>> The PR that I submitted already addresses for the most part inter-subnet
>> routing (i.e., bridge+router scenario) if employing asymmetric routing (
>> https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding section
>> 4). [I say "for the most part" because some additional changes are needed
>> for advertisement of gateway MACIP in the case of centralized gateway and a
>> few other things.] Changes are of course needed for symmetric routing
>> (section 5 of aforementioned draft). I'll describe both of these below.
>>
>> At the end, I'll propose some thoughts on extending this for other EVPN
>> encapsulation - specifically MPLS - to support traditional VPLS.
>>
>> Asymmetric routing:
>>
>> Here, we're dealing only with host routes and the ingress VTEP/NVE will
>> route to the virtual subnet where the destination is, so that the egress
>> VTEP/NVE only does bridging. In VxLAN terms, we're only dealing with L2
>> VNIs which need to be provisioned on all VTEPs. MACs are learnt against a
>> VLAN through kernel notifications, mapped to a VxLAN/VNI and advertised.
>> Likewise, neighbor entries (ARP/ND) are learnt on an SVI by listening to
>> kernel notifications; the mapping to the VxLAN/VNI is straightforward and
>> MACIP routes are originated using this L2 VNI. The logic on the receive
>> side is straightforward too. The received RTs map to the VNI which maps to
>> the VLAN. MAC routes would be installed into the FDB while MACIP routes
>> would result in neighbor entries being created on the SVI (corresponding to
>> the VLAN).
>>
>> The above functionality is all present in the PR submitted. While the
>> target of the PR was just EVPN for L2 with ARP suppression, it can
>> accomplish routing too. Note that ARP suppression requires some additional
>> functionality in the Linux kernel which Cumulus Networks is working to get
>> into the upstream kernel.
>>
>> The only additional provisioning we had planned to introduce was whether
>> to advertise our SVI MAC or not - needed only on gateway devices. This was
>> to be under "address-family l2vpn evpn":
>>
>> router bgp <as>
>>   address-family l2vpn evpn
>>     advertise-default-gateway
>>
>> [Philippe]
> It picks up default gateway MAC address of the local VNI endpoint ?
> This seems ok for local VNI endpoints.
>

Correct. Plus, this is needed only in the centralized gateway scenario, not
in a distributed gateway scenario (where every VTEP/NVE does L2+L3).


>
>
>> However, I'll propose some changes to the provisioning at the end of this
>> note.
>>
>> Symmetric routing:
>>
>> Clearly, this is more scalable and brings in the "inter-connect subnet"
>> (L3 VNI). It also introduces the ability to do prefix routing with EVPN
>> type-5 routes.
>>
>
>
>
>> The L3 VNI is a parameter per tenant - i.e., per L3 VRF. This is planned
>> to be the only required/mandatory configuration on top of what my PR
>> introduces. The tenant (L3 VRF) configuration already exists
>>
>
>
>
>> and the L3 VNI was going to be added to it. The RD and RTs (for the
>> tenant) could be auto-derived from this L3 VNI, but could optionally be
>> configured.
>>
> The planned configuration is/was:
>>
>> router bgp <as> vrf <tenant VRF>
>>   <any existing configuration such as "redistribute connected" or
>> "network">
>>   l2vpn evpn l3vni <vni>
>>   rd <RD>
>>   route-target <import | export | both> <RT>
>>
>
> [Philippe]
> I am not sure about the vty you propose.
> If I understand well, you propose to use l2vpn keyword directly under
> router bgp node ?
>
> (config)# router bgp <> vrf <>
> (bgpd)# l2vpn evpn l3vni <vni>                     <--- added command
> (bgpd)# rd   <>                                               <--- added
> command
> (bgpd)# route-target <>                                <--- added command
> (bgpd)# address-family l2vpn evpn
> (config-router-evpn)# vni <l2vni>
> (config-router-evpn)# ...
> (config-router-evpn)# exit-address-family
> (config-router-evpn)# l2vpn evpn l3vni <l3vni>
>
> If this is it
> -  The relationship between MAC-VRF ( l2vni) and IP-VRF ( the l2vpn evpn
> l3vni configured by RD) is done by the configuration. Right ?
>
>

Yes, because the L3 VNI is an operator configured entity. It is
theoretically possible to auto-generate it, though I don't think that is
well supported by the Linux kernel.

Note that that line - "l2vpn evpn l3vni <vni>" - is the only "new" command
here. The RD and RT configuration is given to complete the layer-3
configuration but would apply for L3VPN also (subject to conclusion on
"vrf-policy" as noted).


>
>> If the community decision is to configure the RD and RT configs as
>> "vrf-policy" against the default VRF in BGP, the above will of course
>> change.
>>
>
>
>
>> The way symmetric routing operates is as follows. There is no change to
>> advertisement or reception of MAC-only type-2 routes, these will only
>> contain the L2 VNI.
>>
>
> [Philippe] Why restrict to sending RT2 L2 VNI only ?
> I should elaborate an example on how vrf-policy configuration would be
> done so as to permit sending RT2 with both labels.
>

I meant for MAC-only routes which don't have an IP address, only the L2 VNI
is relevant. If you have a use case where MAC-only routes also need 2
labels (VNIs), can you explain that?


>
>
>> For MACIP type-2 routes, when the neighbor (ARP/ND) is learnt by
>> listening to a kernel notification, the SVI that the entry is learnt on
>> will be part of the tenant's VRF and that will provide the L3 VNI and L3
>> RTs. The RouterMAC extended community has to be added and the MAC will be
>> derived from the interface corresponding to the L3 VNI (the "inter-connect
>> subnet" interface). On the receive side, if the route has 2 VNIs, the MAC
>> and Neighbor entry will be installed against the L2 VNI (if present
>> locally) as before while the IP host route will be processed and imported
>> into any L3 VRFs (BGP's RIB) that match its RTs.
>>
>
> [Philippe]
> by taking an extract of draft-ietf-bess-evpn-inter-subnet-forwarding
> <https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding>
> "
> While sending RT2 with L3VNI and L2VNI, you must ensure that RTs refer to
> MAC-VRF and IP-VRF ( as per 5.1.1 control plane operation).
> "
> What if there is no L3 VRF Matching locally ? Do you drop the whole
> incoming entry ?
> I think there should be a control on incoming RT2 messages, against RTs.
>

No, the RT2 wouldn't be dropped completely. My understanding is that the
RTs in the incoming RT2 must be matched against BOTH the MAC VRFs (VNIs in
the case of VxLAN) and the IP VRFs, and imported into either or both as
appropriate, IF the RT2 has 2 labels (VNIs).



>
> For that, to differentiate L3VNI from L2VNI, I would add an attribute per
> "vrf-policy" mentioning that this is an IP-VRF or a MAC-VRF.
>
> (vrf-policy)# layer layer_3 | layer_2
>
> How would you do that filtering based on a CE configuration ?
>

Did my response above answer this? If not, I need to understand the
question some more.



>
>
>
>> There is some special handling required because the next hop is the
>> remote VTEP/NVE whose MAC should be set up as the received Router MAC.
>>
>> What the above shows is that there isn't an explicit hierarchy of L2 VNIs
>> (subnets) of a tenant to the tenant's L3 VRF...but it is present implicitly
>> (the SVIs corresponding to those subnets will be assigned to the tenant's
>> VRF).
>>
>> For external routing, the plan is that by default, any routes in the L3
>> VRF (in BGP's RIB) will be advertised to EVPN peers as type-5 routes. The
>> current thought is that this can be controlled using existing route-map
>> constructs (TBD). Internal (i.e., EVPN) routes are already present in the
>> L3 VRF (BGP's RIB) as mentioned above. Existing route-maps can be used to
>> control how these are advertised externally - currently using VRF-lite BGP
>> peerings, in future using L3VPN.
>>
>> For inter-DC connectivity, EVPN single-hop or multi-hop peerings can be
>> setup between the border EVPN routers in each DC. If some/all tenants do
>> not need their L2 domain stretched across the DCs but only need L3
>> connectivity (i.e., subnets contained to one DC), only EVPN type-5 routes
>> need to be exchanged on the inter-DC peering. The current plan is to
>> implement an addition to route-map matching for that - "match evpn
>> route-type <type>".
>>
>>
> [Philippe]
> Indeed Route Type 5 can be used with or without Route Type 2.
> I understand you want to filter out Route Type 2 entries.
>
> It is as if you want to filter only L3 VPN information.
> I woud propose a route-map that filters on L3 messages only ( no
> RT1/RT2/RT3 indeed).
>

The above is an OPTIONAL configuration. If there is EVPN peering between
the DCs (and no other peering), by default, all routes would be exchanged.
In the scenario mentioned (and possibly others), there may be a need to
only exchange a particular type of EVPN route, in addition to other filters
(IP, AS-path etc. already exist, we are adding support for MAC ACLs).


>
> I have a subsidiary question.
> Suppose you have a MPLS based framework, and you want to use MPLSVPN to
> populate the L3VPN of BGP'RIB.Do you have a method to carry that L3
> information in BGP MPLSVPN instead of using BGP EVPN RT5 ?
>

Yes, the way I envision is that there would be L3VPN peering (instead of
EVPN peering) outside of the DC. EVPN routes within the DC would get
installed in the VRF routing table and L3VPN can pick these up and
advertise (with any needed policy control). L3VPN routes from the external
side would again get installed in the VRF routing table and EVPN can pick
these up and advertise as RT5 within the DC. I haven't worked out any
details yet though.


>
>
>
>> Extending/generalizing the provisioning for the non-VxLAN use case:
>>
>
> [Philippe]
> As per draft-ietf-bess-evpn-inter-subnet-forwarding-03
> "The first BGP Extended Community identifies the tunnel
>    type per section 4.5 of [TUNNEL-ENCAP]"
>
> You may need an extra extended community ( see rfc5512) to define the
> encapsulation type wished: VXLAN or other encapsulation type.
>

The PR submitted already carries/exchanges the ENCAP extended community
though it is filled as VxLAN. The proposed config in this mail can be used
to extend this to carry the desired encap.


>
>
>
>>
>> In the case of EVPN for VxLAN, a VLAN is mapped to a VxLAN (VNI) by the
>> operator and whether it is a single broadcast domain per EVI or multiple
>> broadcast domains per VNI, the VNI is sufficient to identify the bridge
>> table as per section 5.1.2 of https://tools.ietf.org/html
>> /draft-ietf-bess-evpn-overlay. This does lend itself to a rather
>> simplified configuration for VxLAN that would be a big advantage to retain.
>>
>> Whether EVPN should be used for VNIs or not (i.e., "advertise-all-vni"
>> under BGP L2VPN/EVPN address-family configuration in my PR) should move to
>> the entity (i.e., zebra) which creates/handles EVIs.
>>
>
> [Philippe]
> I understand you want to have similar command to zebra.
> Nonetheless, I think bgp should keep it too ( for RT auto derivation, but
> also to control zebra events)
>
>
>>
>> The term "vni" is specific to VxLAN and cannot be used for other EVPN.
>> Our preference is for "evi" but it is up to the community to decide whether
>> "evi", "vsi" or something else is the most appropriate.
>>
>
>
>>
>> For VxLAN, it is convenient to refer to the EVI (Ethernet Virtual
>> Instance) by its VNI for the common case; for other cases, there is no such
>> well-known identifier and the EVI is likely to be identified by name (just
>> like a L3 VRF).
>>
>
> [Philippe]
> As per draft-ietf-bess-evpn-inter-subnet-forwarding-03, 5.1.1
>    - Label-1 = MPLS Label or VNID corresponding to MAC-VRF
>    - Label-2 = MPLS Label or VNID corresponding to IP-VRF
>
> It seems VNI can apply to IP-VRF too.
> I would propose to pick up the definition of the draft :
>
> "Label " = "MPLS Label or VNID"
>

Hmm...are you saying to use "label" instead of "vni" in the configuration
commands?


>
>
>>
>> The proposed commands are as follows. These are initial thoughts subject
>> to more refinement - partly because the Linux kernel does not currently
>> have a forwarding model for L2oMPLS.
>>
>> l2vpn evpn advertise-vni <all | list of VNIs>
>> -- The handler of this command will be "zebra" and it is in lieu of the
>> "advertise-all-vni" command as stated above.
>> -- This only applies if using EVPN for VxLAN
>>
>> l2vpn evpn evi <name>
>
>>   encapsulation <vxlan | mpls>
>>   bridge-table <table | bridge-name>
>>   <any MPLS/label allocation parameters - if encap is mpls>
>>   <any VxLAN parameters - if encap is vxlan>
>> -- The above syntax/commands will be used to create EVIs for MPLS, and if
>> needed, for VxLAN.
>> -- The handler of these commands will be "zebra"
>>
>>
> [Philippe]
> BGPd is the only daemon interested in getting the VNI information ?
>

No, zebra continues to be the entity interacting with the kernel, both for
learning all the L2 info (bridges, bridge ports, VLAN-VNI mappings, MACs
etc.) and neighbors as well as installing into the kernel.

We have some nascent thoughts on splitting/reorganizing zebra further, but
nothing planned in the near term and will certainly be discussed in detail
before anything is attempted.



> Also, the current level of FRR deliberately gives EVPN access to VNI only.
> That implies that Ethernet NVO tunnel is neither MPLS nor NVGRE.
>
> If yes, then no need to keep advertise-vni on bgpd.
> If no, then I would want to control the information on both sides.
>
>
>> router bgp <as>
>>   l2vpn evpn { vni <vni> | evi <name> }
>>
> [Philippe]
> I have a configuration issue, if you want to do RT2 emission with both L2
> and L3 Label.
> Could you please elaborate ?
>

It is the presence of this configuration that will determine that RT2
should have a second label. In the case of VxLAN, the L3 VNI value would be
provided here, in the case of MPLS (or something else), the EVI would have
some appropriate configuration to generate this.


>
>
>>     rd <rd>
>>     route-target <import | export | both> <rt>
>> -- The above syntax/commands will be used to define the RD/RT parameters
>> for a VNI/EVI if the auto-derivation is not desired.
>> -- The handler of the above will clearly be "bgpd"
>>
>> The L3 VNI configuration - which is against a L3 VRF - is as proposed
>> earlier.
>>
>> The "advertise-default-gateway" configuration for asymmetric routing can
>> be modified based on the final consensus on the above.
>>
>>
> [Philippe] In the CE purpose, this command is ok for me.
>
> Thanks,
>
> Philippe
>
> >
> > On Tue, Jun 20, 2017 at 9:44 AM, Lou Berger <lberger at labn.net> wrote:
> >>
> >> see below.
> >>
> >>
> >> On 6/20/2017 11:42 AM, Philippe Guibert wrote:
> >> > Hi Lou, Vivek,
> >> >
> >> > inline my comments,
> >> >
> >> >
> >> > On Mon, Jun 19, 2017 at 4:51 PM, Lou Berger <lberger at labn.net> wrote:
> >> >>
> >> >> On 6/17/2017 1:25 AM, Vivek Venkatraman wrote:
> >> >>> Hi Lou and Philippe,
> >> >>>
> >> >>> Besides the provisioning angle, how these entities map to current
> data
> >> >>> structures and code flow also is a consideration, IMO. Everything
> >> >>> about the current VRF ('struct bgp' or 'struct zebra_vrf' or soon to
> >> >>> be introduced support for OSPF) pertains to a Layer-3 routing
> >> >>> instance. I'm not sure it is a good idea to either morph that
> >> >>> construct into a Layer-2 (bridging) instance too or try to envelope
> a
> >> >>> Layer-2 instance and a Layer-3 instance under something else (like
> >> >>> "network-instance").
> >> >> What are your thoughts on when we get to bridge+router capability?
> >> >> Allowing for this is part of what drove my comments.
> >> >>
> >> >> I have a fair bit of this in a prototype using rfapi and openflow,
> but
> >> >> not quete working or in sharable form.  (Just need to find a few days
> >> >> to
> >> >> code!)
> >> >>
> >> >>> My line of thinking after discussion with a few of my colleagues is
> as
> >> >>> follows:
> >> >>>
> >> >>> 1. We should keep Layer-3 instance and Layer-2 instance
> configuration
> >> >>> distinct, though there may be some common parameters that both have.
> >> >> Again, we can't forget about the real case of bridge routers and
> cause
> >> >> us problems down the road.
> >> > I am not sure about that.
> >> > Right now, I don't have the exact use case that shows that. I will
> >> > give more information later.
> >> > What I mean is that there may be some instances that can get both L3
> >> > and L2 information.
> >> > As far as I know, this is the case for RT2 entries with two labels
> >> > inside.
> >> from the bgp distribution side, there is both a (L2VPN) mac and (L3VPN)
> >> CE-advertised/PE-learned route to distribute in this case.
> >>
> >> >
> >> >>> 2. While internal semantics indicate some parameters are "CE
> related"
> >> >>> and other parameters are "PE related", there are instances where it
> >> >>> can be argued either way. In any case, it would be easier for the
> >> >>> user/operator to have the configuration for one entity in one place,
> >> >>> as much as possible.
> >> >> I think your distinction is customer-facing (within VRF/VSI) and
> >> >> provider-facing (within core/provider transport), right?
> >> >>
> >> >>> 3. The reference to "VNI" directly and some aspects of the
> >> >>> configuration syntax in my PR make it too specific to EVPN for
> VxLAN.
> >> >>> This should be made more generic.
> >> >> Does VSI work for you?
> >> > Does VSI covers MPLs labels ?
> >> I think of VSI = VRF for L2.  So labels may or may be used based on
> >> config.
> >>
> >> Lou
> >>
> >> >
> >> >>> 4. There are certain aspects though about EVPN for VxLAN that allow
> >> >>> for auto-creation and auto-derivation for which allowance has to be
> >> >>> made. For e.g., I'm sure an operator wouldn't want to configure a
> >> >>> named-instance for each VNI on the system when the VNI itself can be
> >> >>> the key and can be learnt by the routing control plane from the
> >> >>> kernel.
> >> >>>
> >> >>> With these in mind, I'll discuss a proposal with my colleagues
> before
> >> >>> bringing it here for further discussion next week.
> >> >>>
> >> >> Excellent!
> >> > ++1
> >> >
> >> > Philippe
> >> >
> >> >
> >> >
> >> >>>
> >> >>> On Thu, Jun 15, 2017 at 6:53 AM, Lou Berger <lberger at labn.net
> >> >>> <mailto:lberger at labn.net>> wrote:
> >> >>>
> >> >>>     Philippe,
> >> >>>
> >> >>>     I agree with your analysis.  One additional point bellow.
> >> >>>
> >> >>>
> >> >>>     On 6/15/2017 9:18 AM, Philippe Guibert wrote:
> >> >>>     > Hi Vivek,
> >> >>>     >
> >> >>>     > I just saw Lou's reply message.
> >> >>>     > Initial agreement was using vrf-policy under bgp node.
> >> >>>     > If I understand correctly, there is kind of redundancy with
> EVPN
> >> >>>     > address-family vni configuration command used on CE side.
> >> >>>     >
> >> >>>     > Your remark is very interesting. I think it is worth looking
> at
> >> >>>     how to
> >> >>>     > fuse both configuration ways.
> >> >>>     > Please find below some remarks on what could be done.
> >> >>>     >
> >> >>>     >> In addition, there are commands to configure the RD and RTs
> if
> >> >>>     >> auto-derivation is not desired - for e.g., peering with
> >> >>>     third-party BGP
> >> >>>     >> system. The syntax for this is shown through an example
> >> >>>     configuration below
> >> >>>     >> (which also shows steps #1 and #2).
> >> >>>     >>
> >> >>>     >> router bgp 65001
> >> >>>     >>  address-family l2vpn evpn
> >> >>>     >>   neighbor SPINE activate
> >> >>>     >>   vni 10100
> >> >>>     >>    rd 1:10100
> >> >>>     >>    route-target import 1:10100
> >> >>>     >>   exit-vni
> >> >>>     >>   advertise-all-vni
> >> >>>     >>  exit-address-family
> >> >>>     >>
> >> >>>     >> I see it as being very useful to have all the configuration
> >> >>>     relevant to a
> >> >>>     >> VRF (or VNI) in one place.
> >> >>>     > Thanks for point out that. I agree with you
> >> >>>     >
> >> >>>     >> One topic of discussion is regarding this optional VNI
> >> >>>     configuration.
> >> >>>     >> Instead of the keyword being "vni", should it be "vni-policy"
> >> >>>     to match with
> >> >>>     >> "vrf-policy"?
> >> >>>     > If we want to have a common vty node to enter the
> information, I
> >> >>>     would
> >> >>>     > like to draw your attention to the following:
> >> >>>     > - This vty node should be used for not only EVPN,but also
> VPNVx
> >> >>>     > address families.
> >> >>>     > The vni value used should be an attribute of that VPN object (
> >> >>> since
> >> >>>     > vxlan does not apply to VPNVx afi/safi).
> >> >>>     > This vty node should be moved from evpn address-family to bgp
> >> >>> node.
> >> >>>     >
> >> >>>     > - This vty node stands for a VRF that should be used.
> >> >>>     > It is true that in comparison to route-map concept, the
> >> >>> "vrf-policy"
> >> >>>     > wording could be improved.
> >> >>>     > But we have to distinguish the vtynode from VRF node that is
> >> >>> used
> >> >>>     > outside of BGP node.
> >> >>>     >
> >> >>>     > Based on vrf-policy wording, the subnode vty commands should
> be
> >> >>>     added
> >> >>>     > vni keyword.
> >> >>>     This would also work nicely for the future case where the VNI
> is a
> >> >>>     bridge/router. it would just fall out by specifying a valid vrf
> >> >>>     name in
> >> >>>     the vrf-policy.  Although this does lead to the slightly ugly
> case
> >> >>> of
> >> >>>     needing to rename the 'policy' when associating a running
> VNI/VSI
> >> >>>     (bridge) with a VRF.  perhaps it makes sense to uncouple of the
> >> >>>     binding
> >> >>>     of the "policy" with the VRF name and VSI/VNI ID.  e.g.,
> >> >>>
> >> >>>
> >> >>>      network-instance <node-name>
> >> >>>        !when associated with a named BGP VRF
> >> >>>         vrf <vrf-name>
> >> >>>        !when associated with a vni
> >> >>>         vni <vni-id>
> >> >>>         rd <value>
> >> >>>         rt (import|export|both) <value> [<value-list>]
> >> >>>         label <value>
> >> >>>         route-map <mapname>
> >> >>>         tunnel advertisement-method <encap-attribute|evpn>
> >> >>>         tunnel type
> >> >>> (none|l2tpv3overip|gre|ipinip|vxlan|mpls|mplsovergre)
> >> >>>
> >> >>>
> >> >>>     The name network-instance comes from
> >> >>>         https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model
> >> >>>     <https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model>
> >> >>>
> >> >>>     An alternative is to not add vrf/vni above and do something like
> >> >>>      router bgp XXX vrf <vrf-name>*
> >> >>>        network-instance <node-name>
> >> >>>
> >> >>>     and under a new bgp vsi (I like the more generic name VSI over
> >> >>>     VNI) node
> >> >>>       vsi <vni-id>
> >> >>>        network-instance <node-name>
> >> >>>
> >> >>>     but then it's up to the config reader to notice when something
> is
> >> >>>     a bridge and/or router instance.  (so I prefer the first
> >> >>>
> >> >>>
> >> >>>     > Vivek, those changes have also wider impact, I mean, at least
> >> >>>     > internally in the BGP daemon.
> >> >>>     > I list some of the changes that may be done, if we merge [both
> >> >>> vty
> >> >>>     > nodes in a single one.
> >> >>>     >
> >> >>>     > - The VRF configuration calls VNC code, while VNI
> configuration
> >> >>>     calls
> >> >>>     > bgp_evpn_vty.c code.
> >> >>>     > This should be put in a separate file. A registration
> mechanism
> >> >>> with
> >> >>>     > EVPN and VNC could apply.
> >> >>>     Yes this would need to change.
> >> >>>
> >> >>>     > - Some other attributes of EVPN ( RD and RT auto derivation)
> >> >>>     could be
> >> >>>     > configurable within that new VRF instance.
> >> >>>     >
> >> >>>     > - Also, regarding the advertise-all-vni command, does that
> mean
> >> >>> that
> >> >>>     > such VNI ( VRFs objects ) should be instantiated too ?
> >> >>>     > I mean, I am sorry, I did not attend the specific EVPN meeting
> >> >>> you
> >> >>>     > lead a few weeks ago. I know Lou was there.
> >> >>>
> >> >>>     > Perhaps you talked about the way to exchange VNI information
> >> >>> between
> >> >>>     > EVPN and VNC ?
> >> >>>     We did, but all future (non blocking) stuff.  The sole blocking
> >> >>> issue
> >> >>>     from my perspective is resolving this discussion.
> >> >>>
> >> >>>     Lou
> >> >>>
> >> >>>     > Regards,
> >> >>>     >
> >> >>>     > Philippe
> >> >>>     >
> >> >>>     >
> >> >>>     > [0]
> >> >>>
> >> >>> https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_
> XN5yz33MMNNqM/edit#
> >> >>>
> >> >>> <https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_
> XN5yz33MMNNqM/edit#>
> >> >>>     >
> >> >>>     >
> >> >>>     >
> >> >>>     >
> >> >>>     >> I don't think "vni-policy", or for that matter, "vrf-policy"
> is
> >> >>>     the best
> >> >>>     >> choice due to the following two main reasons:
> >> >>>     >>
> >> >>>     >> 1. A "policy" is a fairly familiar construct in routing
> >> >>>     parlance. It
> >> >>>     >> commonly refers to a set of rules or definitions that are
> >> >>>     generically
> >> >>>     >> specified and can then be applied to different "attach
> points".
> >> >>>     In FRR, a
> >> >>>     >> "route-map" would be a good example of such a policy. It may
> be
> >> >>>     misleading
> >> >>>     >> to call the specific configuration for a VNI or VRF as
> >> >>> "policy",
> >> >>>     >> particularly when the VNI/VRF may later support import/export
> >> >>>     policies
> >> >>>     >> (route-maps).
> >> >>>     >>
> >> >>>     >> 2. The configuration syntax that emerged for VRFs after the
> >> >>>     last round of
> >> >>>     >> discussions separates out the "CE side" configuration (e.g.,
> CE
> >> >>>     neighbors,
> >> >>>     >> redistribution etc.) from the "PE side" configuration (e.g.,
> RD
> >> >>>     and RT
> >> >>>     >> configuration). From the user/operator's perspective, I do
> not
> >> >>>     see any value
> >> >>>     >> add in this separation, only a potential source of confusion
> >> >>>     since the same
> >> >>>     >> entity (VRF) needs to be configured in multiple places. It
> can
> >> >>>     also be
> >> >>>     >> debatable where a configuration lies. For e.g., should
> >> >>>     "vrf-import-policy"
> >> >>>     >> reside on the "PE side" as it deals with received L3VPN
> routes
> >> >>>     or on the "CE
> >> >>>     >> side" as it decides which routes to import into which VRF
> >> >>> table?
> >> >>>     >>
> >> >>>     >> I see it as being very useful to have all the configuration
> >> >>>     relevant to a
> >> >>>     >> VRF (or VNI) in one place.
> >> >>>     >>
> >> >>>     >> The purpose of this email is to solicit wider feedback since
> >> >>>     only a few
> >> >>>     >> people participated in the earlier discussion and their
> >> >>>     positions are very
> >> >>>     >> likely unchanged. My suggestion would be to have the initial
> >> >>>     deliberations
> >> >>>     >> on the list and if that does not converge or indicates the
> need
> >> >>>     for a
> >> >>>     >> meeting, the maintainers will call one.
> >> >>>     >>
> >> >>>     >> Based on the consensus that emerges, I shall update my PR
> >> >>>     and/or introduce
> >> >>>     >> modifications in a subsequent PR - if needed.
> >> >>>     >>
> >> >>>     >> Vivek
> >> >>>     >>
> >> >>>     >>
> >> >>>     >> _______________________________________________
> >> >>>     >> dev mailing list
> >> >>>     >> dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>
> >> >>>     >> https://lists.frrouting.org/listinfo/dev
> >> >>>     <https://lists.frrouting.org/listinfo/dev>
> >> >>>     >>
> >> >>>
> >> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20170712/a2d0543b/attachment-0001.html>


More information about the dev mailing list