Locator/ID Separation Protocol (LISP) Impact
RFC 7834

Note: This ballot was opened for revision 04 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

(Ben Campbell) No Objection

Comment (2015-10-20 for -04)
No email
send info
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.

(Spencer Dawkins) No Objection

Comment (2015-10-21 for -04)
No email
send info
"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.

(Stephen Farrell) No Objection

Comment (2015-10-22 for -04)
No email
send info
- 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.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

Comment (2015-10-20 for -04)
No email
send info
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

(Kathleen Moriarty) No Objection

Comment (2015-10-21 for -04)
No email
send info
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

Alvaro Retana No Objection

Comment (2015-10-20 for -04)
No email
send info
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.

(Alia Atlas) Abstain

Comment (2015-10-21 for -04)
No email
send info
The opening of this draft 
"The Locator/Identifier Separation Protocol (LISP) relies on three
   principles to improve the scalability properties of Internet routing:
   address role separation, encapsulation, and mapping.  The main goal
   of LISP is to make the routing infrastructure more scalable by
   reducing the number of prefixes announced in the Default Free Zone
   (DFZ)."
is targeted at solving the Internet scalability issue for Internet routing.
While the document goes into some details about rather large unknowns
and issues observed, it does not have any indications or caveats up
front that this is still experimental work - certainly as far as solving this
Internet-scale problem.

At a minimum, I think there need to be clear caveats on the experimental
nature, on the aspects still to be understood, and on the complexity and
concerns around the operational and security aspects.

While LISP is a really neat idea and it's good to see how far work and
research on it has progressed, this document reads much more like
marketing than something discussing the engineering and operational
trade-offs.

1) There is no discussion of what the "mapping system" is and I think
that some of the discussion is assuming the use of BGP, but it's a bit hard
to tell.  At a minimum, it'd be good to clarify whether an Internet-scale
deployment must use the same mapping system and what the trade-offs
there are.

2) In Sec 4.1, "When there are several RLOCs, the ITR selects the one with
   the highest priority and sends the encapsulated packet to this RLOC.
   If several such RLOCs exist, then the traffic is balanced
   proportionally to their weight among the RLOCs with the lowest
   priority value."

It is unclear whether the "highest priority" means the lowest priority value.
Please clarify because it incorrectly sounds like the highest priority RLOC
is picked - unless there are multiple in which case load-balancing among the
lowest priority value RLOCs is done.

3) Sec 5.1 "Proxies cause what is referred to as path stretch and make
   troubleshooting harder."  This doesn't actually describe what path stretch
is in any way.  I can guess from the name, but that's not sufficient.

4) In Sec 5.2: "Deployment in the beta network has shown that LISP+ALT
         ([RFC6836], [CCR13]) was not easy to maintain and control,
         which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]"
Can you give a reference or indicate what the benefits of DDT are as
compared to ALT in this context?