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

[Luigi Iannone <[e-mail]>]

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 <[e-mail]> 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