Since you responded Brian to Albert's email and have commented and agreed to most of the changes, I don't need to respond to each point below. I think we are golden. Agree?
Dino > On Jan 19, 2015, at 6:45 AM, Brian Haberman <[email protected]> wrote: > > Hi Dino, > > On 1/14/15 1:10 PM, Dino Farinacci 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. >> >>> * 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. > > That is fine with me. > >> >>> 2. Section 3 (and a few times in 3.5) : >>> s/inetrworking/internetworking/ >>> >>> 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. > > I agree with what you say above, but the document explicitly says EIDs > are only routable at the edge and that is not the case in non-LISP parts > of the Internet. The document just needs to be more explicit on that point. > >> >>> * 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. > > Given my concern and your comment above, how does the EID/PI analogy hold? > >> >>> * 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). >>> >>> 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. > > So, Section 3.3.1 should point the reader to 6830 when it mentions the RTR. > >> >>> 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. >>> >>> 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). > > Even though the NAT-traversal draft is not a WG draft, this document can > spend a few cycles talking about the general ability of LISP to operate > in the face of NATs. > >> >>> 7. Section 4.1 >>> >>> * s/requires of a /requires a/ >>> >>> * The discussion of SMR should contain a reference to 6830 or a >>> brief discussion of how the SMR is used. >>> >>> 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? > > MIP and NEMO are the general modes of mobility that most closely > approximate what is being discussed in Section 5. My thought was to > give the reader a basis for how mobility in LISP operates, including the > drawbacks. > >> >> Plus, it raises questions more than simplifies the understanding of >> LISP. This is an intro document. >> >>> * 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. > > Shouldn't that be mentioned somewhere in this draft? > >> >>> 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. > > So, to avoid erroneous assumptions, perhaps the intro should mention that. > > Regards, > Brian > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
