Hi Bill,
I wasn't suggesting that the large number of end-users who want
multihoming etc. was the problem. I suggested the problem was a
mismatch between this number and the scaling limits the BGP based
routing system, which is the only current method of providing this.
That problem could be seen in at least two ways:
1 - That the current system's scaling limits are the problem.
Assumes: The routing system should be responsible for
providing multihoming, TE and portability.
Solution: Soup up or replace the routing system so it can
cope with the larger numbers. (Since we can't replace
the BGP system, and no-one thinks it could be souped up
to scale to hundreds of millions of prefixes, we have
the network-based core-edge separation schemes, primarily
based on map-encap: LISP, APT, TRRP and Ivip, although in
the long term, Ivip does not use encapsulation.)
2 - That current host functionality is deficient, since hosts
themselves are incapable of providing multihoming, TE and
portability.
Assumes: 1 - The routing system is not capable of, or should
not be required to, provide these things, at
least to such numbers of end-user networks.
2 - Hosts should be required to do this for
themselves.
Solution: Change Internet protocols, involving changes to
host stacks, APIs and applications so that hosts
can provide all this, without burdening the
existing BGP-based routing system.
Your current definition of the root cause of the routing scaling
problem: http://bill.herrin.us/network/rrgarchitectures.html (5th)
is entirely along the lines of 2 above. However the underlying
assumptions are not stated.
I disagree with the assumptions on which 2 is based. (I also think
it will be impossible to attract enough end-users to any such system
which involves application changes.)
I think the proper place to handle multihoming, TE and portability
for end-user networks is in the "routing system" - that is in the
DFZ, in ISP routing systems and in at least one of the routers in
end-user networks. (Not, as Noel discussed, in routers at the edge
of end-user networks.) I wrote about this in:
Fundamental objections to a host-based scalable routing solution
http://www.irtf.org/pipermail/rrg/2008-November/000271.html
Adopting the 2 assumptions and solution will burden all hosts with
extra complexity, greater reliance on fast and reliable
communications to and from each host etc. to provide these things.
Yet multihoming, TE and portability are all things which concern the
operators of end-user networks, and are not of any direct interest to
hosts at all.
Multihoming involves real-time response to network outages. This is
nothing to do with hosts and has traditionally been handled by the
routing system.
Inbound Traffic Engineering is also a network-based, real-time,
concern. The network operator wants to balance loads across multiple
links, handle some kinds of packets on one link or the other for
cost, QoS, or some other policy reasons. This has nothing to do with
hosts. Hosts can't easily determine what the total load of packets
is across any one link, or what other factors the network operators
consider important when choosing which packets should come in via
which links.
Portability of address space is the only way a network can change
ISPs without the excessive costs, disruption etc. of renumbering.
This is never going to change, since the addresses turn up in all
sorts of places, including in config files of hosts, routers etc.
well beyond the network itself.
These things are best controlled from a few levers directly operated
by the network administrator. I think the mechanisms should be in
the routing system too - and should not involve hosts at all.
Implementing the actual mechanisms in hosts would require the network
administrator to be sure that all hosts have the right mechanisms and
respond to the network administrator's desires. Yet it is
commonplace for hosts which are not owned by, or controlled by, the
end-user network operator to connect to these networks in an ad-hoc
manner, such as plugging in a laptop, or using a Wi-Fi link for a PC,
Wi-Fi phone etc.
A further problem is the complexity and extra packets which must flow
back and forth to hosts in order to do this work. This would be a
serious burden on any small device, significantly increasing the
complexity, costs, operating currents etc of the simplest possible
host.
Over a slow, expensive, unreliable, radio link the extra traffic
required for hosts to perform these functions would be a real
problem. The current unreliability of radio links impacts service
quality directly. In addition, if hosts had to do multihoming, TE
and portability within themselves, radio link delays and
unreliability for packets concerning these functions would further
degrade the final service quality.
I am completely opposed to host-based solutions to the routing
scaling problem. I think the current "root cause" problem assumes
the problem is in the hosts, and therefore implies that the solution
should lie there - despite the fact that some of the solutions are
network-based, rather than host-based.
I could write some new words for your page, but you would probably do
a better job of writing with the terseness I think you desire.
Regards
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
