Joel, On Dec 7, 2009, at 13:11 MST, Joel M. Halpern wrote: > 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.
Valid point. However, in various places in the IETF the above problem has been addressed by "Applicability Statements" and/or "Applicability Documents" that should articulate when certain mechanisms can be used together (or not). For example, MP-TCP may advise that it should only be used in the context of host-based multi-homing solutions, since MP-TCP doesn't benefit from network-based multi-homing solutions. -shane > > 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 >> [email protected] >> http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
