Subject: [lisp] LISP SDN

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 17 Feb 2014 08:45:51 -0800

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Feb 2014 12:20:36 -0500

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:
>
> 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.
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Mon, 17 Feb 2014 17:59:07 +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 <[email-masked]> 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.
> 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
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Feb 2014 10:26:17 -0800

I agree the title needs to be more specific.

Dino

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 17 Feb 2014 20:14:45 +0100

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 ... 

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 :)

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 <[email-masked]
> wrote:

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 18 Feb 2014 00:09:29 +0000

O'fino ?
openflow identity network overlay 
Sounds italrish..

Many people still don't get how to combine openflow and overlay SDN-XTR can clear its not a XOR

--szb

On Feb 17, 2014, at 10:26 AM, "Dino Farinacci" <[email-masked]> wrote:

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 17 Feb 2014 16:45:48 -0800

> openflow identity network overlay 

It shouldn't be openflow specific. It could be used for any southbound protocol. 

> Many people still don't get how to combine openflow and overlay SDN-XTR can clear its not a XOR

Well a lot if times is because the explanation isn't clear enough. 

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 19:09:25 +0900

Joel,

This is exactly the kind of discussion we wanted to trigger with this draft
submission. Your questions are much appreciated. Most of issues you raised
do not have a clear answer yet. There is ongoing discussion among the draft
authors on how to best address those points. Let me try to provide some
light on what is the plan.

At this point we are focusing on exact match tuple lookups. That's a
reasonable goal that can be achieved somehow easily with a DHT-like Mapping
System. As you pointed wisely, prefix matches on multiple fields increases
hugely the complexity. We would like to cover those too, but currently we
are studying which would be the best way to do so, and if the necessary
trade-offs would make prefix lookup worthwhile. Maybe at some point we will
need to limit prefix lookup to a certain number of fields or to a certain
size of network deployments.

As for MS selection, we assume now that it is preconfigured on the devices.
Currently, we are also only considering the case of an internal deployment
where all the elements are SDN-capable and the whole deployment is
SDN-oriented. How a xTR serving conventional operation and SDN operation
should behave is to further study.

Thanks,
Alberto

On Tue, Feb 18, 2014 at 2:20 AM, Joel M. Halpern <[email-masked]>wrote:

> 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
>
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 19:12:11 +0900

Hi Michiel,

On Tue, Feb 18, 2014 at 2:59 AM, Michiel Blokzijl (mblokzij) <
[email-masked]> 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).
>
> Maybe that is due to the fact that most of the people involved in the ODL
lispflowmapping project, the NFV draft and the SDN draft are the same ;).
Regarding NFV-SDN drafts, the idea is to keep the NFV draft to cover NFV
specific details, while all SDN related stuff (that of course may be of
interest for NFV) will be described in this new draft.

> "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..
>

If you want to deploy a full SDN system using LISP, then for sure you need
to take into account all what you said. However, as you pointed, this is
not the target of this draft. This draft covers, what we consider, some
extensions to the base protocol that can enhance LISP inherent support for
SDN. Namely, tuple lookup and advanced mapping updates.

The things you mentioned are indeed necessary for a SDN deployment, but
they are out of the scope of this draft. Some of those should be covered by
other protocols (for instance using netconf, ovsdb, or of-config to handle
configuration) or even be implementation specific. Let me give you a
concrete example. For the ODL lispflowmapping project we had to define a NB
interface for the MS. That interface allows to introduce mappings on the MS
using a REST API and JSON encoded data. Although this is useful, we don't
want to cover that in an IETF draft since it is implementation specific and
it's not a modification to the LISP protocol itself.

Said that, I think that maybe you are right and this is not the best name
for the draft. We'll try to think of a better one. Maybe something related
to the "southbound" nature of the draft? We are also open to suggestions ;)

>
> 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.
>

That's exactly what we intend, I'm sorry if the draft name made you think
otherwise. Thanks Michiel for your comments.

Best,
Alberto

> 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".
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 19:15:23 +0900

Hi Robert,

On Tue, Feb 18, 2014 at 4:14 AM, Robert Raszuk <[email-masked]> wrote:

> 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
> 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

> On Mon, Feb 17, 2014 at 5:45 PM, Alberto Rodriguez-Natal <
> [email-masked]> wrote:
>
>> Dear all,
>>
>> this draft we aim to improve vanilla LISP with some extensions to make it
>> even more suitable for SDN scenarios.
>>

---

From: Lori Jakab <[email-masked]>
Date: Tue, 18 Feb 2014 12:57:53 +0200

Hi Alberto, Robert,

I'm really excited to LISP used as an SDN enabler!!

A few initial comments:

On 02/18/2014 12:15 PM, Alberto Rodriguez-Natal wrote:
> Hi Robert,
> 
> 
> On Tue, Feb 18, 2014 at 4:14 AM, Robert Raszuk <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

[...]

> but we expect to cover more in the future (thus, the n-tuple notation on

I think covering more fields is a good idea.

> 
> 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.

I don't think you would be competing with OF by specifying the same
match types as the ONF does, you would be using (implementing?)
OpenFlow, and that would lead to less fragmentation and more code reuse.

> 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 ;)

Well, OpenFlow is slowly adding support for L3 only flows, and LISP is
slowly adding support for L2 encaps. Even if you're initially focusing
on a few match fields, the design should accommodate a variable number
of fields, and the specification of field prerequisites (e.g., if you're
matching on a TCP port number, you should have an IPv4 or IPv6 packet).

As Robert, I would really like OpenFlow compatible match support.

-Lori

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 20:17:04 +0900

Hi Lori,

Thanks for the comments, see below.

> I'm really excited to LISP used as an SDN enabler!!

That makes at least two of us then! :D

> I think covering more fields is a good idea.

Agreed.

> OpenFlow, and that would lead to less fragmentation and more code reuse.

Don't get me wrong here. Maybe I explained myself poorly. I didn't want to
say that we need to cover different fields. What I meant to say is that
maybe we don't need to cover ALL the fields that OF covers. Perhaps a
subset of those is enough for LISP. Of course, in the future maybe we see
the need for covering more (all?) OF fields or maybe beyond OF ones.

> slowly adding support for L2 encaps.

That's why I said "generally speaking" ;)

> Even if you're initially focusing

We had discussed that in the past. I think that it could make sense. Maybe
we finally add that to the draft...

Thanks,
Alberto

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Tue, 18 Feb 2014 11:36:05 +0000

Hi Alberto,

Thanks for getting back to me!

I was thinking a draft title that incorporates "flow" would probably be suitable, since you're extending LISP to deal with L4 flows. I was almost going to suggest lisp-flowmapping, or "flow mapping extension for LISP", or something like that.. But I don't know enough about the other projects you are involved in to know whether a title like the above sufficiently and/or correctly differentiates this draft from the other ones, if that's required.

Also, I see headings like "Mapping subscription" and "Proactive update pushing" (which mostly say TBD). Those strike me as elements that might be useful independent of the n-tuple flow mapping concept.

Best regards,

Michiel

PS: I'm glad to see people working on LISP+SDN!

On 18 Feb 2014, at 10:12, Alberto Rodriguez-Natal <[email-masked]> wrote:

> Hi Michiel,
> 
> On Tue, Feb 18, 2014 at 2:59 AM, Michiel Blokzijl (mblokzij) <[email-masked]> wrote:
> Hi,
> 
> Maybe that is due to the fact that most of the people involved in the ODL lispflowmapping project, the NFV draft and the SDN draft are the same ;). Regarding NFV-SDN drafts, the idea is to keep the NFV draft to cover NFV specific details, while all SDN related stuff (that of course may be of interest for NFV) will be described in this new draft. 

[MB] Ah, I understand :)

> If you want to deploy a full SDN system using LISP, then for sure you need to take into account all what you said. However, as you pointed, this is not the target of this draft. This draft covers, what we consider, some extensions to the base protocol that can enhance LISP inherent support for SDN. Namely, tuple lookup and advanced mapping updates. 
> 
> The things you mentioned are indeed necessary for a SDN deployment, but they are out of the scope of this draft. Some of those should be covered by other protocols (for instance using netconf, ovsdb, or of-config to handle configuration) or even be implementation specific. Let me give you a concrete example. For the ODL lispflowmapping project we had to define a NB interface for the MS. That interface allows to introduce mappings on the MS using a REST API and JSON encoded data. Although this is useful, we don't want to cover that in an IETF draft since it is implementation specific and it's not a modification to the LISP protocol itself.
> 
> Said that, I think that maybe you are right and this is not the best name for the draft. We'll try to think of a better one. Maybe something related to the "southbound" nature of the draft? We are also open to suggestions ;)
>  
> 
> That's exactly what we intend, I'm sorry if the draft name made you think otherwise. Thanks Michiel for your comments.
> 
> Best,
> Alberto
> 
> Best regards,
> 
> Michiel
>

---

From: Lori Jakab <[email-masked]>
Date: Tue, 18 Feb 2014 13:38:55 +0200

On 02/18/2014 01:17 PM, Alberto Rodriguez-Natal wrote:
> On Tue, Feb 18, 2014 at 7:57 PM, Lori Jakab <[email-masked]
> <mailto:[email-masked]>> wrote:

[...]

> Don't get me wrong here. Maybe I explained myself poorly. I didn't want
> to say that we need to cover different fields. What I meant to say is
> that maybe we don't need to cover ALL the fields that OF covers. Perhaps
> a subset of those is enough for LISP. Of course, in the future maybe we
> see the need for covering more (all?) OF fields or maybe beyond OF ones.

Understand.

My main consideration here is that many (most?) SDN software packages
today (for whatever definition of SDN) has support for OpenFlow (mostly
1.0). Hardware is also starting to support OpenFlow. So I think that
simply from the implementation point of view you have an advantage if
you just can reuse a versatile existing matching engine.

> That's why I said "generally speaking" ;)

I thought so :)  But I still wrote the comment because I think we should
be forward looking!

Thanks for the discussion,
-Lori

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 21:55:36 +0900

Michiel,

In general, the idea behind this draft is: LISP is inherently a well-suited
protocol to serve as a southbound SDN protocol, however there are a few
pieces missing. This draft tries to get together all these pieces and fill
the gaps.

I agree that maybe "SDN extensions" is too general, since the draft does
not cover (neither intent to) things such NB APIs for instance. My thoughts
are now into pointing clearly in the title the "southbound" nature of the
draft.

On Tue, Feb 18, 2014 at 8:36 PM, Michiel Blokzijl (mblokzij) <
[email-masked]> wrote:

> I was thinking a draft title that incorporates "flow" would probably be
> suitable, since you're extending LISP to deal with L4 flows. I was almost
> going to suggest lisp-flowmapping, or "flow mapping extension for LISP", or
> something like that.. But I don't know enough about the other projects you
> are involved in to know whether a title like the above sufficiently and/or
> correctly differentiates this draft from the other ones, if that's required.
>

Actually we did present a prototype of some of these ideas to the SDNRG
with the title "LISPflow". However, as you point below, this draft is not
only extensions to support flows ;)

>
> Also, I see headings like "Mapping subscription" and "Proactive update
> pushing" (which mostly say TBD). Those strike me as elements that might be
> useful independent of the n-tuple flow mapping concept.
>

> PS: I'm glad to see people working on LISP+SDN!

It's my pleasure! :)

Alberto

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 18 Feb 2014 22:01:16 +0900

Lori,

> you just can reuse a versatile existing matching engine.
That's indeed a good point. I think that with that in mind, the inclusion
of a OF-like-tuple makes even more sense.

Many thanks for your comments,
Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Feb 2014 08:02:09 -0800

> I was thinking a draft title that incorporates "flow" would probably be suitable, since you're extending LISP to deal with L4 flows. I was almost going to suggest lisp-flowmapping, or "flow mapping…

How a title that indicate "LISP with a Granular Map-Cache". Because even not going too granular this draft could also include (S-prefix, G-prefix) entries. Which are not flows but source/destination pairs in prefix form.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Feb 2014 15:34:38 -0800

> http://tools.ietf.org/html/draft-rodrigueznatal-lisp-sdn-00

Alberto, enclosed are my comments. The draft text comes first and is indented and my comments follow.

> Abstract
> 
>    This document describes extensions for the Locator/ID Separation
>    Protocol (LISP) to make it more suitable to be used on Software
>    Defined Networking (SDN) scenarios.

As others have said this draft is probably mis-titled. SDN, in understandable form, is a mechanism to program network devices. This spec says nothing about the programmability and more about how to do map-cache lookups locally in the xTR and how to what lookup-key should be used for mapping database lookups.

So I think this is really a draft that says LISP can be extended to have more general lookup keys, multi tuple keys. So I suggest the title "LISP Granuarl Map-Caches". And the lookups are not just multi-tuple lookups but in practice will be more like each element of the tuple will be a LONGEST match lookup (that is a superset of an EXACT match lookup).

>    However, vanilla LISP offers a limited feature set on terms of SDN
>    requirements.  To position LISP as the foundations for a SDN
>    solution, advanced interaction between LISP elements and some
>    extensions to the stock protocol can be defined.  This document
>    describes SDN extensions for LISP.

I think this paragraph should be rewritten a bit. Most protocols do not offer or satisfy SDN requirements. Whatever that could be. But SDN capabilities can be used to configure, monitor, and get status from SDN capabile devices. So this issue, or problem you are trying to form, is not in the protocol but a general device capability.

I think this paragraph should say "This draft will describe how a lookup key, specificly termed in the main LISP spec and the LISP-DDT spec as an extended-EID, can be used for more granular lookups ..."

And also note, we already have multi-tuples in the mapping system. They are {instance-id, EID-prefix} and LISP-RE uses {S-prefix, G-prefix}.

>    On the present iteration of this draft, the LISP protocol operating
>    in a SDN deployment manages network traffic in terms of flows
>    identified by a 5-tuple identifier. 5-tuples are encoded in a

A 5-tuple map-cache entry can be configured with SNMP, local CLI, an SDN type API or learned via protocol mechansims (Map-Request/Map-Reply exchange).

>    specific type of LISP Canonical Address Format (LCAF).  Flows are
>    routed over the network using Explicit Locator Paths (ELPs).  The

A 5-tuple extended-EID can be used to yield any type of locator-set, not just one with an ELP in it. You may want this application to use ELPs, but state that later in a specific use-case example, in a separate section.

>  o  Extended-EID: This document uses the term Extended-EID to refer to
>       any n-tuple (including a 5-tuple) used in a EID role.

Indicate this is the same extended-EID as in LISP-DDT. Or else, you can't look up a multi-tuple entry in the mapping system. This is the same comments Joel provided. And yes, he is right, we have to provide way more details about how its done. I can explain at the LISP WG meeting.

> Protocol operation follows the specification defined on [LISP] except
>    for the following.  Besides of IP to IP mappings, Mapping System
>    stores also Extended-EID to ELP mappings.  Being Extended-EID a
>    n-tuple identifying a flow.  LISP routers perform look-ups based on
>    these Extended-EIDs, instead of on destination IPs.  Apart from using
>    n- tuples instead of IPs, retrieving information from the Mapping
>    System follows LISP standard mechanisms (i.e. Map-Request, Map-
>    Reply).

The basic framework and structure is already in LISP. You are just defining a different key lookup and a return result. Please phrase it that way. This is a specific use-case of having a 5-tuple-to-RLOC-ELP mapping.

>  Traditionally ETRs register EID-prefixes that include their own RLOC
>    addresses as well as other RLOCs for ETRs at the same site.  Here a
>    third-party will also register Extended-EID-to-ELP bindings.

A third-party is not required to register these new mappings. An ETR can do this. And a third-party could register ETR RLOC addresses in the current form.

> LISP routers (xTRs, RTRs) behave as specified on [RFC6830] and
>    [RFC6833], except for the following.  LISP routers perform mapping
>    lookups based on Extended-EID (n-tuple) not on IP address EID and
>    they obtain an ELP instead of an IP address RLOC.  Which specific
>    n-tuple lookup to use and how to configure the router to use it, is
>    to be covered on future iterations of this document.

> It is not except for the following. Today multi-tuples are looked up in the form of {instance-ID, EID}.
> 
> The
> 
> Rodriguez-Natal, et al.  Expires August 11, 2014                [Page 4]
> Internet-Draft                  LISP-SDN                   February 2014
> 
> 
>    Mapping System must reply with a Map- Reply carrying on the locator
>    field an ELP.  This Map-Reply can carry on the EID-prefix field an
>    Extended-EID more coarse in some fields, but covering the original
>    Extended-EID.  The LISP router must store this Extended-EID entry
>    (even if more coarse) in its map-cache.

It is not required for the mapping system to return the Map-Reply for this use-case. The process of sending and processing a Map-Request can occur just like it is documented today. That is, whoever registered the extended-multi-tuple-extended-EID-prefix is the one that gets the Map-Request and can reply with or without policy added or that entity registers to its Map-Servers with the proxy-reply flag where the Map-Server sends the Map-Reply.

> Mapping System (comprising Map Servers and Map Resolvers) behaves as
>    specified on [RFC6830] and [RFC6833], except for the following.  It
>    also stores mappings indexed by Extended-EID.  These mappings contain
>    n-tuple to ELP mappings.

You must include LISP-DDT here. And you must not (and you did not) include LISP-ALT because it can only handle IPv4 and IPv6 EIDs.

And again, this is not an exception, we can handle multi-tuples today and implementations exist to support it.

> Map Servers can store more coarse Extended-EID entries.

And so do LISP-DDT nodes as well. And you'll need to specify that each element of a multi-tuple can be coarse.

>    Map Resolvers must be capable of finding the Map-Server containing
>    the longest match Extended-EID entry, according to the lookup rules
>    described in section Section 6.  Once found, the Map Resolver
>    forwards the Map-Request to the Map Server.  The Map Server replies

" ... using the mapping database transport system such as LISP-DDT ...".

>    itself to Map- Requests.  It must not forward Map-Requests comprising
>    Extended-EIDs to any ITRs.

You shouldn't say that. Because if an ITR is acting as a proxy registerer, then the mapping system should. I'm not saying we should do this but you don't need to make that statement.

>    The 5-tuple LCAF is the combination of LCAF types 4 and 12.

Make this sentence more user-friendly indicate "a combination of Application Data Type 4 and Source/Dest Type 12".

> 12.  Normative References

Add a LISP-DDT reference.

Thanks,
Dino

---

From: Sharon Barkai <[email-masked]>
Date: Wed, 19 Feb 2014 03:50:26 +0000

Have to say that I agree with Lori on that point. 

It's possible to specify a flow based lisp, ie cached-lookup, pub-sub, as Dino says very accurately and consequently all around efficient low-cost, low-footprint hardware, high performance software on generic hardware implementation...
All that without committing to OpenFlow.

And it's possible to specify federated, data-driven, consistent distribution of OpenFlow based on distributed overlays, without committing to LISP (multicast transparent bridging, route-reflector as directory, or some other weird method).

Its probably a good idea to unify LISP & OpenFlow at least as a reference with consistent cross reference to tuples, transient aging time / watch-dogs, etc.    

But add text to the LISP draft that explains the generalization made here with respect to looking up whole network conversations in the mapping and not per-packet, and sticking to common conventions as to the definition of these conversations (TCP/UDP) for such and such time while active packets prolog aging..

In the flowMapping NFV specs we take the concepts further to per subscriber flow function affinity, function chaining, app specific mapping schemas..
But Alberto's draft is a much needed pre-step, generates the right discussion.

--szb

[...]

Understand.

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 19 Feb 2014 13:02:52 +0900

Hi Dino,

I mostly agree with all of your comments regarding the current text (with
some nuances of course), but I think that we can carry on that discussion
on London. However, let me address something here.

On Wed, Feb 19, 2014 at 8:34 AM, Dino Farinacci <[email-masked]> wrote:

> As others have said this draft is probably mis-titled. SDN, in
> understandable form, is a mechanism to program network devices. This spec
> says nothing about the programmability and more about how to do map-cache
> lookups locally in the xTR and how to what lookup-key should be used for
> mapping database lookups

My idea with the draft is to address all the extensions (with all the
required technical detail) to enhance LISP+SDN deployments, that's the
reason for the name. Please keep in mind that this is just a -00 version
and most of the content is still to be written. Despite the fact that the
text now refers mostly to flow aspects, my intention is to address other
points (such Publish/Subscribe mechanism, etc) on the near future.

I would prefer to keep all SDN related stuff here to avoid the
proliferation of drafts. If in the future we see that some parts (like what
you call "LISP granular map-caches") require too much technical detail,
then we should consider the spin-off of those parts to different drafts and
keep this draft as a "SDN umbrella" (as Michiel suggested).

At this point this draft is a tool to work on all the SDN specific aspects
of LISP and to generate some discussion.

Let's talk in London ;)

Alberto

---

From: Sharon <[email-masked]>
Date: Tue, 18 Feb 2014 22:42:12 -0800

LISP Pattern Matching Hashing Caching :)

--szb

> On Feb 18, 2014, at 8:02 AM, Dino Farinacci <[email-masked]> wrote:
> 

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 19 Feb 2014 21:32:58 +0900

Hi again Dino,

Just for list completeness and to prepare the meeting in London, here are
some replies to the rest of your comments.

[...]

> I think this paragraph should be rewritten a bit. Most protocols do not
> offer or satisfy SDN requirements. Whatever that could be. But SDN
> capabilities can be used to configure, monitor, and get status from SDN
> capabile devices. So this issue, or problem you are trying to form, is not
> in the protocol but a general device capability.
>

Correct, this is not an issue of LISP. I'll rewrite this to state that more
clearly.

>
> I think this paragraph should say "This draft will describe how a lookup
> key, specificly termed in the main LISP spec and the LISP-DDT spec as an
> extended-EID, can be used for more granular lookups ..."
>

Perfect, that text is a good introduction to the lookup section (or the
eventual lookup draft) .

>
> And also note, we already have multi-tuples in the mapping system. They
> are {instance-id, EID-prefix} and LISP-RE uses {S-prefix, G-prefix}.
>

Noted ;)

> A 5-tuple map-cache entry can be configured with SNMP, local CLI, an SDN
> type API or learned via protocol mechansims (Map-Request/Map-Reply
> exchange).
>

Agreed.

> A 5-tuple extended-EID can be used to yield any type of locator-set, not
> just one with an ELP in it. You may want this application to use ELPs, but
> state that later in a specific use-case example, in a separate section.
>

You are right and I like the idea of stating the use of ELPs for the SDN
case in another section.

> Indicate this is the same extended-EID as in LISP-DDT. Or else, you can't
> look up a multi-tuple entry in the mapping system. This is the same
> comments Joel provided. And yes, he is right, we have to provide way more
> details about how its done. I can explain at the LISP WG meeting.
>

Agreed. That needs more explanation. Regarding Extended-EID, I believe the
definition here goes beyond the Extended-EID definition on LISP-DDT. Let's
put it this way, the Extended-EID defined in LISP-DDT is just an example of
a possible n-tuple Extended-EID on the sense of Extended-EID used on the
SDN draft. We can talk further about this in London.

> The basic framework and structure is already in LISP. You are just
> defining a different key lookup and a return result. Please phrase it that
> way. This is a specific use-case of having a 5-tuple-to-RLOC-ELP mapping.
>

Absolutely correct. It was not my intention to say that this is not already
present on LISP. .Will rephrase.

> A third-party is not required to register these new mappings. An ETR can
> do this. And a third-party could register ETR RLOC addresses in the current
> form.
>

Correct, an ETR can do this. However in the context of SDN, it's most
likely that a third-party, and no the ETR, will register the tuple-ELP
mappings on the Mapping System.

> It is not required for the mapping system to return the Map-Reply for this
> use-case. The process of sending and processing a Map-Request can occur
> just like it is documented today. That is, whoever registered the
> extended-multi-tuple-extended-EID-prefix is the one that gets the
> Map-Request and can reply with or without policy added or that entity
> registers to its Map-Servers with the proxy-reply flag where the Map-Server
> sends the Map-Reply.
>

Yes, I'm not defining any new operation of LISP. Just trying to make clear
how this LISP operation will look like when used on a SDN scenario.

> You must include LISP-DDT here. And you must not (and you did not) include
> LISP-ALT because it can only handle IPv4 and IPv6 EIDs.
>

Which Mapping System to use requires further and deeper discussion (I
think). For an exact match tuple lookup the best choice would be a DHT one
(since it's a plain namespace). However for coarse lookups I'm not sure yet
how to proceed.

> element of a multi-tuple can be coarse.

If we finally allow that, then for sure that should be specified.

> You shouldn't say that. Because if an ITR is acting as a proxy registerer,
> then the mapping system should. I'm not saying we should do this but you
> don't need to make that statement.
>

Agreed. Good point.

> Make this sentence more user-friendly indicate "a combination of
> Application Data Type 4 and Source/Dest Type 12".
>

We need also to discuss if this is enough, or if we want to define a
5-tuple specific type to avoid extra LCAF headers overhead.

> Add a LISP-DDT reference.

Will do.

Thanks,
Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Feb 2014 08:56:33 -0800

> My idea with the draft is to address all the extensions (with all the required technical detail) to enhance LISP+SDN deployments, that's the reason for the name. Please keep in mind that this is just a -00 version and

I understand what you are trying to do but when you say "LISP+SDN" that can mean 100s of things. Here is an example:

(1) I have 1 ITR and 1000 ETRs.
(2) I have 100 groups where there membership is a subset of the 1000 ETRs.
(3) I don't want to do any protocol signalling to allow the ITR to replicate multicast packets for the 100 
groups to the various ETRs.
(4) I have an SDN application that programs the ITR with 100 map-cache entries.

So the above example can be classified as "LISP+SDN" but you, of course, had no intention to cover that in your draft. My point being is that you need to GET SPECIFIC.

> most of the content is still to be written. Despite the fact that the text now refers mostly to flow aspects, my intention is to address other points (such Publish/Subscribe mechanism, etc) on the near future.

Publish means that ETRs register 5-tuples to the mapping system. Subscribe means that ITRs send Map-Requests to find RLOC-records for those 5-tuples.

Unless you use specific language like I did above just saying "Pub/Sub" can mean dozens of things.

> I would prefer to keep all SDN related stuff here to avoid the proliferation of drafts. If in the future we see

What is the "SDN related stuff" mean?

> that some parts (like what you call "LISP granular map-caches") require too much technical detail, then we should consider the spin-off of those parts to different drafts and keep this draft as a "SDN umbrella" (as Michiel suggested).

If you take the details of the granular map-cache out of this spec, then what is the spec covering?

> At this point this draft is a tool to work on all the SDN specific aspects of LISP and to generate some discussion.
> 
> Let's talk in London ;)

Where is the spec on SDN specific aspects of BGP and OSPF? There isn't any because it doesn't make sense.

Can someone else clarify this if you think I'm missing something?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Feb 2014 08:57:51 -0800

Ack. Thanks for being receptive of my comments.

Dino

On Feb 19, 2014, at 4:32 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:

> Hi again Dino,
> 
> Just for list completeness and to prepare the meeting in London, here are some replies to the rest of your comments.
> 
> 
> Correct, this is not an issue of LISP. I'll rewrite this to state that more clearly.
> 
> Perfect, that text is a good introduction to the lookup section (or the eventual lookup draft) .
> 
> You are right and I like the idea of stating the use of ELPs for the SDN case in another section.
> 
> Agreed. That needs more explanation. Regarding Extended-EID, I believe the definition here goes beyond the Extended-EID definition on LISP-DDT. Let's put it this way, the Extended-EID defined in LISP-DDT is just an example of a possible n-tuple Extended-EID on the sense of Extended-EID used on the SDN draft. We can talk further about this in London.
> 
> Absolutely correct. It was not my intention to say that this is not already present on LISP. .Will rephrase.  
> 
> Correct, an ETR can do this. However in the context of SDN, it's most likely that a third-party, and no the ETR, will register the tuple-ELP mappings on the Mapping System. 
> 
> Yes, I'm not defining any new operation of LISP. Just trying to make clear how this LISP operation will look like when used on a SDN scenario. 
> 
> Which Mapping System to use requires further and deeper discussion (I think). For an exact match tuple lookup the best choice would be a DHT one (since it's a plain namespace). However for coarse lookups I'm not sure yet how to proceed.
> 
> We need also to discuss if this is enough, or if we want to define a 5-tuple specific type to avoid extra LCAF headers overhead.
> 
> > 12.  Normative References
>