Re: [lisp] LISP SDN

[Alberto Rodriguez-Natal <[e-mail]>]

Hi again Dino,

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


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

[...]

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

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

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

Agreed.

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

You are right and I like the idea of stating the use of ELPs for the SDN
case in another 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.
>

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.

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

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

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

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.

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

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.

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

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.

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

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

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

Agreed. Good point.

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

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
>
> Add a LISP-DDT reference.
>

Will do.

Thanks,
Alberto

>
> Thanks,
> Dino
>
>
>
>
>
>
>
>
>
>