>-----Original Message----- >From: Teco Boot [mailto:[EMAIL PROTECTED] >Sent: Monday, November 24, 2008 7:40 AM >To: 'Robin Whittle'; 'RRG' >Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team tosell it > >Hi Robin, > > >> > Adding ISP uplinks to single-homed edge networks can be very >> beneficial. >> >> But it requires some kind of scheme to make them useful. Currently, >> the only way to multihome like this is to get PI space and advertise >> it into the DFZ through one ISP or the other. As more and more >> end-user networks do this, so we have the routing scaling problem. > >Multi-homing with PA is possible. See RFC3704 section 4 on suggested >solutions. My BRDP Based Routing proposal is an enhancement, it eliminates >careful planning and configuration and the need for tunnels. > > >> > Taking an existing ISP uplink out of service would need more >> attention, but >> > don't say this is impossible or not cost-effective. Let's say: it >> depends. >> > More important: it can be decided site by site. >> >> I haven't been able to understand this clearly, or why you think it a >> host-based routing scaling solution could pass either set of >> critiques I (and others) have made: >> >> 1 - It would be impossible to deploy it widely enough (in any >> reasonable time frame) that there were such a proportion of >> all hosts (such as 95%, 99% or whatever) that the resulting >> multihoming would actually be useful to anyone who deployed it - >> this is because a host-based solution only works when both >> hosts are upgraded. This is especially so if the scheme involves >> rewriting applications, as well as host stacks. >> >> As Brian Carpenter wrote recently: >> >> It's clear that once you ask for action by application >> programmers or non-routine action by end users, the costs >> become unthinkable. >> >> >> 2 - As I wrote here: >> >> Fundamental objections to a host-based scalable routing solution >> http://www.irtf.org/pipermail/rrg/2008-November/000233.html >> >> It would be undesirable to push this functionality out to hosts, >> compared to handling it with some new architectural structures >> in the network (that is, the routing and addressing system in >> the core of the Net and in ISP and end-user networks). > >I prefer a step-by-step approach. > >The first step would upgrade edge networks for multi-homing, this enables >multi-homing for hosts that can make use of it. > >In a second step, hosts are updated. It depends on the gain for users how >fast a transition takes place. Keep in mind that many end-user hosts use >dynamic addresses already (single address, IPv4, lots of NAT). Day-to-day >renumbering is no problem at all. > >Upgrading server farms requires special attention. I would not say servers >MUST have static unique addresses, there are examples of hosted servers >based on DNS names. For those, multi-homing is not that difficult to >implement. > > >I think the subject line has some negative judgment. And I would call it the >edge-based solution. >Keep in mind that I do not prefer edge-based over core-based. I think they >are orthogonal.
Where I run into difficulties is when "edge-based" solutions are extended all the way into the core such that end sites are locked into a provider-aggregated "matrix". Proper balance therefore depends on careful determination of where does "the edge" end and "the core" begin... Fred [EMAIL PROTECTED] > >Teco. > > > >_______________________________________________ >rrg mailing list >[email protected] >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
