Subject: Gen-ART Review of draft-ietf-lisp-impact-04

From: Russ Housley <[email-masked]>
Date: Wed, 14 Oct 2015 12:50:34 -0400

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.

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

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.

Other Comments:

Please spell out "DPI" and "DFZ" on first use.

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

Section 4.1: s/(non-LISP)routing/(non-LISP) routing/

---

From: Luigi Iannone <[email-masked]>
Date: Sat, 17 Oct 2015 21:50:46 +0200

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 <[email-masked]> wrote:
> 

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

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

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

> Please spell out "DPI" and "DFZ" on first use.

Consider it done.

> 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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Oct 2015 14:13:35 +0100

Thanks for the edits & review.

Jari