[lisp] Lisp to Nvo3

Sharon <sbarkai@gmail.com> Wed, 01 April 2015 03:58 UTC

Return-Path: <sbarkai@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A411A7023 for <lisp@ietfa.amsl.com>; Tue, 31 Mar 2015 20:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 GZBYTCQJskey for <lisp@ietfa.amsl.com>; Tue, 31 Mar 2015 20:58:45 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467A71A702A for <lisp@ietf.org>; Tue, 31 Mar 2015 20:58:43 -0700 (PDT)
Received: by padcy3 with SMTP id cy3so39481924pad.3 for <lisp@ietf.org>; Tue, 31 Mar 2015 20:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=zTzn5r4icwaY44k5x53e684XkP6LjIHWfs4iULTbHYg=; b=a2e6INlfzXoEsElvLiVIDb7Uc0kFb6iWsuxieDAxdB3jfgKXenv3qkBDYuJz18enls mfSAbE3dMxPh0WawfjrUesXGsCLQMHwjwf0nILsUrpPE2XCbEhvk0VJJ1RhHVYCWeVCb 8gzfJnJ1xPQnOuKArbUeKffHkjtDyDXmf42GSOreh2xV9e1Z6s/QoKI7WxGv2DUabZ2o zc0olSH9nC4rBxANfd5qYv6hCztic6olAD63qaym+PgMDN8ncnpYQkW1bfNsD7Px24v+ iJaFWlGH0Mnxzyo+Alpf9XzjPLOvypB/4NR6rMPpjhlCiGzMHfMO0fVwV/pl6pMe/2kY DbyA==
X-Received: by 10.69.0.163 with SMTP id az3mr72807659pbd.21.1427860722963; Tue, 31 Mar 2015 20:58:42 -0700 (PDT)
Received: from ?IPv6:2601:9:8380:447:8940:ec7c:e65e:6cf8? ([2601:9:8380:447:8940:ec7c:e65e:6cf8]) by mx.google.com with ESMTPSA id jc9sm438779pbd.54.2015.03.31.20.58.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 20:58:41 -0700 (PDT)
From: Sharon <sbarkai@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Tue, 31 Mar 2015 20:58:38 -0700
Message-Id: <2DB9153F-698C-4228-A01B-34EBB4112664@gmail.com>
To: LISP mailing list list <lisp@ietf.org>
X-Mailer: iPhone Mail (12D508)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/PjZXM_UqJVwNtsFjLTxatDtm7as>
Subject: [lisp] Lisp to Nvo3
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 03:58:47 -0000

In the short re-charter discussion there was a proposal to offer lisp architecture (with multi encapsulations option) as one of the possible control planes for nvo3.

There was a comment regarding inter-networking with legacy vpn.
We recently faced such a requirement for service provider-anchored VPN overlays. 
These VPN overlays are implemented such that the "real" XTRs are in the provider regional data centers, while "satellite" XTRs at customer premise use them as anchors and do not use the mapping directly.

Much like Vina's NAT traversal draft. 

This makes it easier to cluster virtual network functions next to the "real" XTRs, same rack, and share their capacity across XTRs over the high speed core underlay.

The point is that the inter-networking - into and out of the VPN Overlay - is handled, much like any other "extra" functionality over basic lisp. It is handled the NFV way. 
This means that the complexity of external BGP talkers to other VPNs or to the Internet routers is locked inside the VNFs, and the capacity of these VNFs is shared across the VPN held by the XTRs using the mapping service as global locator.
Similar to the multicast replication function proposal, or similar to how firewall functions are chained, using SFC.

Is there interest in such a draft? There should probably be a common part applicable to any function, eg the Schema for instances, scoping of each, affinity for the return path, and  locations (as in RLOCs), in the mapping. 
Then specifically for the inter VPN VNF what is the lisp FlowMapping behavior in each of the XTRs to accommodate. Alternately we can also take it a function at a time.

--szb