Hi,
Hereafter my comments on the architecture draft.
Florin
LISP Working Group J. N. Chiappa
Internet-Draft Yorktown Museum of Asian Art
Intended status: Informational October 15, 2012
Expires: April 18, 2013
An Architectural Perspective on the LISP
Location-Identity Separation System
draft-ietf-lisp-architecture-00
[snip]
3.1. Another Packet-Switching Layer
When considering the overall structure of the LISP system at a high
level, it has proven most useful to think of it as another packet-
switching layer, run on top of the original internet layer - much as
the Internet first ran on top of the ARPANET.
All the functions that a normal packet switch has to undertake - such
as ensuring that it can reach its neighbours, and they
FC: that
they are still
up - the devices that make up the LISP overlay also have to do, along
the 'tunnels' which connect them to other LISP devices.
[snip]
4.2. Need for a Mapping System
LISP does need to have a mapping system, which brings design,
implementation, configuration and operational costs. Surely all
these costs are a bad thing? However, having a mapping system have
FC: has/brings
advantages, especially when there is a mapping layer which has global
visibility (i.e. other entities know that it is there, and have an
interface designed to be able to interact with it). This is unlike,
say, the mappings in NAT, which are 'invisible' to the rest of the
network.
[snip]
5. Namespaces
One of the key elements in any architecture, or architectural
analysis, are the namespaces involved: what are their semantics and
syntax, what are the kinds of things they name, etc.
LISP has two key namespace, EIDs and RLOCs, but it must be emphasized
that on an architectural level, neither the syntax, or, to a lesser
degree, the semantics, of either are absolutely fixed. There are
certain core semantics which are generaly unchanging (such as the
notion that EIDs provide only identity, whereas RLOCs provide
location), but as we will see, there is a certain amount of
flexibility available for the long-term.
In particular, all of LISP's key interfaces always include an Address
Family Identifier (AFI) [AFI] for all names, so that new forms can be
introduced at any time the need is felt. Of course, in practise such
an introduction would not be a trivial exercise - but neither is is
FC: remove one is
impossibly painful, as is the case with IPv4's 32-bit addresses,
which are effectively impossible to upgrade.
[snip]
5.1.1. Residual Location Functionality in EIDs
LISP retains, especially in the early stages of the deployment, in
many cases some residual location-naming functionality in EIDs,
FC: full stop
This
is to allow the packet to be correctly routed/forwarded to the
destination node, once it has been unwrapped by the ETR - and this is
a direct result of LISP's deployment philosophy (see [Introduction],
Section "Deployment").
[snip]
5.3. Overlapping Uses of Existing Namespaces
It is in theory possible to have a block of IPvN namespace used as
both EIDs and RLOCs. In other words, EIDs from that block might map
to some other RLOCs, and that block might also appear in the DFZ as
the locators of some other ETRs.
This is obviously potentially confusing - when a 'bare' IPvN address
from one of these blocks, is it the RLOC, or the EID? Sometimes it
FC: drop one it
it obvious from the context, but in general one could not simply have
a (hypothetical) table which assigns all of the address space to
either 'EID' or 'RLOC'.
[snip]
6. Scalability
As with robustness, any global communication system must be scalable,
and scalable up to almost any size. As previously mentioned (xref
target="Perspectives-Packet"/), the large fanouts to be seen with
LISP, due to its 'overlay' nature, present a special challenge.
One likely saving grace is that as the Internet grows, most sites
will likely only interact with a limited subset of the Internet; if
nothing else, the separation of the world into language blocks means
that content in, say, Chinese, will not be of interest to most of the
rest of the world. This tendency will help with a lot of things
which could be problematic if constant, full, N^2 connectivity were
likely on all nodes; for example the caching of mappings.
FC: I would say that generally content tends to 'cluster' in a limited number
of servers/networks. Thus, the fanout is already limited. Moreover, I'm not
convinced content will be segregated based on social/cultural considerations
but on economical ones. Unfortunately, I'm right now lacking a good reference
to support the claim. But, [1] gives an idea about how 'popular' websites are
generally hosted by 'large' hosting providers.
[1]
http://www.pcworld.com/article/2012852/amazon-web-services-outage-takes-out-popular-websites-again.html
[snip]
The most important result of this change is that it avoids a
concentration of resolution request traffic at the root of the
indexing tree, a problem which by itself made ALT unsuitable for a
global-scale system. The problem of root concentration (and thus
overload) is almost unavoidable in ALT (even if masses of 'bypass'
links are created).
ALT's scalability also depends on enforcing an intelligent
organization that aincreases
FC: increases
aggregation. Unfortunately, the current
backbone routing BGP system shows that there is a risk of an organic
growth of ALT, one which does not achieve aggregation. DDT does not
display this weakness, since its organization is inherently
hierarchical (and thus inherently aggregable).
[snip]
11.2.1. Mapping Database Provider Lock-in
This refers to the fact that if one does not like the entity which is
providing the indexing for the part of the address space which one's
EIDs are allocated out of, there isn't probably isn't
FC: drop an "isn't"
any way to
switch to an alternative provider.
It is not clear that this is a real probem, though - the fact that
all DNS top-level zones only have a single registry has not been a
problem, nor has the fact that if one doesn't like the service the
registry offers, one can't take one's DNS name to another registry.
[snip]
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
