Hi Marc Thanks for your comments, please see inline my replies:
On Tue, Oct 7, 2014 at 10:32 AM, Marc Binderberger <[email protected]> wrote: > > Hello Albert and Damien, > > some comments about your document. > > In the introduction: > > By taking advantage of such separation between location > and identity, the Internet core is populated with RLOCs which can be > quasi-static and highly aggregatable, hence scalable [Quoitin]. > > > Would reduce this statement to the fact that you need only RLOCs in the > Internet core. Address schemes that have a hierarchical structure across AS > are unlikely to fit the Internet. Nor is there any need, if the Internet core > can be reduced to infrastructure address ranges, i.e. a single or few > networks per AS, then it would be a huge reduction already. > What about this: Additionally, LISP’s approach to solve the routing scalability problem [RFC4984] is that with LISP the Internet core is populated with RLOCs whileTraffic Engineering mechanisms are pushed to the Mapping System [Quoitin]. With this RLOCs are quasi-static and hence, the routing system scalable [Quoitin]. > > > Overview of the Architecture: > > The edge are LISP sites (e.g., an > Autonomous System) that use EID addresses. EIDs are typically -but > not limited to- IPv4 or IPv6 addresses that uniquely identify > endhosts and are assigned and configured by the same mechanisms that > we have at the time of this writing. EIDs can be are typically > Provider Independent (PI [RFC4116]) addresses > > What you probably want to emphasize is that EIDs are independent from the > RLOC, thus the provider(s). Most IPv4 addresses are _not_ PI but PA, for IPv6 > you need to extra request PI (and some RIR do not support it). In case you > have your own AS you have in most cases PA addresses today. > > I would propose to _not_ use the PA and PI terms as they have a meaning (and > make sense) in today's routing setup. > > There is also the risk that readers interpret more into these terms. E.g. > some RIR tend to have direct end-customer contractual relation for PI but I > doubt for EID space the RIRs could handle the amount nor that you had this in > mind when writing it. > > In short: don't reuse these acronyms as they have already too much context :-) > The goal of the draft is to make easier to read the LISP specs, this requires explaining the big picture and, in some cases, simplifying. PIs are a great analogy to EIDs, what about this: EIDs do not contain inter-domain topological information and can be thought as Provider Independent (PI [RFC4116]) addresses. > > > the only > required changes to the existing infrastructure are to routers > connecting the EID with the RLOC space. Such LISP capable routers > typically require only a software upgrade. > > If you are lucky then it's just a software upgrade but "typically"? I would > remove this statement. The overall picture remains: overlay means you keep > the "core" untouched and your rollout problem is reduced to the edge systems, > which overall should be cost effective. > > What I am trying to say is that in most cases LISP only requires a software upgrade, again I am trying to explain the big picture with as few details as possible. What about this: Such LISP capable routers, in most cases, only require a software upgrade. > Mapping System: > > with the LISP Mapping System, > a publicly accessible database responsible of storing mappings. > > > The "publicly accessible" shows up multiple times (yes, consistent :-) . But > LISP mapping systems are only publicly accessible in the case of public > networks, like the Internet. Or do you want to emphasize that all xTRs must > be able to reach the mapping system? > > Agreed, I´ll change this on the upcoming draft. Thanks! Albert > Regards, Marc > > P.S.: I read/comment the other sections in the following days. > > > > > > On Mon, 22 Sep 2014 13:06:18 -0700, [email protected] wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Locator/ID Separation Protocol Working > > Group of the IETF. > > > > Title : An Architectural Introduction to the LISP > > Location-Identity Separation System > > Authors : Albert Cabellos > > Damien Saucez > > Filename : draft-ietf-lisp-introduction-05.txt > > Pages : 24 > > Date : 2014-09-22 > > > > Abstract: > > This document describes the Locator/ID Separation Protocol (LISP) > > architecture, its main operational mechanisms as well as its design > > rationale. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-lisp-introduction-05 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-introduction-05 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
