Hi Teco, In: Re: RACHH: the host-based solution .... http://www.irtf.org/pipermail/rrg/2008-November/000239.html
you wrote: > Multi-homing with PA is possible. See RFC3704 section 4 on > suggested solutions. A quick look at this left me with the impression that this does not specify a usable form of multihoming with PA prefixes. My understanding of the purpose of multihoming is that the end-user network's hosts can continue their current sessions through one or the other ISP's links, without disruption, as one link is selected by some mechanism due to an outage in the other. > My BRDP Based Routing proposal is an enhancement, it eliminates > careful planning and configuration and the need for tunnels. OK - I see this I-D, new a week ago: http://tools.ietf.org/html/draft-boot-brdp-based-routing-00 which depends on: http://tools.ietf.org/html/draft-boot-autoconf-brdp-01 I understand it is for IPv6 only at this stage. I still don't see how this form of multihoming enables sessions to survive an outage of the ISP currently in use. If you think BRDP is in any way relevant to scalable routing, perhaps you could write up a summary for it on the list. >> 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. However, with the possible exception of SHIM6, there are no such hosts. There seems to be no broad support for SHIM6 as a solution for multihoming, or as part of the scalable routing solution. I was referred to this message in a 2006 discussion, by a list member, as an example of "Several prominent network engineers at major SPs trying to tell the shim6 creators that it was unacceptable." http://www.ops.ietf.org/lists/shim6/msg01139.html but I haven't had a chance to read it yet. What is the incentive for anyone to upgrade their edge networks, if there are no hosts which can multihome with the upgrades? I assume that the correspondent host would also need the host upgrade too - so for a very long time, there would still be lots of traffic which could not be multihomed. I think that having a multihoming solution which does not work with 100% of traffic, or very close to 100% (like 99%) is of little value to anyone. I guess your upgrades to the network would involve upgrades to routers, more management etc. as well as the major expense of connecting to a second ISP. > In a second step, hosts are updated. Yes, but to what? > 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 don't see how you can implement multihoming for anything, with session continuity in the event of an outage, with PA addresses unless all hosts involved in the communication have some stack and probably application changes, such as I criticised here: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000233.html > I think the subject line has some negative judgment. Yes - but RACHH (Routing and Addressing Changes Handled in Hosts) is quite descriptive of the host-based scalable routing solutions I am criticising. > And I would call it the edge-based solution. "Edge-based" could mean actions in end-user networks (routers) or in the hosts themselves, or both. I was discussing only solutions which required new responsibilities for hosts to handle things which happen in the network (outages, TE, new ISP etc.), especially if applications needed to be rewritten. > Keep in mind that I do not prefer edge-based over core-based. I > think they are orthogonal. OK - but I would prefer a situation which solved the entire routing scaling problem in one place, such as the routing and addressing system, rather than requiring new functionality, new architecture etc. in both the network and all the hosts. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
