[ixpmanager] VPLS/EVPN support

[Nick Hilliard]

Following up on Barry's email, we recently deployed vxlan at INEX and at
the same time restructured things so that the entire switching
configuration (except for test / temporary ports) is handled via napalm.
 Currently there are 4 separate templates:

- general switch config
- bgp + vxlan config
- member port configuration
- core port configuration

As we didn't really know exactly what we'd need before going into this,
we prototyped up an abstraction layer in YAML and are still using this
internally for building the entire core network configuration.  Yann is
in the process of building this out in IXP Mangager at the moment, and
all the information required to build out the infrastructure will be
provided on API handles.

The orchestration is handled using SaltStack, but there's no reason that
NAPALM couldn't use ansible instead.  We only chose Salt because we use
it internally for everything else.

Regarding the bridging mechanism on the network side, I would advise
against VPLS.  Because it uses mpls as the overlay, it's difficult to
get core LAG load balancing working well using mpls l2vpn.  The reason
is that the hashing algorithm used by the forwarding chipsets tends not
to be able to inspect into the l3/l4 headers to get optimal per-stream
hashing, and FAT-PW is not widely available.  Even on some of the bigger
and more expensive platforms, the workaround is to use multiple LSPs
between each router (typically twice the number of bundle members of the
LAG/ECMP link with the largest number of members), but that ends up with
O(n^2) LSPs being built on the network which causes both a configuration
complexity problem and also a performance scaling problem in the case
where you have link failures and you suddenly need to reroute thousands
of LSPs.

All these problems are solved with vxlan, which uses a UDP pseudo source
port which is randomised on ingress with the hash of the original
packet, so the problem completely disappears, which means that switch
configuration is simple layer 3 without any messing around.  Over time,
EVPN will mature in a standardised way (draft-ietf-bess-evpn-overlay),
and switch manufacturers will move to supporting arp/nd proxy, allowing
MAC address distribution over bgp.  But for the moment,
mac-learning-via-UU and static BUM endpoint configuration works fine and
is completely portable across different platforms.

Nick

Barry O'Donovan wrote:
> Hi Andreas,
> 
> we looked at VPLS before and it was a nightmare. We've instead moved to
> VXLAN so we have no internal plans at looking at VPLS.
> 
> EVPN however is something we're very interested in (EVPN+VXLAN) and will
> be looking at. The L2 ACLs I mentioned in the previous email relate to
> that by adding API endpoints to allow one to feed a MP-BGP EVPN instance
> with l2 addresses and end arp'ing / dynamic l2 fdbs.
> 
>  - Barry
> 
> Andreas Polyrakis wrote:
>> Hello again,
>>
>> Following my previous email, I would like to ask if you plan to support
>> VPLS or EVPN setups.
>>
>> (I create a separate thread for this, so as to not to mix up replies for
>> the two related but separate discussions)
>>
>> Regards,
>>
>