Hi Luigi, Yes, Adrian also picked up on the "typically" for EID and RLOC and the proposed response fixes that as well as the BGP issues.
I don't recall seeing the "oh, routers can just do with with a software upgrade" claim fixed. Regards, Alia On Thu, Mar 5, 2015 at 4:32 PM, Luigi Iannone <[email protected]> wrote: > Hi Alia > > thanks for the review. > > I have just one comment right in the middle of your review. > > > On 05 Mar 2015, at 16:14, Alia Atlas <[email protected]> wrote: > > > > Alia Atlas has entered the following ballot position for > > draft-ietf-lisp-introduction-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Adrian's discuss. In a similar vein: > > > > In Sec 3.2: Please either remove the claim of "Such LISP capable > > routers, in most cases, only require a software upgrade." or explain > > how you can justify the need to add and remove new encapsulations and > > handle the various flag triggers and caching at line rate. There is > > no need for such marketing in this document. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 1) Sec 1, second paragraph: > > "LISP creates two separate namespaces, EIDs (End-host IDentifiers) > > and > > RLOCs (Routing LOCators), both are typically syntactically identical > > to the current IPv4 and IPv6 addresses." > > > > What does "typically" mean? As far as I'm aware, they are > > syntactically identical. This is reiterated in Sec 3.2; are you just > > trying to preserve the point of architectural freedom? I've found > > the > > third instance of insisting that the EID or RLOC now is only > > "typically" > > an IPv4 or IPv6 address. Please lose "typically". Minorly, the , > > before both should be a ;. > > > > I think that the changes the authors already proposed to Adrian fix the > above Discuss and comments. > Can you check if I am correct? > > From this point down is just typos/grammar, so authors will easily fix > your helpful comments > > thanks again > > ciao > > L. > > > > > > > 2) top paragraph of p.4: > > "The initial motivation in the LISP effort is to be found in the > > routing scalability problem [RFC4984], where, if LISP is completely > > deployed, the Internet core is populated with RLOCs while Traffic > > Engineering mechanisms are pushed to the Mapping System." > > > > Instead of "LISP is completely deployed" to "LISP were to be > > completely deployed" - making it subjunctive. > > > > 3) Last paragraph in Sec 1: > > "This document describes the LISP architecture, its main > > operational mechanisms as its design rationale." > > > > I think you mean > > > > "This document describes the LISP architecture and its main > > operational mechanisms as well as its design rationale." > > > > 4) In Sec 3.1, second paragraph: > > "Locator/Identifier split: By decoupling the overloaded semantics > > of the current IP addresses the Internet core can be assigned > > identity meaningful addresses and hence, can use aggregation to > > scale." > > I assume that you mean "topologically meaningful addresses" instead > > of "identity meaningful addresses". > > > > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
