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

Luigi Iannone <> Sat, 17 October 2015 19:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D0F11ACD36 for <>; Sat, 17 Oct 2015 12:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IR_z9xCAXDYl for <>; Sat, 17 Oct 2015 12:50:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F3DB1ACD31 for <>; Sat, 17 Oct 2015 12:50:52 -0700 (PDT)
Received: by wicfv8 with SMTP id fv8so30579715wic.0 for <>; Sat, 17 Oct 2015 12:50:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Bn3EtCjoJ037qsJPuKosYQjlYF9JjjwMSiM5vRbbj9U=; b=OIqDQlysk2qu59rt1RAe4T1nGhHptawRzRXS0SoxqBqYdmJI6lcl89TX06QlHykYGt 3vI5mJQGWBcDpiMnKZ1Nky7WiNCUdDQJDSxCwoMgRbTLgOpWLtCLmY192CItRgTgHwO+ u13hZvcUNnP48W3MeYvPL1wY8VGH1WEPPe4ykXGfv9QqJar48L/I871unYHntxRkBxXB 0pauZBCb03P4Br7xk15BbjMykFrVgSPxK/gwuuzWGjCZbS5R89xAGs9hsZa9PGtkXvdC xhjR2HcSyovz5IsBNZEruF49ByB4tLg64xO+g/oBXPaPWHDcZasju1XaHk9m+IFZWx9S Qksg==
X-Gm-Message-State: ALoCoQkWUoQTkADK1KNOHQnOBHnsFoW30+maRScm0ShBUVyvfA2Tmu6PUnawJ9aPmMAW01DsK1tQ
X-Received: by with SMTP id a12mr501472wib.37.1445111450715; Sat, 17 Oct 2015 12:50:50 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id bd4sm24095843wjb.15.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Oct 2015 12:50:49 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Sat, 17 Oct 2015 21:50:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3094)
Archived-At: <>
Cc:, IETF Gen-ART <>, IETF <>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-lisp-impact-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Oct 2015 19:50:54 -0000

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.



> On 14 Oct 2015, at 18:50, Russ Housley <> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> 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.