Hi Lori, see in line.
On 12/07/2013 00:48, Lori Jakab wrote:
> 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.
That's good. I don't feel strongly about the title.
>
>
>>
>> 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 explanation you have just written is quite informative. We're a bit
shy in the IETF about discussing incentives, but I think your explanation
would fit nicely into the draft. (I'm embarassed that we didn't
get this right for 6to4.)
>> 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.
I expect you will be getting a Security Area review, so maybe
you'd better go by that.
Brian
>
> Best regards,
> -Lori
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
