[lisp] AD Evaluation: draft-ietf-lisp-introduction

Brian Haberman <brian@innovationslab.net> Wed, 14 January 2015 16:26 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12BE1A9024 for <lisp@ietfa.amsl.com>; Wed, 14 Jan 2015 08:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCMCD24mutF8 for <lisp@ietfa.amsl.com>; Wed, 14 Jan 2015 08:26:23 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45231A901F for <lisp@ietf.org>; Wed, 14 Jan 2015 08:26:22 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AEF9288119; Wed, 14 Jan 2015 08:26:22 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3AEE671C0002; Wed, 14 Jan 2015 08:26:22 -0800 (PST)
Message-ID: <54B698A7.1080309@innovationslab.net>
Date: Wed, 14 Jan 2015 11:26:15 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "lisp@ietf.org" <lisp@ietf.org>, draft-ietf-lisp-introduction@tools.ietf.org, "lisp-chairs@tools.ietf.org" <lisp-chairs@tools.ietf.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="IKbSwj5KKpejpDOlGNNtbMGJHqqx8K79P"
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/BRaWj3CggRcLqU_PB6sPFwQ4S3U>
Subject: [lisp] AD Evaluation: draft-ietf-lisp-introduction
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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, 14 Jan 2015 16:26:29 -0000

All,
     I have completed by AD Evaluation of draft-ietf-lisp-introduction
as a part of the IETF publication process.  I have some
comments/questions that should be resolved prior to starting an IETF
Last Call.  Please let me know if you have any questions on these...

1. Section 1

* I am going to try and short-circuit the inevitable question that will
arise about the reference [Chiappa].  Since it is a web page, the RFC
Editor will be concerned by its long-term stability.  Is that the best
reference for that text?  Anything similar that has been published in a
conference/journal/RFC/etc.?

* The text uses the terms underlay and overlay without any context (in
the summary bullets).  This is easily fixed by augmenting the text in
the 2nd paragraph to identify which networks form the underlay and the
overlay.

2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/

3. Section 3.2

* Is it correct to say that EIDs are only routable at the edge?  This
seems to contradict the text in section 3.5 that says EIDs may be
injected in the global routing system.

* I find the PI and PA analogies misleading.  EIDs are global, but they
may change their point of attachment.  If that occurs, you are not
guaranteed that your EID space does not change.

* In the example, bullet four mistakenly says that the destination
address of the outer header is set to RLOC_B2 (it should be RLOC_b1).

4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel
Routers) with no real description of how it functions or relates to ITRs
and ETRs.

5. Section 3.4.3 makes reference to the LISP WG.  Given that this
document will probably outlive the WG, I would suggest re-wording to
remove a direct reference to the WG.

6. Section 3.4 has no discussion of EIDs and NATs.  Given the global
nature of the mapping system, it would seem that NATs don't play well
with LISP.  There should be some discussion of that.

7. Section 4.1

* s/requires of a /requires a/

* The discussion of SMR should contain a reference to 6830 or a brief
discussion of how the SMR is used.

8. Section 5

* I would suggest having a reference to both the MIP and the NEMO specs
when discussing mobility.  LISP has the potential to operate in a manner
conducive with NEMO if the xTR acts as the NEMO Mobile Router.

* Should there be some discussion of the mapping system's TTL mechanism
impact on mobility support?

9. Section 9 talks about propagating multicast state as (S-EID, G).
Does that mean that multicast in LISP is really only allowed to be SSM?

10. I am surprised that there are 2 Security Consideration sections (7 &
9).  I am even more surprised that one says "Nothing new here" and the
other actually discusses potential issues with the LISP approach.

Regards,
Brian