Ran Atkinson wrote in:
http://www.ietf.org/mail-archive/web/rrg/current/msg06462.html
As I've said before, ILNP can work with IPv4 as well as IPv6.
Of course, the engineering varies, but the architecture is the
same.
ILNP, like other Core-Edge Elimination (Locator / Identifier
Separation) architectures cannot provide scalable routing benefits in
IPv4, since its use for multihoming involves using at least 3 times
the current amount of global unicast address space used by the
end-user network. This is completely impractical given the shortage
of IPv4 global unicast space. (There is no such problem with
Core-Edge Separation architectures such as LISP, Ivip or IRON-RANGER.)
All these CEE architectures (ILNP, GLI-Split, RANGI, Name Based
Sockets, GSE etc.) provide multihoming, portability and perhaps
mobility by having host sessions established and maintained by using
something other than the IP address: specifically an "Identifier".
Then, when a host's network changes to another ISP, it gets a
different "Locator" (such as a different IP address), but retains its
"Identifier" - and the protocols ensure that sessions survive.
If the host is in a network multihomed to two ISPs, then the network
gets a prefix of space from its ISP-A and another prefix from ISP-B.
The host has an IP address ("Locator") in each such prefix.
Multihoming involves sessions being maintained no matter which
"Locator" a host is using.
Scalability is achieved because each prefix can be a PA prefix from
each ISP. So ISP-A advertises a single short prefix in the DFZ,
which it uses small portions of for many such end-user networks - and
ISP-B does the same. The two ISPs could support very large numbers
of multihomed, portable end-user networks with just these two DFZ
advertised prefixes.
This can achieve scalable routing benefits in IPv6. In principle it
could work fine in IPv4 too, provided there was no attempt to include
the "Identifier" in the IP address, since at 32 bits, it is way to
short to do this. (ILNP does this, and this is one reason it can't
work for IPv4.)
However, there is a more fundamental reason why none of these CEE
architectures, ILNP included, can provide scalable routing benefits
for IPv4:
For each dual-homed end-user network with S global unicast IP
addresses, the system requires a total of S*3 global unicast
IP addresses:
S IP addresses for the hosts in the end-user network
S IP addresses for the PA prefix from ISP-A
S IP addresses for the PA prefix from ISP-B
This is impractical for widespread adoption, given the IPv4 address
space shortage.
Ran, I have raised this critique several times and AFAIK you have
never responded to it.
Your "can work" statement about ILNP in the context of the RRG is
effectively a statement that it not only could work but that it could
also provide scalable routing benefits for IPv4. But this is
completely at odds with reality.
I think your work is far too theoretical - too concerned with some
supposedly "high-level", ""architectural"" matters of principle, and
avoidant of important details which you might regard as mere
"engineering details".
For more reasons why CEE architectures are unsuitable for adoption,
see section 17.4 of msg06219. Please also see msg06250.
BTW, Ran objects to the Core-Edge Elimination vs. Core-Edge
Separation dichotomy, but has never given detailed arguments against it.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
