Subject: [Gen-art] Gen-ART LC review of draft-ietf-lisp-deployment-09.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jul 2013 16:18:41 +1200

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.

---

From: Lori Jakab <[email-masked]>
Date: Thu, 11 Jul 2013 15:48:37 +0300

Hi Brian,

Thank you for reviewing.  Please find replies to you comments inline.

> 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.

> clientele might be up to half the Internet, depending on who chooses to

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?

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jul 2013 08:17:05 +1200

Hi Lori, see in line.

>    one stable point in that evolution of understanding.

That's good. I don't feel strongly about the title.

> 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.)

> 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

---

From: Lori Jakab <[email-masked]>
Date: Wed, 17 Jul 2013 20:53:34 +0300

Hi Brian,

Should we post a new revision of the draft now, with the below changes, 
or should we wait for the security review first?

-Lori

---

From: Brian Haberman <[email-masked]>
Date: Wed, 17 Jul 2013 14:15:54 -0400

I would suggest waiting for the secdir review and generate a single 
update based on all reviews.

Regards,
Brian H.