Ack. Thanks for being receptive of my comments. Dino
On Feb 19, 2014, at 4:32 AM, Alberto Rodriguez-Natal <[email protected]> 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 <[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
