Last Call Review of draft-ietf-lisp-deployment-08
review-ietf-lisp-deployment-08-genart-lc-carpenter-2013-07-10-00
Request | Review of | draft-ietf-lisp-deployment |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2013-07-15 | |
Requested | 2013-07-05 | |
Authors | Lorand Jakab , Albert Cabellos-Aparicio , Florin Coras , Jordi Domingo-Pascual , Darrel Lewis | |
I-D last updated | 2013-07-10 | |
Completed reviews |
Genart Last Call review of -08
by Brian E. Carpenter
(diff)
Genart Telechat review of -10 by Brian E. Carpenter (diff) Secdir Last Call review of -08 by Warren "Ace" Kumari (diff) |
|
Assignment | Reviewer | Brian E. Carpenter |
State | Completed | |
Request | Last Call review on draft-ietf-lisp-deployment by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 08 (document currently at 12) | |
Result | Almost ready | |
Completed | 2013-07-10 |
review-ietf-lisp-deployment-08-genart-lc-carpenter-2013-07-10-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-lisp-deployment-09.txt Reviewer: Brian Carpenter Review Date: 2013-07-10 IETF LC End Date: 2013-07-15 IESG Telechat date: Summary: Almost ready -------- Comments: --------- I was assigned to review -08, but -09 came out during Last Call. Issues: ------- The draft states in its Introduction that it "is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered." The desire to freeze a version of the draft as an RFC is understandable, but shouldn't the title and Abstract clearly indicate that it's a snapshot (and genuinely a request for comments)? In general the draft is clear and well written. If you believe that there are sufficient incentives for Tier 3 providers and large sites to deploy an experimental protocol such as LISP, the discussion is useful. However, I am disappointed by the limited discussion of scalability. In particular, the incentives to deploy P-ITRs and to announce routes to them will become a critical issue at the half-way stage between early transition (LISP is a minority solution) and late transition (LISP is the majority solution). According to RFC 6832, P-ITRs scale either because "aggregate routes might be selectively announced" or because "the same address might be announced by multiple Proxy-ITRs in order to share the traffic." I really expected the deployment draft to discuss this issue in more detail. As I believe has been said before, these issues are very similar to the issues facing the operators of a 6to4 forward or return relay. We have experimental evidence there that altruism doesn't work and the incentives to "donate" connectivity are insufficient. The analogy isn't perfect, but the underlying question is similar - what is the incentive for a particular operator to offer P-ITR service for a particular bunch of EID prefixes, when the clientele might be up to half the Internet, depending on who chooses to propagate the routes? The Security Considerations are minimal. I wonder if draft-ietf-lisp-threats identifies threats for each scenario described in draft-ietf-lisp-deployment? If not, the statement "Security implications of LISP deployments are to be discussed in separate documents." is rather optimistic.