Short version: Med's concern (as best I understand it) about DFZ
routers needing to carry routes for all end-user
prefixes in Ivip or LISP seems to be based on a
misunderstanding.
Also, why support for Mobility should be a goal of
any architectural change regarding scalability.
Hi Med,
In "Re: [rrg] Next pass" (msg06535) you wrote, in part:
> - The proposed solutions I read, imho, seem to not solve the scalability
> issue since the full table should be maintained in some nodes and this
> table is not reduced (in transit border routers for current BGP
> deployment, in TIB tables in TIDR proposal, APR for AIS, LISP/Ivip
> maintain separate database to store the mapping but still there is a
> impact on the global routing table in early deployment stages since IDs
> need to be routable at least to be reached from non LISP/Ivy sites,
> etc.).
I think you are assuming that for LISP and Ivip that each prefix (or
for Ivip, a "micronet", which need not be a prefix) of "edge" space
used by an End User Network (EUN) is separately advertised in the
DFZ. This is not the way Ivip will be used, and I doubt if LISP
would be used in this manner either.
The main way "edge" space will be provided in Ivip is for a company
to devote a DFZ advertised prefix to being used to serve the needs of
many (up to tens or hundreds of thousands) of separate EUNs. This
prefix is called a "Mapped Address Block" (MAB) and the company which
runs it is called a MAB Operating Company (MABOC). The MABOC leases
the space within the MAB to all these EUNs. Each EUN splits up its
space into as many separately mapped micronets as it likes.
So you could have a MAB of 44.44.0.0/16 with 2^16 IPv4 addresses.
This could be split into various User Address Blocks (UABs), each for
a different EUN. There might be 10,000 EUNs, some with just one or a
few IPv4 addresses and some with more. A single micronet in Ivip is
an integer number of IPv4 addresses or IPv6 /64s, with any starting
and ending point provided both are within the one MAB. So a micronet
could be:
44.44.55.67 (Single IP address.)
44.44.55.68 to 44.44.55.73 inclusive (6 IP addresses.)
The MABOC runs one or typically multiple DITRs - Default ITRs in the
DFZ. These advertise the MAB. So all DFZ routers need the MAB in
their RIB and FIB. This is entirely scalable, since the one MAB is
providing space for ten thousand EUNs, and some of those EUNs will be
further splitting their space into multiple micronets. A single DFZ
advertised prefix for all these separately mapped micronets of "edge"
space is highly scalable.
LISP could do the same thing - except LISP always works in prefixes.
Each separately mapped division of address space is an "EID prefix".
As far as I know, there is little documentation of LISP's technical
and administrative arrangements regarding address space usage. LISP
has no formal concept equivalent to Ivip's MAB, but Dino has used the
term "coarse prefix" to refer to much the same thing - which would be
advertised by some or perhaps all PTRs (Proxy Tunnel Routers - much
the same as Ivip's DITRs).
> - To what extent a loc/id solution can mitigate/solve the routing
> scalability issue?
Neither LISP or Ivip are Locator / Identifier Separation
architectures. RANGI, GLI-Split, ILNP and Name Based Sockets are.
For an account of how LISP or Ivip could solve the scalability
problem for both IPv4 and IPv6, and for why Ivip could do it better,
please see:
http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
Since then, IRON-RANGER has developed somewhat and I think it may be
more promising than LISP. This also includes a taxonomy of the
proposals and links to other messages where this is argued in greater
detail.
> - Why draft-narten is not acceptable as a starting point to sketch the
> problems to be solved? A frozen version of the problem statement is must
> for the group in order to help selecting solution(s).
The RRG Goals I-D was never properly developed. My message 06219 has
my account of the goals - but there seems to be no consensus on what
the goals should be.
> - Unlike the multi-homing case which is obvious, need to motivate why
> mobility is an issue for routing systems.
Because global mobility is similar to multihoming and portability in
some ways.
For an account of a new approach to global mobility, for IPv4 and
IPv6, without modifications to correspondent hosts and with generally
optimal paths, please see the TTR Mobility architecture:
http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf
This could work with both Ivip and LISP.
If we are going to do a major upgrade to the architecture of the
Internet, I and some other people think that it should support
Mobility - rather than doing an upgrade just for portability and
multihoming and then having to do something later for Mobility.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
