Re: [nvo3] The way forward

["Yves Hertoghs (yhertogh)" <[e-mail]>]

Ali,

I realise this means more work for you, but the gap analysis draft people are looking for more draft like http://tools.ietf.org/html/draft-hertoghs-nvo3-lisp-controlplane-unified-00 for other control planes ie BGP.
Would you or any other be able to adapt the draft you mentioned to be more inline with the current requirement drafts in NVO3?

Yves

From: Ali Sajassi <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 4 March 2014 01:24
To: Yves Hertoghs <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [nvo3] The way forward


Yves,

Just a minor correction that the following EVPN draft covers both VXLAN and NVGRE encapsulation for DC applications and it has been around for over a year with multiple vendors implementing it.

http://tools.ietf.org/id/draft-sd-l2vpn-evpn-overlay-02.txt

I agree with rest of the things that you are saying. I think a cleaner comparison would be to compare different control-plane solutions such as EVPN, IP-VPN, LISP (columns of a table) against a set of functionalities (rows of tables) that you mentioned below with each entry in the table to indicate whether that functionality is supported and if so with what encap.

Cheers,
Ali

From: "Yves Hertoghs (yhertogh)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, March 3, 2014 6:40 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [nvo3] The way forward

Folks.

To pick up the discussion on the list where we left off.

Currently we have VXLAN/NVGRE/EVPN/IP-VPN/VPLS in there as ‘potential solutions’.  These solutions dont compare at all.  VxLAN/NVGRE/VPLS all use flood-and-learn as a control plane + some ways of creating the emulated ethernet service end to end.  IP-VPN and E-VPN uses BGP as a control plane, but in its current form is using an MPLS or MPLSoGRE encapsulation.

NVO3’s aim was to see how the defacto encapsulations like VXLAN and NVGRE would need to evolve from a control plane perspective to support a greater set of services, remove the need for multicast, add more scale , etc.

So why are we comparing these 5 options ? Sounds like comparing bananas to kiwis to me.

Secondly, i though there was a rough consensus that we should ‘choose’ a couple of encapsulation (like e.g. VXLAN, VXLAN-GPE, NVGRE, etc), and then see how existing control planes would work across these encapsulations, to both setup connectivity/create the tunnels, as well as carrying the reachability information. Draft-nvo3-hertoghs is doing essentially that, for LISP.    Wouldn’t that be a better way forward going forward?

Yves