Re: [lisp] LISP SDN

Alberto Rodriguez-Natal <arnatal@ac.upc.edu> Tue, 18 February 2014 10:15 UTC

Return-Path: <arnatal@ac.upc.edu>
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 BB0FF1A0627 for <lisp@ietfa.amsl.com>; Tue, 18 Feb 2014 02:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level:
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 FCKOqFGrYSAe for <lisp@ietfa.amsl.com>; Tue, 18 Feb 2014 02:15:49 -0800 (PST)
Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id CB7371A03C9 for <lisp@ietf.org>; Tue, 18 Feb 2014 02:15:48 -0800 (PST)
Received: from gw-3.ac.upc.es (gw-3.ac.upc.es [147.83.30.9]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id s1IAFjuZ009759 for <lisp@ietf.org>; Tue, 18 Feb 2014 11:15:45 +0100
Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by gw-3.ac.upc.es (Postfix) with ESMTPSA id B0C63C1 for <lisp@ietf.org>; Tue, 18 Feb 2014 11:15:44 +0100 (CET)
Received: by mail-yk0-f169.google.com with SMTP id 142so32780165ykq.0 for <lisp@ietf.org>; Tue, 18 Feb 2014 02:15:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=myu6bQxFy8yFspNh6nDDZHhmlbHWCpCIx3CyPFSxndk=; b=m4f0KDEsWjwQ63g4lksnatl8qO4IuosLpYiCrLZLcKSX0j7R9KrDsn0xB3PaeS7qOh hE5U1GCOcuJzFyO45Kiayqxg0FEjMJJjhoGnt5IdT2b+SL48nWyKPRAmu+NY2Lj1HgsU kwS2vMYdE090ZZEnSkoSOr3EY6QfhWkzDipkuZdQhM7HiLkrHUC+yfR3xlmt5R69KxLU MXf/Nc6E0l4CrRSN9O4Vym7nawGPFmPNwlaQZpTqIF11liCuO8+XkxkHAAFVrgB83nfh U35DtRMgVSH5u45jLi84yA4r1E9Kvf48WYW+EZECeYRnQf/j01O2q7D9hrK1CwhfdoPV 4HiQ==
X-Received: by 10.236.93.208 with SMTP id l56mr2834593yhf.112.1392718543561; Tue, 18 Feb 2014 02:15:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.170.51.209 with HTTP; Tue, 18 Feb 2014 02:15:23 -0800 (PST)
In-Reply-To: <CA+b+ERmJsdSw+kb+oSi-yyydQrB6_uTJBXPnNT9LH9nqovLRMQ@mail.gmail.com>
References: <CA+YHcKF5aUK-ADsxaE7W1T9DmkON51LogDdDXVEWTq1jF5tDDA@mail.gmail.com> <CA+b+ERmJsdSw+kb+oSi-yyydQrB6_uTJBXPnNT9LH9nqovLRMQ@mail.gmail.com>
From: Alberto Rodriguez-Natal <arnatal@ac.upc.edu>
Date: Tue, 18 Feb 2014 19:15:23 +0900
Message-ID: <CA+YHcKFgSWxeSbCeCJm9Te8Cxmv1xjvrLvO9h3Yd+y=yDsLKxg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary="20cf3010ead10fc69604f2ab8efd"
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/IYj5FPMBYv9uLBdfB3jkvYNFNhk
Cc: "lisp@ietf.org list" <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: Tue, 18 Feb 2014 10:15:53 -0000

Hi Robert,


On Tue, Feb 18, 2014 at 4:14 AM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Alberto at all,
>
> I have read your draft with high interest expecting to understand what the
> "sdn" is. And you did not let me down as the draft provided clear
> definition of 5-tuples to be all the SDN magic is about:
>
>       5-tuple: The term 5-tuple is used in this document to describe the
>
>       set comprised by 5 elements, being these the source IP address,
>       the destination IP address, the level 4 protocol number, the level
>       4 protocol source port and the level 4 protocol destination port
>       of a data packet.
>
>
>
>
> Considering you implicitely meant IPv4 & IPv6 you have really defined 7 tuples ...
>
> Correct, IP means both IPv4 and IPv6 here. We are also implicitly talking
about several level 4 protocols, so if you take into account (for instance)
both UDP and TCP, then we are implicitly defining 9 different tuple field
types ;). Although only 5 (at most) will be used at the same time to
identify a flow.


>
>
>
> But I must ask why limit yourself to 5 or 7 tuples if another standards body (at least one claims to be the SDO)
>
> already
>
> long time
> ago defined 39 tuples to be SDN primitives or building blocks.
> Is there something among those
>
> 39 tuples xTRs can't do ? I guess not as both could be same boxes from same ODM vendor :)
>
>
> You are right here. More fields beyond just the addresses, protocol and
ports can be taken into account. For now, we are focusing on these only,
but we expect to cover more in the future (thus, the n-tuple notation on
the draft).

Besides, please note that we may won't cover the same types that OF covers.
We don't want to compete with OF, but rather to complement it. It's about
using the right tool for the job. OF is (generally speaking) focused on L2,
while LISP is (generally speaking) focused on L3. That's why the 5-tuple
makes more sense for LISP as a flow identifier than, let's say, ETH or ARP
fields. Hope I had brought some light here ;)

Best,
Alberto


> List of those 39ers (src: OF 1.3
> http://goo.gl/a2OnWn
>
>
>
> )
> :
>
>
> /* OXM Flow match field types for OpenFlow basic class. */
>
> enum oxm_ofb_match_fields {
> OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */
> OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */
> OFPXMT_OFB_METADATA = 2, /* Metadata passed between tables. */
> OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */
> OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */
> OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */
> OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */
> OFPXMT_OFB_VLAN_PCP = 7, /* VLAN priority. */
> OFPXMT_OFB_IP_DSCP = 8, /* IP DSCP (6 bits in ToS field). */
> OFPXMT_OFB_IP_ECN = 9, /* IP ECN (2 bits in ToS field). */
> OFPXMT_OFB_IP_PROTO = 10, /* IP protocol. */
> OFPXMT_OFB_IPV4_SRC = 11, /* IPv4 source address. */
> OFPXMT_OFB_IPV4_DST = 12, /* IPv4 destination address. */
> OFPXMT_OFB_TCP_SRC = 13, /* TCP source port. */
> OFPXMT_OFB_TCP_DST = 14, /* TCP destination port. */
> OFPXMT_OFB_UDP_SRC = 15, /* UDP source port. */
> OFPXMT_OFB_UDP_DST = 16, /* UDP destination port. */
> OFPXMT_OFB_SCTP_SRC = 17, /* SCTP source port. */
> OFPXMT_OFB_SCTP_DST = 18, /* SCTP destination port. */
> OFPXMT_OFB_ICMPV4_TYPE = 19, /* ICMP type. */
> OFPXMT_OFB_ICMPV4_CODE = 20, /* ICMP code. */
> OFPXMT_OFB_ARP_OP = 21, /* ARP opcode. */
> OFPXMT_OFB_ARP_SPA = 22, /* ARP source IPv4 address. */
> OFPXMT_OFB_ARP_TPA = 23, /* ARP target IPv4 address. */
> OFPXMT_OFB_ARP_SHA = 24, /* ARP source hardware address. */
> OFPXMT_OFB_ARP_THA = 25, /* ARP target hardware address. */
> OFPXMT_OFB_IPV6_SRC = 26, /* IPv6 source address. */
> OFPXMT_OFB_IPV6_DST = 27, /* IPv6 destination address. */
> OFPXMT_OFB_IPV6_FLABEL = 28, /* IPv6 Flow Label */
> OFPXMT_OFB_ICMPV6_TYPE = 29, /* ICMPv6 type. */
> OFPXMT_OFB_ICMPV6_CODE = 30, /* ICMPv6 code. */
> OFPXMT_OFB_IPV6_ND_TARGET = 31, /* Target address for ND. */
> OFPXMT_OFB_IPV6_ND_SLL = 32, /* Source link-layer for ND. */
> OFPXMT_OFB_IPV6_ND_TLL = 33, /* Target link-layer for ND. */
> OFPXMT_OFB_MPLS_LABEL = 34, /* MPLS label. */
> OFPXMT_OFB_MPLS_TC = 35, /* MPLS TC. */
> OFPXMT_OFP_MPLS_BOS = 36, /* MPLS BoS bit. */
> OFPXMT_OFB_PBB_ISID = 37, /* PBB I-SID. */
> OFPXMT_OFB_TUNNEL_ID = 38, /* Logical Port Metadata. */
> OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header pseudo-field */
> };
>
>
> Cheers,
> R.
>
>
>
>
> On Mon, Feb 17, 2014 at 5:45 PM, Alberto Rodriguez-Natal <
> arnatal@ac.upc.edu> 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
>>
>>
>