Short version: - Reply to Robin's question - BRDP Based Routing doesn't brake anything and works with all IGPs. - There is more than Shim6 - BRDP Based Routing IPv4 support is on its way - There could be a need for host renumbering
> -----Oorspronkelijk bericht----- > Van: Robin Whittle [mailto:[EMAIL PROTECTED] > Verzonden: dinsdag 25 november 2008 5:12 > Aan: RRG > CC: Teco Boot > Onderwerp: Teco's BRDP proposal and SHIM6 > > 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. [Teco:] That depends what you think what is usable. > 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. [Teco:] Session continuity is provided with MIP6 and HIP (and maybe others) and this works fine with BRDP Based Routing. Moreover, BRDP provides hints to the MIP6 stack for SA selection. Expect BRDP Based SA selection I-D before next IETF. As far as I know, there is no secure, scalable and management-free solution for multi-homed networks. Translation on the border router is something of interested, but this has some well-known disadvantages. > > 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. [Teco:] On BRDP, Autoconf (SLAAC) for IPv4 is not in scope. IPv4 address configuration using DHCP for connected MANETs is in scope. Using short lease times, address switching caused by failing ISP unlink helps fast recovery. Some MIP stacks has hooks in WiFi driver for triggered handover. This is a subject for improvement (MIPSHOP). BRDP Based Routing for IPv4 is straightforward, I just add the IPv4 prefix in the BRIO. There are reserved fields left, so no overhead. Next versions will include IPv4 support. Again, session continuity is MIP6 and HIP (and maybe others). In many access network use cases, session continuity is not that important because short lived connections are used or session reestablishment is handled by higher layers (or user...). Personally, I switch IP addresses once a day (at least!). > If you think BRDP is in any way relevant to scalable routing, perhaps > you could write up a summary for it on the list. [Teco:] I included a _marketing_ sheet in the v6ops presentation: - Built on well known protocols such as IPv6 Neighbor Discovery And Policy Based Routing - Works with all IGPs - Full support for multi-homing with Provider Independent (PI) And Provider Aggregatable (PA) addresses - Helps scaling the Internet by removing need for PI addresses - Border Router load balancing - Automatic ingress filter on first hop routers - No tunnels, routing headers or any other encapsulation - Extensible for ad hoc networking The second marketing sheet is more important: - List of incompatible protocols: <empty> If someone comes up with a currently being used protocol that is broken by BRDP Based Routing, I really want to know. I'll add it in the applicability statements. Same for IGPs, I am not aware that BRDP Based Routing doesn't work with any of the IP routing protocols used today. I'll set up a wiki / Q&A or something else to better describe the BRDP protocol and related topics. Current URL: http://www.inf-net.nl/brdp.html > >> 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. [Teco:] Fault. We have MIP6 and HIP. And session recovery at higher layers. > 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? [Teco:] 1) add additional capacity 2) reduce dependency (ISP uplink fail: part of hosts survive) 3) migration to multi-homed hosts (also by adding load balancers) 4) single uplinks at different sites, sites are interconnected 5) ad hoc networks / hasty formed networks, where zero or more uplinks are available 6) multiple access providers, e.g. dsl and wimax and wifi (is related to ad hoc networks) > 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. [Teco:] Not the case with MIP6. Also not the case if short lived connections are used. > 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. [Teco:] Agreed on that no traffic may have hindrance of multi-homing. It depends on the benefits of multi-homing. Think of a smooth transition of single homed network (single ISP), with PA addresses. I this case, not a single host is required to support multi-homing, but there can be a business case for the smooth transition. > 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. [Teco:] If someone finds out multi-homing is not cost effective, (s)he is not interested in this kind of technology. But it seems to be that there is a need for PI addresses. I would not say that multi-homing with PA addresses takes away all the needs for PI, but I expect a reduction. > > In a second step, hosts are updated. > > Yes, but to what? There are multiple solutions for upper layer transparency (MIP6/HIP/Shim6). Personally, I think updates of applications provide the real benefits. I use the Skype in the notification area for checking my Internet connectivity:-) Bittorent is another example. I have to check SIP (to mention an IETF upper layer protocol). > > 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 > [Teco:] Yes, a long list of objections. It is easy to compose a long list of objections for the routing based approach (Tony posted this already). Remember I do not prefer one of the other. But please understand there are some good points on the host based approach! > > 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. [Teco:] I think the routing architecture should describe the whole infrastructure and not just the core network. The Internet model is a model of cooperation. Host do their job, so is the core. For example, my BRDP Based Routing improves routing in edge networks only. There are benefits for the hosts and for the core. Hosts may use multi-homing. Load on the core by unneeded PI addresses may be reduced. > > 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. [Teco:] Maybe you forget something. There could be hard requirements for host renumbering, e.g. for privacy or address hijacking. And I am not sure on security considerations on total loc/id split. There are some postings on this subject. Teco. > - Robin > > > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
