Albert, I agree with all your changes and suggestions. Thanks. Dino
> On Jan 16, 2015, at 8:14 AM, Albert Cabellos <[email protected]> > wrote: > > > Hi > > Thank you very much for the review, please see inline my replies: > >> On Jan 14, 2015, at 7:10 PM, Dino Farinacci <[email protected]> wrote: >> >> Here are some brief responses to your comments Brian. Thanks for doing the >> throuogh review. >> >>> On Jan 14, 2015, at 8:26 AM, Brian Haberman <[email protected]> >>> wrote: >>> >>> All, >>> I have completed by AD Evaluation of draft-ietf-lisp-introduction >>> as a part of the IETF publication process. I have some >>> comments/questions that should be resolved prior to starting an IETF >>> Last Call. Please let me know if you have any questions on these... >>> >>> 1. Section 1 >>> >>> * I am going to try and short-circuit the inevitable question that will >>> arise about the reference [Chiappa]. Since it is a web page, the RFC >>> Editor will be concerned by its long-term stability. Is that the best >>> reference for that text? Anything similar that has been published in a >>> conference/journal/RFC/etc.? >> >> I will yield to the authors. > > Unfortunately I´ve been unable to find a more “stable” publication. However > the exact same document is cited in RFC4423 with the following “disclaimer”: > > "(…) the unpublished Internet Draft "Endpoints and Endpoint Names" [10] by > Noel Chiappa (…)” > > Please let me know if adding a similar sentence is enough. > >> >>> * The text uses the terms underlay and overlay without any context (in >>> the summary bullets). This is easily fixed by augmenting the text in >>> the 2nd paragraph to identify which networks form the underlay and the >>> overlay. >> >> Those terms aren't used very much in RFC 6830 because those terms seem to >> become fashionable with the advent of nv03. If the authors want to continue >> to use those terms, I have no problem with that, but would suggest that the >> Definition of Terms section say that the underlay is what is referred to in >> RFC 6830 as "the underlying core routing system". And that an "overlay" is >> the encapsulation relationship between ITRs, ETRs, PxTRs, and RTRs. > > I think that the second paragraph already introduces many new and important > concepts, what about updating the first two bullet points? > > o RLOCs have meaning only in the underlay network, **that is the > underlying core routing system.** > > o EIDs have meaning only in the overlay network unless they are leaked > into the underlay network. **The overlay is the encapsulation relationship > between LISP-capable routers.** > >> >>> 2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/ >>> > > Thanks for catching this typo. > >>> 3. Section 3.2 >>> >>> * Is it correct to say that EIDs are only routable at the edge? This >>> seems to contradict the text in section 3.5 that says EIDs may be >>> injected in the global routing system. >> >> Well it depends on your reference point. If the overlay is the center of >> perspective, then the global routing system is a non-LISP site relative to >> the overlay. The whole point is that EIDs are routable where LISP is not >> available. And that is true inside of a LISP site where packets are at a >> point in the data-path pre-encapsulation or post-decapsulation. >> > > What about changing the last sentence to: > > Because of this, EIDs are usually routable at the edge (within LISP sites) or > in the non-LISP Internet. > >>> * I find the PI and PA analogies misleading. EIDs are global, but they >>> may change their point of attachment. If that occurs, you are not >>> guaranteed that your EID space does not change. >> >> It is desirable that your EIDs do not change. But the scope of EID mobility >> may be limited and if a legacy site wants to continue to use DHCP and >> address addresses out of, say an enterprise address pool, it should be able >> to do that while losing session survivability features. That is a decision >> for the organization that is supporting mobility into its own domain. > > I suggest removing both analogies (PI and PA), two sentences overall. > >> >>> * In the example, bullet four mistakenly says that the destination >>> address of the outer header is set to RLOC_B2 (it should be RLOC_b1). >>> > > Thanks > >>> 4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel >>> Routers) with no real description of how it functions or relates to ITRs >>> and ETRs. >> >> Well there are references to it in RFC 6830 and there are many use-cases for >> them which we are not allowed to reference since the drafts are not working >> group documents. >> > > What about extending the last sentence of the paragraph? > > Typically such functions are implemented by Reencapsulating Tunnel Routers > (RTRs), **An RTR can be thought as a router that first acts as an ETR by > decapsulating packets and then as an ITR by encapsulating them towards > another locator.** > > >>> 5. Section 3.4.3 makes reference to the LISP WG. Given that this >>> document will probably outlive the WG, I would suggest re-wording to >>> remove a direct reference to the WG. > > Updated sentence: > > Many of the existing mechanisms to create distributed systems have been > explored and considered for the Mapping System architecture: > >>> >>> 6. Section 3.4 has no discussion of EIDs and NATs. Given the global >>> nature of the mapping system, it would seem that NATs don't play well >>> with LISP. There should be some discussion of that. >> >> LISP plays very well with NATs and we have many use-cases which are alive >> and being used. But again the draft on NAT-traversal is not a working group >> document so it is hard to reference it. EIDs are translatable by NATs and so >> are RLOCs. It all depends where the xTR resides (on the public versus >> private side of the NAT). > > I will add a paragraph summarizing section 7 of RFC6832 at the end of section > 3.5. > >> >>> 7. Section 4.1 >>> >>> * s/requires of a /requires a/ >>> > > Thanks > >>> * The discussion of SMR should contain a reference to 6830 or a brief >>> discussion of how the SMR is used. >>> > > Could you please elaborate further this comment? > > "Solicit-Map-Request (SMR): SMR is an explicit mechanism to update > mapping information. In particular a special type of Map-Request > can be sent on demand by ETRs to request refreshing a mapping. > Upon reception of a SMR message, the ITR must refresh the bindings > by sending a Map-Request to the Mapping System." > >>> 8. Section 5 >>> >>> * I would suggest having a reference to both the MIP and the NEMO specs >>> when discussing mobility. LISP has the potential to operate in a manner >>> conducive with NEMO if the xTR acts as the NEMO Mobile Router. >> >> Well if we do that then there are a ton of other cases where a xTR can be >> co-located with other functions (i.e. a simple reference is say a wifi AP). >> So singlingly out MIP/NEMO seems to be favoring these technologies versus >> others. Why would we want to do that? >> >> Plus, it raises questions more than simplifies the understanding of LISP. >> This is an intro document. > > What about adding the following sentence at the end of section 5? > > The decoupled identity and location provided by LISP allows it to operate > with other layer 2 and layer 3 mobility solutions. > >> >>> * Should there be some discussion of the mapping system's TTL mechanism >>> impact on mobility support? >> >> The TTL is not used for mobility to work. It is the SMR and Map-Notify >> mechanisms between xTRs and the mapping system and xTRs, respectively. > > True, but mappings from LISP mobile nodes are expected to have a low TTL (1 > min), what about updating the last paragraph to: > > Whenever the device changes of RLOC, the xTR updates the RLOC of its > local mapping and registers it to its Map-Server, **typically with a low > TTL value (1min)**. To avoid the need > of a home gateway, the ITR also indicates the RLOC change to all > remote devices that have ongoing communications with the device that > moved. The combination of both methods ensures the scalability of > the system as signaling is strictly limited the Map-Server and to > hosts with which communications are ongoing. >> >>> 9. Section 9 talks about propagating multicast state as (S-EID, G). >>> Does that mean that multicast in LISP is really only allowed to be SSM? >> >> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC 6831 >> describes all PIM modes. >> > > What about rephrasing the last sentence of the Multicast section: > > LISP [RFC6831] supports all PIM modes, additionally LISP can also support > non-PIM mechanisms to maintain multicast state. > > >>> 10. I am surprised that there are 2 Security Consideration sections (7 & >>> 9). I am even more surprised that one says "Nothing new here" and the >>> other actually discusses potential issues with the LISP approach. >>> > > My fault, Section 7 should be “LISP Security Considerations” > > Section 9 describes the security considerations for the document itself. > > Regards > > Albert > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
