Short version: Some people are uncomfortable about the
constraints perhaps precluding any proposal from
being viable. Can anyone suggest why this
statement of the constraints is incorrect?
I think at least two proposals meet the constraints.
Hello Dae,
Thanks for your message, in which you wrote:
> I do share your good intention with this list of constraints.
>
> But, again, I have some worry that perhaps this list will be falsely
> used to effectively reject most of proposals. Too many ideal assumption,
> perhaps with this list of constraints.
OK - which of the constraints listed at:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
do you think are not realistic, bearing in mind the recent messages
about 8, 9 and 10 not being absolute?
This text is meant to reflect reality. It is not my "ideal" list of
constraints - ideally there would be no such constraints.
I am happy to modify or annotate the list if you can think of
corrections or some circumstances in which a constraint would not apply.
If these constraints are real, then proposals which don't meet all
the absolute constraints should be rejected - or put on the
back-burner for some future scenario in which the constraints no
longer apply.
If all the proposals fail to meet the constraints, then we are in
trouble. We only need one proposal which meets them, but ideally
there should be a few to consider. Meeting these constraints
regarding voluntary adoption doesn't indicate anything about the
other merits of the proposals.
I believe APT and my own proposal Ivip fully meet these constraints.
I think LISP-NERD could meet them, but it doesn't scale well. It
would always be better to use local full database query servers, as
does APT and Ivip.
LISP-CONS, LISP-ALT and TRRP can't fully meet the 9th constraint -
that of not degrading security, robustness or performance. This is
because they use a distributed global query server system which means
that ITRs must often wait significant times - such as a fraction of a
second to a second or two - before they can send the first packets in
a new communication session. This means dropped packets and slower
starts to many sessions. Also, if the map query packet or its reply
are lost in their potentially very long paths across the globe, then
it may take the ITR two to four seconds to resend the query and
receive a mapping reply.
> Our patient is dying, in any moment. There's no way of saving him by
> surgery without causing pain, real severe pain. He won't voluntarily
> accept the pain.
In which case the patient will die, or reach a point where the
surgery looks like the less painful option.
But I think the patient is not going to die any time soon. The
number of routes in the IPv4 DFZ is growing inexorably, but not rapidly:
http://bgp.potaroo.net
The doubling time is about five years.
Meanwhile, many smaller networks which want and need multihoming,
portability and inbound TE are not able to get it. So the situation
is bad, but the Internet still works. The cost of the growing number
of DFZ routes burdens all ISPs and multihomed end-user networks. It
also makes it somewhat harder for new ISPs to be established by
pushing up the price of the multihomed DFZ routers which every ISP
needs. The growing number of routes in the DFZ also contributes
somewhat to difficulties with the DFZ routers being slower in
converging on a new set of paths in the event of an outage.
The Internet and its interdomain routing system is a growing system,
with plenty of money flowing into it. Lack of scalable routing won't
kill it - it just adds to costs, reduces the ability of end-user
networks to have multihoming etc. and makes it harder to establish
new ISPs (which reduces competition between ISPs).
The surgery doesn't necessarily involve pain. If APT, Ivip and
perhaps some yet-to-be developed proposals meet these constraints,
then there isn't any "pain" to rule out widespread voluntary adoption.
A successful proposal has to be highly attractive. One way of making
them attractive and generate revenue is to use them as part of a new
approach to mobility. Any of these core-edge separation schemes
(LISP-NERD/CONS/ALT, APT, Ivip or TRRP) could be used for a new kind
of mobility, for IPv4 or IPv6, using the TTR (Translating Tunnel
Router) approach:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
I think this is so attractive, that you could sell this service,
complete with a system like APT or Ivip, irrespective of whether
there were IETF RFCs for the systems, and irrespective of whether you
wanted to solve the routing scaling problem. The mobile node gets
its own IP address (or prefix in IPv6) and can use it on any care-of
address, including behind one or more layers of NAT and including the
use of traditional MIP techniques. Path lengths are generally
optimal or nearly so, and the mobile hosts communicate fine with
ordinary hosts.
I would be worried if all of the proposals failed to meet what appear
to be the real constraints imposed by voluntary adoption. However,
since I believe that two meet them well, then I am optimistic about
the problem being solved.
Judging by the slow progress since the RAWS workshop in October 2006,
I think it may take another 5 or 10 years. I think it needs to be
done in a way that facilitates maximal usage of IPv4 address space -
since we are all dependent on IPv4 and I don't see this changing in
the foreseeable future. There's no tearing hurry about the IPv6
routing scaling problem, but hopefully something similar to the IPv4
solution will work well for IPv6 too.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
