[nvo3] Requirements + some non-requirement suggestions
<david.black@emc.com> Mon, 09 April 2012 20:53 UTC
Return-Path: <david.black@emc.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B721F87F8 for <nvo3@ietfa.amsl.com>; Mon, 9 Apr 2012 13:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.218
X-Spam-Level:
X-Spam-Status: No, score=-110.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxBYnOTeGwAe for <nvo3@ietfa.amsl.com>; Mon, 9 Apr 2012 13:53:01 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 779B421F87EE for <nvo3@ietf.org>; Mon, 9 Apr 2012 13:52:57 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q39KqpwI032614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nvo3@ietf.org>; Mon, 9 Apr 2012 16:52:53 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for <nvo3@ietf.org>; Mon, 9 Apr 2012 16:52:44 -0400
Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q39Kqd6N000701 for <nvo3@ietf.org>; Mon, 9 Apr 2012 16:52:44 -0400
Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 9 Apr 2012 16:51:30 -0400
From: david.black@emc.com
To: nvo3@ietf.org
Date: Mon, 09 Apr 2012 16:51:30 -0400
Thread-Topic: Requirements + some non-requirement suggestions
Thread-Index: Ac0WkooKHLYjWW1MQ/qsIoEmbvWQQQ==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE712034117@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [nvo3] Requirements + some non-requirement suggestions
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "L2 \"Network Virtualization Over l3\" overlay discussion list \(nvo3\)" <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: Mon, 09 Apr 2012 20:53:01 -0000
> Dave McDyson asked about three classes of connectivity: > > 1) a single data center > 2) a set of data centers under control of one administrative domain > 3) multiple sets of data centers under control of multiple > administrative domains > > Which of these do we *need* to address in NVO3? I agree with a number of other people that we have to start with 1), and then I'd suggest addressing as much of 2) as "makes sense" without significantly affecting the design and applicability of the result to data centers. For example, a single instance of an overlay that spans data centers "makes sense", at least to me, or as Thomas Narten described it: > two DCs are under the same administrative domain, but are > interconnected by some (existing) VPN technology, of which we don't > care what the details are. The overlay just tunnels end-to-end and > couldn't care less about the existence of a VPN interconnecting parts > of the network. Looking at draft-meyer-loc-id-implications-01: http://tools.ietf.org/html/draft-meyer-loc-id-implications-01 I would suggest that for initial nvo3 work, reachability between all NVEs in a single overlay instance should be assumed, as there will be an IGP routing protocol (e.g., OSPF with ECMP) running on the underlying data center network which will handle link failures. Specifically, for initial nvo3 work I'd suggest assuming that the underlying network handles reachability of the NVE at the other side of the overlay (other end of the tunnel) that does the decapsulation. In terms of that draft, within a single data center (and hence for the scope of initial nvo3 work), I'd suggest that the underlying network be responsible for handling the Locator Path Liveness problem. This suggestion also applies to the Multi-Exit problem, although on a related note, I think it's a good idea to make sure that nvo3 doesn't turn any crucial NVE into a single point of failure. Techniques like VRRP address this in the absence of nvo3, so this could be mostly a matter of paying attention to ensure that they're applicable to NVE failure. Regardless of whether things work out that way, I'd suggest that availability concerns be in scope. Turning to the topic of IGP metrics and "tromboning", I'd suggest that having nvo3 add a full IGP routing protocol (or even an IGP metrics infrastructure for one that has to be administered) beyond what's already running in the underlying network is not a good idea. It seems like a large portion of the "tromboning" concerns could be resolved by techniques that distribute the default gateway in a virtual network so that moving a VM (virtual machine) automatically sends traffic to the locally-applicable instance of the default gateway for the VM's new location, based on the same L2 address. There are multiple examples of this sort of approach - OTV and draft-raggarwa-data-center-mobility-02 are among them. One more - Peter Ashwood-Smith writes: > Is it a requirement to support different tunnel encapsulation types in the same DC? > > It would seem that a very large DC could well end up with several different kinds of > tunnel encapsulations that would need to somehow be bridged if they terminate VMs in > the same subnet. I'd suggest that the latter scenario be out of scope and that crossing virtual networks initially involve routing in preference to bridging, so that an NVE receiving an unencapsulated packet can determine the overlay and encapsulation by knowing which virtual network the packet belongs to. An implication is that I'd suggest figuring out how to optimize the following structure into a single network node later (or at least as a cleanly separable work effort: ... (Overlay1)---- NVE1 ---- (VLANs) ---- NVE2 ---- (Overlay2) ... In the above, NVE1 and NVE2 are separate nodes, and the parenthesized terms are the means of virtual network separation. That suggests that a starting point for whether different tunnel encapsulation types should be supported in a single data center could be "if they don't have an NVE node in common, they can be made to work" and optimizations can be considered later. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------
- [nvo3] Requirements + some non-requirement sugges… david.black
- Re: [nvo3] Requirements + some non-requirement su… Anoop Ghanwani
- Re: [nvo3] Requirements + some non-requirement su… David Meyer
- [nvo3] VLANs between overlays david.black
- Re: [nvo3] VLANs between overlays John E Drake
- [nvo3] Reachability and Locator Path Liveness david.black
- Re: [nvo3] Reachability and Locator Path Liveness Joel M. Halpern
- Re: [nvo3] Reachability and Locator Path Liveness david.black
- Re: [nvo3] Reachability and Locator Path Liveness David Meyer
- Re: [nvo3] Reachability and Locator Path Liveness David Meyer
- Re: [nvo3] Reachability and Locator Path Liveness Robert Raszuk
- Re: [nvo3] Reachability and Locator Path Liveness Dino Farinacci
- Re: [nvo3] VLANs between overlays Pat Thaler
- Re: [nvo3] Reachability and Locator Path Liveness AshwoodsmithPeter
- Re: [nvo3] Reachability and Locator Path Liveness david.black
- Re: [nvo3] Reachability and Locator Path Liveness David Allan I
- Re: [nvo3] Reachability and Locator Path Liveness Santosh Rajagopalan
- Re: [nvo3] VLANs between overlays Roger Jørgensen
- Re: [nvo3] Reachability and Locator Path Liveness Thomas Narten
- Re: [nvo3] Reachability and Locator Path Liveness Thomas Narten
- Re: [nvo3] Reachability and Locator Path Liveness Robert Raszuk
- Re: [nvo3] Reachability and Locator Path Liveness Thomas Narten
- Re: [nvo3] VLANs between overlays david.black
- [nvo3] Topology david.black
- Re: [nvo3] Topology LASSERRE, MARC (MARC)
- Re: [nvo3] VLANs between overlays AshwoodsmithPeter
- Re: [nvo3] Topology Thomas Narten
- Re: [nvo3] VLANs between overlays Paul Unbehagen
- Re: [nvo3] Topology LASSERRE, MARC (MARC)
- Re: [nvo3] VLANs between overlays Balus, Florin Stelian (Florin)
- Re: [nvo3] VLANs between overlays Dino Farinacci
- Re: [nvo3] Reachability and Locator Path Liveness Stiliadis, Dimitrios (Dimitri)
- Re: [nvo3] Reachability and Locator Path Liveness Stiliadis, Dimitrios (Dimitri)
- Re: [nvo3] VLANs between overlays Roger Jørgensen
- Re: [nvo3] Reachability and Locator Path Liveness Vishwas Manral
- Re: [nvo3] Topology Anoop Ghanwani