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

[Jari Arkko <[e-mail]>]

Thanks for the edits & review.

Jari

On 17 Oct 2015, at 20:50, Luigi Iannone <[e-mail]> 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 <[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
> 
>