Re: [lisp] LISP SDN

Dino Farinacci <farinacci@gmail.com> Mon, 17 February 2014 18:26 UTC

Return-Path: <farinacci@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 C30671A050E for <lisp@ietfa.amsl.com>; Mon, 17 Feb 2014 10:26:24 -0800 (PST)
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 mCbVl37Z6c_L for <lisp@ietfa.amsl.com>; Mon, 17 Feb 2014 10:26:22 -0800 (PST)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9FB1A0239 for <lisp@ietf.org>; Mon, 17 Feb 2014 10:26:22 -0800 (PST)
Received: by mail-pd0-f180.google.com with SMTP id x10so15254241pdj.11 for <lisp@ietf.org>; Mon, 17 Feb 2014 10:26:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vxevk84Cx0bGDpdY9Lyz4ho2zi5OiTDlOg8WeujXV80=; b=FMJKjqC8NWJNJC4ZP7iRcfhU4n1UUsBBo1TfVoZq2Rr+okrQImwILtTUhoOHq2ozXd R+o/dPeBBSdNVixQGpHkgTzB3NhWKhSJCMLOH+tyS1M/STRm+fndZlhbOvf80DjocTaC h42kVrYHmre37UdB65Ihz3qOzbrb9jUgi7+oBgsrgwJAa5mZQwbE/TZ91AJiwJXkyjSp +f+r0yb0SoVK6S92tMys4rk8Ra5Eq4gYnFuM3CCpEqLjUeWPGW+/UvrAib7KFCuZkGxj lmKGWUBT90BKgotKtb6/bYnrtNFkzVspNHJYLBFFV5HS3aiVR5gK6seVXuYGzirw1EqV n8tA==
X-Received: by 10.66.149.37 with SMTP id tx5mr27679559pab.81.1392661579762; Mon, 17 Feb 2014 10:26:19 -0800 (PST)
Received: from [10.0.1.3] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id af1sm8344511pad.12.2014.02.17.10.26.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 10:26:18 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <E7F7C080-38DF-4AF7-B0AD-CB0F95D74BBD@cisco.com>
Date: Mon, 17 Feb 2014 10:26:17 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <541586E7-DB4A-4E42-AE48-24772FB8D7A2@gmail.com>
References: <CA+YHcKF5aUK-ADsxaE7W1T9DmkON51LogDdDXVEWTq1jF5tDDA@mail.gmail.com> <530244E4.4060906@joelhalpern.com> <E7F7C080-38DF-4AF7-B0AD-CB0F95D74BBD@cisco.com>
To: "Michiel Blokzijl (mblokzij)" <mblokzij@cisco.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/FSt9c91G3zgR-XUoCVh8Ga-BSNI
Cc: "lisp@ietf.org" <lisp@ietf.org>
Subject: Re: [lisp] LISP SDN
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: Mon, 17 Feb 2014 18:26:25 -0000

I agree the title needs to be more specific.

Dino

On Feb 17, 2014, at 9:59 AM, Michiel Blokzijl (mblokzij) <mblokzij@cisco.com> wrote:

> Hi,
> 
> After reading this draft, I recognised the idea of using 5-tuples from the LISP flowmapping project (I think there was another draft out there on that, maybe it was https://tools.ietf.org/html/draft-barkai-lisp-nfv-02).
> 
> I think it might be a good idea to give this draft a more specific title.
> 
> "SDN" itself is already a big term, and "SDN extensions for LISP" IMHO could, and probably should, including everything from the Yang datamodel over how using more direct APIs can be used with LISP xTRs for interesting effects (see example below) up to how applications might tell LISP something about how priorities and weights should be set (this could happen both on an IP address level as well as on a flow level), through sending LISP packets or otherwise.. or the controlplane/dataplane separation that seems to be used often as SDN definition..
> 
> I don't mind us having an "umbrella draft" called "SDN extensions for LISP" that contains a catalogue of drafts in all these areas though, but I think it'd be a good idea to keep the technical drafts focused on something more specific.
> 
> Best regards,
> 
> Michiel
> 
> example of how direct APIs can be used:
> In a LISP mobility setup (like the one that ships in the Cisco OSes) it might be useful to have an API for telling an xTR whether or not a mobile host is local to this xTR or not. This could then be called by an orchestration systems plugin, which has access to "ground truth" data about VMs' locations; currently I believe we detect host presence by looking at traffic and other, "non-ground-truth data".
> 
> On 17 Feb 2014, at 17:20, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
>> I would really like to see an answer to how these n-tuple matches are supposed to work with prefix matches on various fields.
>> What is the match algorithm?
>> What assumptions are placed on the mapping system to support these tuples?
>> How will the ETR know that the mapping system it is talking to supports this capability?  In particular, what if the same device is serving as an ETR for conventional operations and for these enhanced operations. Does it need to be configured to know which map server handles which mode?  Does it guess?  Is the same map server required to handle both?
>> 
>> Yours,
>> Joel
>> 
>> On 2/17/14, 11:45 AM, Alberto Rodriguez-Natal wrote:
>>> Dear all,
>>> 
>>> We have submitted a new draft, "SDN extensions for LISP", that you can
>>> find here:
>>> 
>>> http://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00
>>> 
>>> We believe that LISP can serve as a southbound protocol for SDN. With
>>> this draft we aim to improve vanilla LISP with some extensions to make
>>> it even more suitable for SDN scenarios.
>>> 
>>> This draft also complements and provides the foundations for the current
>>> LISP NFV draft.
>>> 
>>> http://tools.ietf.org/html/draft-barkai-lisp-nfv-04
>>> 
>>> Your thoughts and feedback on both drafts are more than welcome.
>>> 
>>> Best,
>>> Alberto
>>> 
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp