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