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