[lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT)

"Alia Atlas" <akatlas@gmail.com> Wed, 21 October 2015 20:41 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: lisp@ietf.org
Delivered-To: lisp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0411ACDE9; Wed, 21 Oct 2015 13:41:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alia Atlas <akatlas@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151021204139.7539.98645.idtracker@ietfa.amsl.com>
Date: Wed, 21 Oct 2015 13:41:39 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/VNvAb5lAqKoEQvX6ySj_oazYGw8>
Cc: draft-ietf-lisp-impact.all@ietf.org, lisp-chairs@ietf.org, draft-ietf-lisp-impact@ietf.org, lisp@ietf.org
Subject: [lisp] Alia Atlas' Abstain on draft-ietf-lisp-impact-04: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 20:41:39 -0000

Alia Atlas has entered the following ballot position for
draft-ietf-lisp-impact-04: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/



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