[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).

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

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

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?

Dino


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