Thanks for the edits & review. Jari On 17 Oct 2015, at 20:50, Luigi Iannone <ggx@xxxxxxxxx> 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 <housley@xxxxxxxxxxxx> 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 > >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail