Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04

Jari Arkko <jari.arkko@piuha.net> Thu, 22 October 2015 13:13 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01CA1A88A3; Thu, 22 Oct 2015 06:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ybjZmCHEpiWz; Thu, 22 Oct 2015 06:13:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id D38491A889B; Thu, 22 Oct 2015 06:13:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BE9C02CEA1; Thu, 22 Oct 2015 16:13:38 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdgrfbu8b4bU; Thu, 22 Oct 2015 16:13:37 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 9515A2CC6B; Thu, 22 Oct 2015 16:13:36 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_7D6167F7-A7F1-461F-83DE-3D73E99B660D"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <A15B2808-2BAD-418D-A515-2054557AFFE7@gigix.net>
Date: Thu, 22 Oct 2015 14:13:35 +0100
Message-Id: <1E44A0E5-BE1C-4B7A-A9E8-0BC4E8058753@piuha.net>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com> <4AC8F4E6-B5A6-46B0-9B0C-28350DAED68B@vigilsec.com> <F49DAA01-500E-443D-8229-DA64ACD9CEA3@gigix.net> <96E7F474-F7B5-43F0-B0F2-C36E6D4CA232@gmail.com> <A15B2808-2BAD-418D-A515-2054557AFFE7@gigix.net>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/CNbrR0WEYffTjgT3zfWcOls245M>
Cc: draft-ietf-lisp-impact.all@ietf.org, IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 13:13:59 -0000

Thanks for the edits & review.

Jari

On 17 Oct 2015, at 20:50, Luigi Iannone <ggx@gigix.net> wrote:

> Hi Russ,
> 
> thanks for the review.
> Inline you can find our propose changes in order to fix the issues.
> 
> Let us know if such proposed changes are sufficient.
> 
> ciao
> 
> Luigi
> 
> 
> 
>> On 14 Oct 2015, at 18:50, Russ Housley <housley@vigilsec.com> wrote:
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-lisp-impact-04
>> Reviewer: Russ Housley
>> Review Date: 2015-10-14
>> IETF LC End Date: 2015-10-19
>> IESG Telechat date: unknown
>> 
>> Summary:  Almost Ready.
>> 
>> 
>> Major Concerns:
>> 
>> Section 3 says: "[KIF13] and [CDLC] explore different EDI prefix space
>> sizes, and still show results that are consistent and equivalent to the
>> above assumptions."  It seems like it would be valuable to include a
>> sentence or two about the way that EDI space is obtained.
> 
> 
> What if we modify the paragraph as follows:
> 
> 	[KIF13] and [CDLC] explore different EID prefix space sizes, and
> 	still show results that are consistent and equivalent to the above
> 	assumptions. In particular, [KIF13] looks at what happens using all
> 	possible /24 and /27 as fixed-size prefixes, while [CDLC] filters out
> 	all de-aggregation from the BGP routing infrastructure (hence including
> 	PA addresses).
> 
> 
>> 
>> 
>> Minor Concerns:
>> 
>> I found the Introduction and LISP in a nutshell sections a bit too
>> much like marketing material.  I think the document would be better
>> if the tone was more like an engineering analysis.
>> 
>> Perhaps this paragraph can be moved to the top:
>> 
>> An introduction to LISP can be found in [RFC7215].  The LISP
>> specifications are given in [RFC6830], [RFC6833],
>> [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].
>> 
> 
> We think that the solution would be:
> 
> 1. Move the last paragraph as actually the first (as you suggest)
> 
> 2. Re-word the second-last paragraph
> 
> OLD Version:
> 
> 	The correspondence between EIDs and RLOCs is given by the mappings.
> 	When an ITR needs to find ETR RLOCs that serve an EID, it queries a
> 	mapping system.  With the LISP Canonical Address Format (LCAF)
> 	[I-D.ietf-lisp-lcaf], LISP is not restricted to the Internet Protocol
> 	for the EID addresses.  With LCAF, any address type can be used as
> 	EID (the address is only the key for the mapping lookup).  LISP can
> 	transport, for example, Ethernet frames over the Internet.
> 
> NEW Version:
> 
> 	The correspondence between EIDs and RLOCs is given by the mappings.
> 	When an ITR needs to find ETR RLOCs that serve an EID, it queries a
> 	mapping system.  The LISP Canonical Address Format (LCAF)
> 	[I-D.ietf-lisp-lcaf] allows LISP to use addresses other than the Internet Protocol.
> 	Such address are used as lookup key in the mapping system.
> 	In this way it is possible, for example, to LISP-encapsulate Ethernet frames.
> 
> 
>> Section 5 has very little content on "business models".  There is some,
>> but not much.  It seems odd that it appears in the section heading.
> 
> That is correct. There is very little about business.
> We can simplify the title to: "Impact of LISP on network operations”
> 
> 
>> 
>> 
>> Other Comments:
>> 
>> Please spell out "DPI" and "DFZ" on first use.
> 
> Consider it done.
> 
>> 
>> Section 4 says: "Without LISP, operators are forced to centralize
>> service anchors in custom built boxes."  This seems a bit too strong.
>> Perhaps: "Without LISP, operators centralize service anchors.”
> 
> Much more straightforward. Thanks.
> 
> 
>> 
>> Section 4.1: s/(non-LISP)routing/(non-LISP) routing/
> 
> Thanks for the catch.
> 
> ciao
> 
> Luigi
> 
>