Short version: We should reject Strategy B. (I think no-one
argues against rejecting C and above.)
It would make no sense to recommend the IETF
actively develop such a scheme, even if we
thought it was desirable to push responsibility
for multihoming etc. to hosts, since:
1 - There are no substantial Strategy B proposals
while there are several substantial Strategy A
proposals.
2 - All possible Strategy B solutions have much
steeper barriers to widespread adoption than
any Strategy A solution, since all Strategy
B solutions involve changes to host stacks
and applications (as well as most or all
networks abandoning IPv4 in favour of IPv6)
and because Strategy B solutions only provide
multihoming etc. when both hosts are upgraded.
Our task is to recommend one (or more than one?) architectural
solutions to the routing scaling problem, to be developed further by
the IETF.
I believe we should recommend one or more architectural solutions
which both:
1 - Show good promise of being able to solve the problem, if widely
adopted.
2 - Show good promise of being very widely adopted.
We need close to 100% adoption. 50% or 95% isn't good enough,
since those end-user networks which want multihoming and don't
adopt the solution will continue to use the PI and BGP approaches
to multihoming. We can't enforce a solution - it has to be
attractive to virtually all end-user networks which want
multihoming, TE and portability. This means end-user networks of
all types and sizes. These networks don't necessarily care about
routing scaling - so the solution must provide immediate,
substantial benefits over whatever costs, risks and disruption
the solution involves.
Strategy A solutions are all "core-edge separation schemes". Apart
from Six/One Router's inability to work with IPv4, they all have a
chance of meeting these two criteria - although opinions vary on
which proposal meets them both best.
I believe there is such a sharp distinction between the Strategy A
and Strategy B proposals that we should only seriously consider
Strategy A proposals for recommendation to the IETF.
How well could Strategies A and B resolve the only scaling problem we
currently have - IPv4's?
Most of the Strategy A proposals (LISP-NERD, LISP-ALT, APT, Ivip
and TRRP) are intended to work with IPv4.
Strategy B proposals cannot help with the IPv4 routing scaling
problem because there is not enough space for each multihomed
end-user network to be given a prefix by each of its two or more
ISPs.
How many reasonably well documented proposals are there?
Strategy A: Six: LISP-NERD, LISP-ALT, APT, Ivip, TRRP and Six/One
Router.
(However, I am not sure that Six/One Router is still
being actively developed. There have been no
updates since my critique in July 2008. The last
update to the LISP-NERD I-D was April 2008.
Six/One Router has no mapping system and TRRP
documentation is minimal.)
Strategy B: There are no properly documented proposals.
ILNP may be a Strategy B approach but it is not
properly documented as a scalable routing solution.
There is no Summary and Analysis in the RRG wiki.
HIP has been mentioned, but no-one seems to be
proposing it as a scalable routing solution.
Every possible Strategy B approach would be vastly harder to have
adopted by the majority of end-user networks which want multihoming,
TE and portability (or its functional equivalent) than any Strategy A
approach, for at least two reasons:
1 - Strategy B solutions require most or all current Internet users
to adopt IPv6 - and furthermore IPv6 with a modified host
stack, API and applications.
2 - Strategy B solutions provides benefits to adoptors only when
the other host in a session (stack and relevant applications)
has been upgraded too. So until almost all networks and their
hosts adopted it, the scheme could only provide multihoming for
a fraction of communication sessions.
Also, I argue that any approach which involves pushing
responsibilities and management traffic to all hosts (all potential
Strategy B approaches) is fundamentally flawed:
http://www.irtf.org/pipermail/rrg/2008-November/000233.html
I find it impossible to imagine how a Strategy B solution could
succeed if we fail to solve the problem via the best one or more
Strategy A solutions being properly developed and offered for adoption.
RRG rejection of Strategy B solutions is not to suggest that people
shouldn't work on such schemes. Just that we have no confidence that
any such scheme could turn out to be technically better and/or easier
to have widely adopted than a well developed version of the best of
the Strategy A schemes.
Of course, if the best efforts with Strategy A schemes fails, then
everything would be up for reconsideration. However, that is a
potential scenario in the post-2020 future. Then, any Strategy B
solution would still involve much higher barriers to development and
adoption than any Strategy A solution.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
