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(_at_)vigilsec(_dot_)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