Re: [nvo3] The way forward
"Ali Sajassi (sajassi)" <sajassi@cisco.com> Tue, 04 March 2014 00:24 UTC
Return-Path: <sajassi@cisco.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310031A0192 for <nvo3@ietfa.amsl.com>; Mon, 3 Mar 2014 16:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.047
X-Spam-Level:
X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY8bK-26rj1a for <nvo3@ietfa.amsl.com>; Mon, 3 Mar 2014 16:24:26 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 172311A00C9 for <nvo3@ietf.org>; Mon, 3 Mar 2014 16:24:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6785; q=dns/txt; s=iport; t=1393892664; x=1395102264; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ORoFCitsrhjqKN3XHsWCcEAdKgtI217qyGdSe3axS08=; b=eu3QvhrIRrb4KTYJI0B3vRgMnf/5LN38RgfpjNlvQulyFXSYw3st4cIn ysocEeS8ETyHSUASn+KtRIszOmU87iMR8Cf83vkoQgRhXsnSWLhI400yv vifuO/533Js7hmJ2jat2P8s/qo2I8h03PEpxekBcFSkhBeImgC9jQ31NY U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkEJAKUcFVOtJV2d/2dsb2JhbABagkQjIThVhCGvVohTgSEWAXSDfQECBIELAQgRAwECKDkUCQgCBAESG4dpAQzEIxePARiENgSYFoEwkGSDK4Iq
X-IronPort-AV: E=Sophos; i="4.97,863,1389744000"; d="scan'208,217"; a="304755959"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 04 Mar 2014 00:24:23 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s240OMAq030690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 00:24:22 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 18:24:21 -0600
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "Yves Hertoghs (yhertogh)" <yhertogh@cisco.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-ietf-nvo3-gap-analysis@tools.ietf.org" <draft-ietf-nvo3-gap-analysis@tools.ietf.org>
Thread-Topic: [nvo3] The way forward
Thread-Index: AQHPNu6SJuYLWlL4wU2ovmFadBpXuJrQduMA
Date: Tue, 04 Mar 2014 00:24:21 +0000
Message-ID: <CF3AC908.C2949%sajassi@cisco.com>
In-Reply-To: <CF3A5302.2F89E%yhertogh@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [10.89.3.229]
Content-Type: multipart/alternative; boundary="_000_CF3AC908C2949sajassiciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/nvo3/-GGYrbtTZVmQYwVhfggPYlK0efY
Subject: Re: [nvo3] The way forward
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 00:24:29 -0000
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)" <yhertogh@cisco.com<mailto:yhertogh@cisco.com>> Date: Monday, March 3, 2014 6:40 AM To: "nvo3@ietf.org<mailto:nvo3@ietf.org>" <nvo3@ietf.org<mailto:nvo3@ietf.org>>, "draft-ietf-nvo3-gap-analysis@tools.ietf.org<mailto:draft-ietf-nvo3-gap-analysis@tools.ietf.org>" <draft-ietf-nvo3-gap-analysis@tools.ietf.org<mailto:draft-ietf-nvo3-gap-analysis@tools.ietf.org>> 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
- [nvo3] The way forward Yves Hertoghs (yhertogh)
- Re: [nvo3] The way forward Ali Sajassi (sajassi)
- Re: [nvo3] The way forward Yves Hertoghs (yhertogh)