[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?
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,
I don't see it that way at all. So let me say first off, EIDs must not
be routed in the underlying network or we are defeating one of the
main purposes of the Loc/ID proposals.
Second, it's a question of address ownership and not routing. The SP
owns the block even though it doesn't route the block because it is
transitioning to a Loc/ID split environment.
However, if EIDs need to be routed, then existing constraints on
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-
Well we have two solutions in draft-lewis-lisp-interwork-01.txt
(coming out soon, -00 has existed for a while). But that wasn't the
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.
If you have seen the above draft, do you think Proxy Tunnel Routers
(PTRs) can be monetized. Rather than focusing on the cost, could we
focus on a revenue opportunity?
to unsubscribe send a message to firstname.lastname@example.org 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