Short version: Why I think NERD should be remembered - it is at
one extreme of the spectrum regarding how many
individual devices should get the full mapping
database.
CONS, ALT and TRRP are at the other end.
APT and Ivip are in the middle and I believe these
are the only two of the current proposals which
could practically solve the routing scaling problem.
CONS, ALT and TRRP can't solve it because their
initial packet delay problems means that almost
no-one would voluntarily adopt them. Yet we
need widespread and later almost ubiquitous
voluntary adoption to solve the routing scaling
problem.
NERD could solve the routing scaling problem,
but it would always be better to make the ITRs
cache and to get their mapping from a smaller
number of local query servers - which is how
APT and Ivip work.
Hi Eliot,
You wrote:
> I like NERD. I like it because it is simple and it has nice security
> properties. I wrote it because I don't like the idea of routers
> dropping packets. Call me old fashioned.
Yes, considering some of the discussions on this list and on the LISP
list about how end users won't really mind some initial packets being
dropped or delayed for some time (fractions of a second to seconds),
you may seem to be old fashioned. Me too.
While I think NERD's most distinctive architectural choice - to have
every ITR know all the mapping - can never be as desirable as having
ITRs able to reliably and quickly get mapping from a smaller number
of query servers, I think NERD is an important architecture since it
anchors one extreme of the architectural spectrum.
We have never needed to discuss some hypothetical scheme in which
every ITR has all the mapping - which avoids most of the problems
inherent in LISP-CONS, LISP-ALT, APT, Ivip and any other core-edge
separation scheme. We simply referred to NERD.
On one end, NERD solves the mapping distribution problem by the
brute-force technique of distributing mapping to every ITR.
On the other end are schemes which say, in effect: "There are going
to be such a vast number of mappings that we couldn't possible expect
any single device to store them all - so we must have all ITRs rely
on a global, distributed, system of query servers for mapping."
Instances of such schemes are LISP-CONS, LISP-ALT and TRRP.
To me, these approaches are even more unrealistic than NERD.
Assuming 10 billion people, each with a mobile device which has a
slice of the address space which needs its own own mapping, it is NOT
absolutely impractical for a scheme to require every ITR to have the
full mapping information. That sort of mapping fits on a consumer
hard-drive and, by the time such large amounts of mapping information
are required, it won't be unthinkable to transport the mapping
updates around the Net to all ITRs.
NERD involves the total mapping database being sent to multiple
instances of individual devices - however many ITRs as are needed.
At the other end of the spectrum, CONS, ALT and TRRP are based on
what I think is a less reasonable extreme assumption than NERD: that
the amount of mapping information is so vast that we can't (or for
some other reason shouldn't) have the whole lot stored in any one
device.
No-one has ever shown why this is the case.
Due to this assumption, these proposals involve heroics constructing
a global distributed query server system, which condemns the users of
such schemes to suffering dropped or delayed initial packets. These
heroics might be acceptable if there was no other way, but the
dropped/delayed packet problem makes it impossible for such a scheme
to be voluntarily adopted sufficiently widely in order to solve the
routing scaling problem.
So CONS, ALT and TRRP anchor the other end of the spectrum in three
actual proposals.
Between these two extremes:
NERD:
Full mapping to ALL of a large number of individual devices
(ITRs).
CONS, ALT, TRRP:
Full mapping to NONE - not a single individual device in the
world.
we have:
APT and Ivip:
Full mapping to SOME individual devices - a bunch of query
servers which are located so all ITRs can access one or more
such servers quickly, cheaply and reliably enough that they
never need to drop a packet or delay one for a time which
would significantly effect end-users.
I think APT would be an adequate solution to the routing scaling
problem. Ivip is intended to improve on this significantly.
NERD's failing is that it burdens all ITRs with a significant task of
storage and of having to be sent the full stream of mapping data.
This is not unthinkable - its merely sub-optimal since APT and Ivip
can also achieve the goal of no lost or significantly delayed
packets. NERD is architecturally much simpler than APT or Ivip,
which is good. However, NERD's requirement for ITRs means that they
all have to be big devices, with low-cost, high-volume, connections
to the rest of the NET. This means NERD's ITRs would be expensive
and few in number, compared to the other schemes - so they would have
to be high-volume routers. It also precludes putting the ITR
function in sending hosts. APT's and Ivip's ITRs can be much lighter
weight, since they are caching ITRs and so could be implemented in
software on a server, or (at least with Ivip) in some sending hosts.
I think NERD's choice of how many devices receive and store the full
mapping database this is a minor failing to the assumptions which
gives rise to CONS, ALT and TRRP:
1 - That the routing scaling problem can be solved by voluntary
adoption of a method of packet delivery which, from a user
perspective, really sucks in some respect.
2 - Thinking that the the heroics of a global query server system
must be implemented because the mapping information is so vast
that no single device can handle it.
> But it is still woefully incomplete.
All the proposals are woefully incomplete.
TRRP is just a bunch of web-pages. However it anchors the CONS-ALT
end of the architectural spectrum in a conceptually simple DNS-like
global query scheme, rather than attempting to create a whole new
system, as does CONS and ALT.
CONS is on the back-burner and ALT is woefully incomplete, despite
the existence of test implementations, because the architectural
principles keep changing (more and more complexity in the protocols,
introduction of Map Servers, Map Resolvers and a completely
unworkable approach to mobility - in which each MN is its own ETR,
which can't work behind NAT or respond rapidly enough to new MN
care-of addresses) and because no solution is in sight to problems
such as:
1 - Excessively long paths up and down the ALT hierarchy.
2 - How to structure the ALT network to minimise this, while at
the same time achieving robustness against failure of ALT
nodes and minimising the number of connections which are
required between ALT nodes.
3 - How to get widespread voluntary adoption when the system
drops or unreasonably delays initial packets.
4 - So far, a complete lack of business models for building
and running the ALT system and the PTR (Proxy Tunnel
Router - like Ivip's OITRDs) system.
APT and Ivip are incomplete too. Its early days yet.
> To give you an idea of how incomplete here are just three
> problems that one would need to address:
>
> * Multicast. I don't think I use the word once in the last draft.
That's just fine. Multicast is not supported today in the
interdomain routing system, so it is not required in any elaboration
to that system. The only class of architecture which is suitable for
voluntary adoption is the core-edge separation approach and NERD,
APT, Ivip, TRRP, CONS and ALT are all proposals of this class. All
core-edge separation schemes are add-on enhancements to the existing
BGP-based interdomain routing system.
Multicast for direct support of end-user protocols would make no
sense unless there was QoS for these typically voluminous data
streams, and we are a long way off devising a system for the
real-time QoS arrangements in the global Internet. The stumbling
block seems to be that a single request for QoS can only be acceded
to by reserving capacity in a potentially large number of networks
around the world. This can only be done if the requester, directly
or indirectly, pays these networks for each such reservation of
capacity. I can imagine such a system, but it would be a lot of work.
Also, how would such a QoS system (for unicast and/or multicast)
maintain its guaranteed bandwidth when, for various reasons, the path
the packets take changes? I have no idea how this can be assured -
yet without this, the QoS reservation would not be robust enough for
many applications.
APT, Ivip and as far as I know, TRRP don't attempt to support
multicast. I understand ALT and perhaps CONS are supposed to support
it, but I have never been able to understand how or why.
> * Mobility. While I explicitly disavow any interest in mobility,
> somewhere in the Grand Scheme of Things, I don't think we can
> ignore it.
Mobility is definitely something we should do, or allow for, in a
scalable routing solution.
The most obvious approach - making the MN be its own ITR - can't
work, since many MNs will be behind NAT and their care-of addresses
change too rapidly for any mapping system to respond in sufficient
time to provide "continual" service. People want continual service -
at least for VoIP - so "continual" means loss of service for no more
than a few tens of milliseconds.
However, if you put the ETR function near the MN, and have the MN
create a two-way tunnel from itself to one or more of these new ETR
functions, then you can make any of the core-edge separation schemes
support mobility, with no extra architectural elaboration in the
scheme itself. This is global mobility for a particular IP address
or prefix, IPv4 or IPv6, even when the MN is behind one or more
layers of NAT and/or is using some conventional mobile IP techniques.
All the details are here:
TTR Mobility Extensions for Core-Edge Separation Solutions to the
Internet's Routing Scaling Problem
Robin Whittle, Steven Russert 2008-08-25
http://www.firstpr.com.au/ip/ivip/#mobile
This is perfectly applicable to NERD or the other core-edge
separation schemes.
> * No work whatsoever has been done (at least by me) to map NERD to
> LISP-MS.
NERD involves a completely opposite, and equally extreme, answer to
the question: "How many individual devices must receive and store the
entire mapping database?" as the CONS, ALT or TRRP answer.
LISP-MS (Map Servers) assumes ALT. I don't think ALT can ever be
made to work well enough for widespread voluntary adoption. While I
think NERD could be, it will always be preferable to use APT or Ivip
compared to NERD, because in these schemes, ITRs can be simpler,
cheaper, more numerous and closer to the sending hosts - including
potentially integrated into the sending hosts for no extra hardware cost.
So I don't see the need to develop NERD, CONS, ALT or TRRP for actual
deployment - nor trying to combine NERD with aspects of ALT, except
as a thought experiment.
> I think it's useful to have an alternative mapping system for LISP out
> there so that people can see that the architecture is indeed modular.
In broad principle the different strands of LISP may be considered
modular. You have an ITR concept, an ETR concept and then various
mapping distribution systems: first NERD, then CONS and then ALT.
But in reality, when you get down to actually designing ITRs and
ETRs, you need to make major decisions about them, and about their
protocols, depending on which of these mapping systems are used. So
I don't consider these alternatives to be modular in any practical
sense.
> I think there IS value in keeping a record of NERD, just to prove that the
> modularity remains.
I think NERD is notable for its simplicity and directness. The most
obvious improvement to make to NERD would be to make some or all of
the ITRs caching ITRs, with access to nearby query servers which do
contain the full mapping database. The result would resembles APT.
Then, to improve APT, you could do real-time mapping updates to the
query servers. This has major advantages including the ability to
handle multihoming service restoration and mobility TTR changes in
real-time. This means ITRs don't need to make any decisions and
don't need multiple alternative ETR addresses. This reduces the
volume and complexity of the mapping information itself. The result
would be something like Ivip.
> Finally, the question before this group has a limited lifetime. Given
> the questions that NERD leaves left open, I wonder whether it is wise to
> spend a whole lot of time debating the use of NERD *at this time*.
> Again, others can pick up the work later, and I am happy to assist with
> whatever limited insights I might add.
For the reasons stated above, I think that of the current proposals,
only APT or Ivip are worth developing seriously. APT would be the
choice if you were certain that real-time mapping distribution is
impossible or for some reason undesirable.
NERD could solve it, but it would always be better to use local
full-database query servers, as does APT and Ivip.
CONS, ALT and TRRP will never be adopted because of their initial
packet drop/delay problem, at least.
All the other proposals won't be widely adopted because they involve
end-users adopting new protocols and/or addressing schemes and
therefore operating system and application software on end-user
hosts. This includes Six/One Router. The only routing scaling
problem we have today is in IPv4 and there's nothing in Six/One
Router, or in any other proposal, including the whole of IPv6, which
makes me think most end-users are going to stop relying on IPv4 in
the foreseeable future.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
