Hi Brian, Thank you for reviewing. Please find replies to you comments inline.
On 7/10/13 7:18 AM, Brian E Carpenter wrote:
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)?
I'm not sure a change in the title is warranted (please suggest a new title if you think it is), but I agree the Abstract should be reworded. How about this new text replacing the old one:
This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the authors as of Summer 2013. LISP deployment scenarios may have evolved since. This memo represents one stable point in that evolution of understanding.
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?
I was hoping we addressed these concerns in Section 5.3, Proxy-ITR Route Distribution (PITR-RD). I agree that altruism doesn't work, that's why the PITR-RD scenario is based on business relationships between different providers. When someone registers a domain name, he/she pays an annual fee that should cover the operating expenses for publishing the domain in the global DNS. The situation is similar with several other registration services. When someone contacts a mapping service provider (MSR), to get their prefix registered in the LISP mapping system, they get the option of signing up for PITR services as well, for an extra fee. These services may be offered by the MSP themselves, but it is expected that specialized P-ITR service providers (PSPs) will do it. If they don't sign up, they become responsible for getting non-LISP traffic to their EIDs (using the LISP+BGP scenario).
Additionally, Tier 1 ISPs may offer P-ITR services to non-subscribers in strategic places just to attract more traffic from competitors, thus more revenue.
Should we add anything to this section to resolve the comment?
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.
draft-ietf-lisp-threats discusses general LISP deployment security issues, without analyzing all scenarios described in draft-ietf-lisp-deployment. I'm not sure such an iterative approach is necessary, unless scenario specific threats are discovered.
Best regards, -Lori _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
