Locator/ID Separation Protocol (LISP) Impact
draft-ietf-lisp-impact-05

I won't oppose the publication of this document.

The document is well-written and clear.  However, for my taste, it read too much like a combination of marketing, a white paper I might find on a vendor's site, and an overview (with pointers to interesting research papers).  I also thought of the relationship with draft-ietf-lisp-introduction and wondered why some of the information in this document wasn't just included there..  Nothing necessarily wrong with all that, it just leaves me feeling unsatisfied.  I don't think there's anything to be done to change that feeling.

It seems odd to me that an "impacts" paper would leave security impacts out of scope. Even with the detailed security considerations in draft-ietf-lisp-threats, it seems like there might be some higher-level observations to make, along the lines of the rest of the draft.

Along those lines, if you want to refer to draft-ietf-lisp-threats for security considerations, it needs to be a normative reference.

Hello,

There was no follow up or changes (it seems) as a result of the SecDir review.  It would be helpful to address the questions on the aim of this draft and how it applies to security for the user and impact of LISP.
https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html

"RLOC" is spelled out on second use, but not on first use.

"Addresses are semantically separated in two:" was a bit rough for me. Perhaps something like "Addresses have two components with different semantic meanings:"?

In this text:

   Middle boxes/filters:  because of encapsulation, the middle boxes may
         not understand the traffic, which can cause a firewall to drop
         legitimate packets.  In addition, LISP allows triangular or
         even rectangular routing, so it is difficult to maintain a
         correct state even if the middle box understands LISP.
         Finally, filtering may also have problems because they may
         think only one host is generating the traffic (the ITR), as
         long as it is not de-encapsulated.  To deal with LISP
         encapsulation, LISP aware firewalls that inspect inner LISP
         packets are proposed [lispfirewall].

I wonder if we're far enough along with RFC 7258/BCP 188 that we expect middleboxes may not understand traffic, whether it's encapsulated or not, because of encryption. Perhaps that's worth a thought, if not a mention.

- section 3: "proven by several studies" without references is
bad - we don't want blatent assertion in RFCs so please add
some references. That could be done via forward pointers to
later in the document or just by adding the refs here as well
and explaining them more later. Or else delete the sentence as
being redundant.

- section 3, para starting "Results indicate...": Which
results? I can't tell from how it's writen.

- section 4: ConteXtream needs a reference as does the tier-1
operator (even if that has to be "private communication"at
least I'd know to go ask the authors if I care.

- I think you could note that as a map-and-encap scheme LISP
also offers the potential for encryption of traffic between
xTRs and reference the relevant lisp-crypto draft. That could
go where you add a mention of rfc 7258 if you do add that.
(In response to I think Spencer's comment.)

- As with Kathleen, I think the secdir review deserves a
substantive response. Please give it one.

Hi, 
Thanks for producing this document, and appreciate the honesty contained therein.

I have two suggestions.

From the introduction "The main goal of LISP is to make the routing infrastructure.." please consider s/is/was/ given the tone of the rest of the document and the discussions underway regarding the WG.

Section 2, second paragraph "Provider (interdomain) Aggregatable";  I think "interdomain" is superfluous here.

Thanks
Terry