Re: [lisp] LISP SDN

"Michiel Blokzijl (mblokzij)" <mblokzij@cisco.com> Mon, 17 February 2014 17:59 UTC

Return-Path: <mblokzij@cisco.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 ECA0A1A04ED for <lisp@ietfa.amsl.com>; Mon, 17 Feb 2014 09:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, 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 7b5ffz9IqKkw for <lisp@ietfa.amsl.com>; Mon, 17 Feb 2014 09:59:12 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8D1A0470 for <lisp@ietf.org>; Mon, 17 Feb 2014 09:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9239; q=dns/txt; s=iport; t=1392659949; x=1393869549; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M/kcVYGCT4DP2tIAhM1Mqjw47FHjkfF20HlCIKjUVzk=; b=ZmsOV97hnw1y63OiFBDDmUZN3Ybodov4/0GKl44GFAB3pXBRFg0WffYx 75uSIlEn76l2XlmOpDopv7r+SS+kwmAdgk/YYd5O2cIrstSU8npHYxBfi nktD/rHrXy1gX52Q2VbA3OFwQuIHStD7FhO40rYdXGwdeQt1DREPBGNkA w=;
X-Files: signature.asc : 801
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlQGAIpMAlOtJXG//2dsb2JhbABZgwY4V7ZjiFmBIBZ0giUBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgUOh28IDctUF459BAeDJIEUBJBAgTKGOoEykHGDLYIq
X-IronPort-AV: E=Sophos; i="4.95,862,1384300800"; d="asc'?scan'208,217"; a="21050215"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 17 Feb 2014 17:59:09 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1HHx9ll004421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 17:59:09 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.200]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 11:59:08 -0600
From: "Michiel Blokzijl (mblokzij)" <mblokzij@cisco.com>
To: "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: [lisp] LISP SDN
Thread-Index: AQHPLAn0Io3RsXJrpUC+fp7yvL8Ztg==
Date: Mon, 17 Feb 2014 17:59:07 +0000
Message-ID: <E7F7C080-38DF-4AF7-B0AD-CB0F95D74BBD@cisco.com>
References: <CA+YHcKF5aUK-ADsxaE7W1T9DmkON51LogDdDXVEWTq1jF5tDDA@mail.gmail.com> <530244E4.4060906@joelhalpern.com>
In-Reply-To: <530244E4.4060906@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.164.164]
Content-Type: multipart/signed; boundary="Apple-Mail=_9126D95A-F8B4-4DB1-869D-FFD4049CF23D"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/cCvYCqqq8mfaNx-BBGwRc40nQ4o
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 17:59:14 -0000

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