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

[Ballot comment]

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

[Ballot comment]
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?

[Ballot comment]
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

[Ballot comment]
"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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-lisp-impact-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (LISP Impact) to Informational RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Impact'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Locator/Identifier Separation Protocol (LISP) aims at improving
  the Internet routing scalability properties by leveraging on three
  principles: address role separation, encapsulation, and mapping.  In
  this document, based on implementation work, deployment experiences,
  and theoretical studies, we discuss the impact that the deployment of
  LISP can have on both the routing infrastructure and the end-user.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ballot/


No IPR declarations have been submitted directly on this I-D.