On Thu, Nov 27, 2008 at 8:34 AM, Christian Vogt <[EMAIL PROTECTED]> wrote: > >> I saw it as: The pain we see is in the network, host solutions don't >> (as of yet) provide the control required for large-scale TE issues [...] > > Hi Chris - > > On the other hand, RRG does have several host-based multi-homing > solutions that enable the network to exercise traffic engineering: > Six/One gives the network explicit traffic engineering control through > address prefix rewrites in routers. Multi-path TCP gives the network an > implicit means for traffic engineering through bandwidth limits and > packet loss. And both Six/One and multi-path TCP can be used within the > framework of a hostname-oriented network protocol stack. >
sure > The only argument that can be brought up against host-based multi-homing > is that it becomes effective only if a considerable portion of all hosts > supports it. Even if networks can ensure that local hosts do support and if a considerable number of sessions would benefit from it. If a lot of the traffic is 30-50 (probably they are smaller than that actually) packet flows I'm not sure host-based makes a lot of sense with respect to the overhead associated with discovering paths, performing TE decisions, etc... Also, keep in mind that there may be some boundaries in administration to be aware of with respect to hosts and network traffic. (network admin people manage traffic, system-admin folks manage hosts, in someplaces this is a challenge) of course this is also dependent upon the implementation on the hosts, but so far the ones I've read will require some discovery and setup. > multi-homing, there is still a dependency on remote hosts supporting it > as well. However, the dependency on the remote side does exist also for > network-based multi-homing. Like host-based multi-homing, network-based > multi-homing does require support on both sides of a connection. > Consequently, host-based multi-homing is IMO deployment-wise just as > feasible as network-based multi-homing. And technically, host-based > multi-homing is IMO even preferable for two reasons: (a) It is > inherently more robust because it does not add new single points of > failure. (b) It is more reliable because only hosts can monitor the > availability of complete end-to-end paths. > > FWIW: The above considerations apply only to RRG's goal of enabling > multi-homing. They do NOT apply to RRG's second goal of eliminating fair enough. > renumbering. Eliminating renumbering entirely is possible only with a > network-based solution. And unlike enabling multi-homing, eliminating ok. > renumbering is achievable with only unilateral support: Six/One Router > Unilateral mode and NAT66 are example solutions. Since the first goal nat66 or nat(anything) is a little scary in that it implies (to me) the injection of lots of state into the 'network' (at least some points in the network) and thus introducing large amounts of complexity and troubleshooting complications. I agree something like NAT would let you avoid renumbering (and that's one of the uses today for NAT) but there is a cost for this. At the individual enterprise level that may be cost effective, at the ISP level I'm not sure it's cost effective. > can IMO best be solved in hosts, whereas the second goal is achievable > only with a network-based solution, I was suggesting the dual approach > consisting of a host-based solution plus a network-based solution. > Sure... my point really was that there seem to be equal reasons for each, and ratholing on just one seems counter productive in the long term. One strategy to permit the network to scale in the face of 'more addresses' or 'more networks' or 'more multihomers' is great. Another strategy to be used for smaller-scale multihoming like home-network-based multihoming (cell, wifi, broadband-cable) also seems like a good thing. -Chris _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
