Re: [lisp] LISP SDN

[Dino Farinacci <[e-mail]>]

Ack. Thanks for being receptive of my comments.

Dino

On Feb 19, 2014, at 4:32 AM, Alberto Rodriguez-Natal <[e-mail]> 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.
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
>