Hi Isidoros Thanks for your comments, please see below our replies:
On Thu, Oct 2, 2014 at 3:41 PM, Isidoros Kouvelas <[email protected]> wrote: > > Albert, Damien, > > Thanks for the document. It provides a good overview of LISP. I have the > following comments: > > Section 2.3.1 page 7. > “The Instance ID field is used to distinguish traffic that belongs to > multiple tenants inside a LISP site, and that may use overlapped but > logically separated addressing space.” > Please expand on the instance ID description to state that it is used to > support segmentation of *EID* space. > Ok, please see below an updated sentence: The Instance ID field is used to distinguish traffic that belongs to multiple tenants inside a LISP site, and that may use overlapped but logically separated EID addressing. > > Section 2.4.2 > The start of this section refers to Map-Requests and Map-Reqplies as > “queries" and “responses". Their definition below does not refer to the > “query” and “response” role. Either modify the definitions to tie the two > together or use the standard terms from the beginning of the section. > Below the updated paragraph that introduces Section 2.4: The LISP control-plane, specified in [RFC6833], provides a standard interface to register, request, and resolve mappings. The LISP Mapping System, is a publicly accessible database that stores such mappings. In what follows we first describe the mappings, then the standard interface, and finally the Mapping System architecture. > Section 2.4.2 > “Map-Notify: When requested by the ETR, this message is sent by the > Map-Server in response to a Map-Register to acknowledge the correct reception > of the mapping.” > The Map-Notify message is also used to convey the latest Map-Server state on > the EID to RLOC mapping. > I´ve appended your suggested sentence at the end of the definition, please see below the updated paragraph: Map-Notify: When requested by the ETR, this message is sent by the Map-Server in response to a Map-Register to acknowledge the correct reception of the mapping and convey the latest Map-Server state on the EID to RLOC mapping. > Section 2.4.2 > “Please note that a Map-Reply may contain a negative reply if the queried EID > is not part of the LISP EID space. In such cases the ITR typically forwards > the traffic natively (non encapsulated) to the public Internet.” > Worth mentioning that this behavior is defined to support incremental > deployment of LISP. > Again, I´ve appended your suggested sentence, please see below the updated paragraph: Map-Reply: This message is sent by Map-Servers or ETRs in response to a Map-Request and contains the resolved mapping. Please note that a Map-Reply may contain a negative reply if the queried EID is not part of the LISP EID space. In such cases the ITR typically forwards the traffic natively (non encapsulated) to the public Internet, this behavior is defined to support incremental deployment of LISP. > Section 2.4.3.1 > “Every ETR involved in the ALT topology advertises its EID prefixes making > the EID routable on the overlay” > The Map-Servers participate in ALT, ETRs do not as the mapping system > interface hides the fact that the ALT is in use. The MS advertises the EID > prefixes that are registered against it in the ALT. > Dino rised a very similar issue with this paragraph, we suggested him this one alternatively, please let me know if you agree with it: The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first Mapping System proposed, developed and deployed on the LISP pilot network. It is based on a distributed BGP overlay participated by Map-Servers and Map-Resolvers. The nodes connect to their peers through static tunnels. Each Map-Server involved in the ALT topology advertises the EID-prefixes registered by the serviced ETRs, making the EID routable on the ALT topology. > Section 2.4.3.1 > “When an ITR needs a mapping, it sends a Map-Request to a nearby ALT router.” > The ITR sends the Map-Request to a nearby Map-Resolver that is ALT connected. > Again, Dino rised a similar issue, here´s the updated paragraph: When an ITR needs a mapping it sends a Map-Request to a Map-Resolver that, using the ALT topology, forwards the Map-Request towards the Map-Server responsible of the mapping. Upon reception the Map-Server forwards the request to the ETR that in turn, replies directly to the ITR using the native Internet core. > Section 2.5 > “In some scenarios, LISP sites may be unable to send encapsulated packets to > the legacy Internet.” > Should this be “unable to send unencapsulated packets with a local EID > address as a source”? > Here´s our updated sentence: In some scenarios, LISP sites may be unable to send encapsulated packets with a local EID address as a source to the legacy Internet. > Section 3.1 > Please add references to the RFCs defining the cache management mechanisms. > Could you please further elaborate this comment? You mean RFC6830? > Section 3.2 > “LSB is a passive technique, the LSB field is carried by data-packets in the > LISP header and can be set by a ETRs to specify which RLOCs are up/down.” > Worth describing that the RLOCs to which the LSBs refer as those of the site > of the ETR. > Please see below our updated sentence: LSB is a passive technique, the LSB field is carried by data-packets in the LISP header and can be set by a ETRs to specify which RLOCs are up/down of the site of the ETR. > Section 3.2 > “RLOC-probing: This is an active probing algorithm where ITRs send probes to > specific locators, this effectively probes both the locator and the path. In > particular this is done by sending a Map-Request (with certain flags > activated) on the data-plane and waiting in return a Map-Reply, also sent on > the data-plane.” > I am not sure what “on the data-plane” means. Can you please clarify. > Please see below an updated paragraph: RLOC-probing: This is an active probing algorithm where ITRs send probes to specific locators, this effectively probes both the locator and the path. In particular this is done by sending a Map-Request (with certain flags activated) on the data-plane (RLOC space) and waiting in return a Map-Reply, also sent on the data-plane. > thanks Thanks! Albert > Isidor > > > On Sep 22, 2014, at 23:40, Albert Cabellos <[email protected]> wrote: > > > Hi all > > > > Below you can find the -05 version of draft-ietf-lisp-introduction. We > > have changed the structure and content based on the feedback posted on > > the list > > > > We´ll gather more feedback and produce a new version before cut-off, > > please review and comment ASAP. > > > > Albert > > > > > > ---------- Forwarded message ---------- > > From: <[email protected]> > > Date: Mon, Sep 22, 2014 at 10:06 PM > > Subject: [lisp] I-D Action: draft-ietf-lisp-introduction-05.txt > > To: [email protected] > > Cc: [email protected] > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Locator/ID Separation Protocol > > Working Group of the IETF. > > > > Title : An Architectural Introduction to the LISP > > Location-Identity Separation System > > Authors : Albert Cabellos > > Damien Saucez > > Filename : draft-ietf-lisp-introduction-05.txt > > Pages : 24 > > Date : 2014-09-22 > > > > Abstract: > > This document describes the Locator/ID Separation Protocol (LISP) > > architecture, its main operational mechanisms as well as its design > > rationale. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-lisp-introduction-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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
