Re: [lisp] LISP SDN

["Michiel Blokzijl (mblokzij)" <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Michiel,
> 
> On Tue, Feb 18, 2014 at 2:59 AM, Michiel Blokzijl (mblokzij) <[e-mail]> 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. 

[MB] Ah, I understand :)

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