I like the picture painted below of synergistic, incremental, flexbile
deployment of improved behavior.
However, this two-ended incentive relates to one of the things that
concerns me about the current paths of this work.
On the one hand, we are looking at a variety of tunneling mechanisms
designed to relive the PI pressure on the core.
One of the other important goals of most of these proposals is that they
remove the difficulty of multihoming and changing providers (thus
providing an incentive for enterprise cooperation / deployment.)
Meanwhile, other sides of our house are looking at interesting ideas
such as TCP Multipath support. These techniques work most simply when
the tcp sender and receiver have visibility to the attachment addresses
of the site to the Internet, and the ability to select which one is used.
All of the network based tunneling techniques I can see seem to have the
property that in providing for multihoming and the ability to change
providers, they remove exactly the visibility that our other hand is
trying to utilize.
There seems to be a systemic disconnect.
Yours,
Joel
Shane Amante wrote:
Scott,
On Dec 7, 2009, at 11:06 MST, Scott Brim wrote:
Excerpts from Brian E Carpenter on Mon, Dec 07, 2009 09:30:45AM +1300:
I was thinking about commenting on this point too, but Christian
beat me to it.
We *can* propagate changes to the numerically significant host
operating systems. It takes years, so any solution based on this
must be one with a completely incremental deployment model. One
view of the IPv6 deployment problem is that it depends on *both*
incremental deployment to all hosts *and* centralised deployment
by operators. That's the worst case, but seems inevitable for
an actual change of the IP packet format.
So, I think that tells us that a solution that requires host stack
changes only, *or* infrastructure changes only, but not both,
is deployable.
Personally, I wouldn't expect something called "routing research
group" to propose a strategy based 100% on host changes and 0% on
changes to the routing system. But we could conceivably propose
something based on changes to both, and that would surely be
a big mistake.
Right. And best of all is to start at both ends and work toward
something good. Do something in endpoints that helps them accomplish
their goals without depending on the network. Do something in the
network that has the ability to help scale routing and addressing even
assuming hosts don't change, BUT is designed so that as the hosts DO
change that ability can be abandoned, and the whole system can become
more streamlined.
I *very* much agree with all of the above points! Specifically, it's critical that we
develop both types of solutions as different networks/domains are going to be vastly
different in terms budget, staff, priorities and size/scale. For example, those with
large size/scale may have a significant amount of 'legacy' equipment they have to
maintain "as is" (or it would take [much] longer to 'upgrade' it in some form),
therefore they're likely to start with a network-based solution. OTOH, those networks
that are green-field, planning/obligated to do host O/S upgrades and/or small(er)
networks may choose to start with a host-based solution.
An analogy from a security standpoint is that hopefully most administrators
realize that host-based firewall solutions are superior (particularly for
laptops, etc. that roam outside a corporate firewall)[1]; however, 'legacy
systems' may not [ever, or initially] support host-based firewall solutions,
therefore a network-based firewall is necessary to provide protection to them
...
The bottom-line is various networks (and, hosts in them) are continually
evolving *and* are evolving at different time-scales.
-shane
[1] This would be analogous to host-based ID/Loc split solutions, assuming they
provide adequate mobility.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
