[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Abstraction of problem space
Dino Farinacci wrote:
BTW - the ability to take a piece of IPv4 PA space, and start
announcing it as if it were PI space, is an example of the kind of
thing that needs to be supported.
Changing the role of a "piece" of the Internet, without renumbering.
So Brian, the decoupling that Loc/ID split gives you is attractive.
And if a site decides to use PA space as an EID-prefix, let's say
while it is still connected to the provider that owns it. If the site
decides to discontinue contract with the provider, gives back, say the
locator the CE box has assigned to it, what do you think should happen
to the PA block?
That is:
1) Do you lose EID address portability in this case because a site
decided to use PA space? And therefore doesn't get the
renumbering-avoidance benefit of Loc/ID split.
2) The service provider is willing to give up the space, which means
it routes only for a small part of this space (the locator space) and
not the entire larger space where EID-prefixes would be allocated out of?
Some of the struggles that can make LISP much more efficient is to
look at an address and tell from an allocation bits, if it's EID
versus RLOC space. Then you can interwork LISP sites with non-LISP
sites much more efficiently. Easier to do with IPv6 but we may
struggle with IPv4 because EID-prefixes could come out of all kinds of
allocations including PA space.
I think this turns on the question of, "Must an EID prefix be routable
and routed?".
If an EID is not routed, it doesn't need to meet certain requirements
that prefixes have to have, to be "routable".
Specifically, that a prefix must be of a certain minimum size (e.g. /24
in IPv4, /64 or even /48 for IPv6).
And, if EIDs are not routed, they can be allocated in a unique fashion
from the get-go, without needing aggregation, and possibly using
otherwise unusable address blocks (e.g. class E in IPv4, 240.0.0.0/4).
However, if EIDs need to be routed, then existing constraints on
prefixes apply.
In which case, the answers are:
1) Yes, you lose portability, and
2) Even if this is the case, the "hole-punching" in aggregates continues
to drive up the cost of routing, by further fragmenting the address
space and bloating the routing table(s).
I agree that interworking for LISP is a big issue, and I don't see a
good solution short of widely-deployed proxies for
otherwise-unroutable/unreachable prefixes.
The cost issues (asymmetrical costs - pushing some of the cost of
reaching LISP sites onto third parties, by way of ITR/ETR infrastructure
needed) are relevant, but only so far as LISP (and LISP-like) solutions
are concerned.
What I'm driving at is, I don't think we've yet found ways of making
mapping scale well enough, and that looking at the mapping in more
abstract ways may be a useful place for investigation for clean-slate
approaches.
E.g. topological and/or geographical inter-domain equivalents to "not-so
stubby areas", may be where we should be looking for ideas.
Brian
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg