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.
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 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.
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?
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
