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 protected]> wrote: > Hi Michiel, > > On Tue, Feb 18, 2014 at 2:59 AM, Michiel Blokzijl (mblokzij) > <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >>> >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
