Hi Robin,

I think multi-homing in edge networks MUST support legacy hosts.
Adding ISP uplinks to single-homed edge networks can be very beneficial.
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.

So I do not agree on:
> For this reason, I think it would be impossible to successfully
> introduce a host-based approach to multihoming

Teco.


> -----Oorspronkelijk bericht-----
> Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Robin
> Whittle
> Verzonden: maandag 24 november 2008 3:21
> Aan: RRG
> Onderwerp: Re: [rrg] RACHH: the host-based solution - prepping the PR
> team to sell it
> 
> Hi Brian,
> 
> You wrote:
> 
> > It's become fashionable to assert that host based solutions
> > are undeployable. I would like to recall that the model for
> > rolling out shim6 is very clear - in MS-talk it's called
> > "Updates are ready for your computer" - since *all* it requires
> > is an IP stack upgrade. There are absolutely no changes for upper
> > layers (except maybe a small tweak for SCTP code) and absolutely
> > no changes for routers or ISPs. Of course, it's true that shim6
> > is not much use until a critical mass of users have installed
> > that update, and it doesn't include TE features for ISPs.
> > But the deployment model is o(OS programmers) in terms of
> > significant cost.
> 
> This only works for that subset of devices for which the operating
> system is actively maintained and upgraded, for which the programmers
> invest in adding SHIM6, for which automatic updates are possible and
> for which the end-user of each device enables such automatic updates.
> 
> This rules out older desktop and server operating systems, printers,
> networking gear (Wi-Fi etc.), NAS boxes, probably lots of hand-held
> devices which only have expensive mobile links to the Net and are not
> so suitable for automatic OS updates etc.
> 
> I don't see how this is a viable method of achieving the critical
> mass required for multihoming based on SHIM6 to become useful.
> Multihoming 10%, 50% or probably anything less than 95% of traffic
> does not strike me as useful.  Multihoming is only of value when it
> works for essentially all traffic.
> 
> For this reason, I think it would be impossible to successfully
> introduce a host-based approach to multihoming - except perhaps over
> a period of 15 years or so.  There are so many devices which would
> never be upgraded that it would take years - maybe a decade or more -
> before they were thrown away and replaced by something modern with
> the new system built in, that the people who did install the system
> on all their hosts had 95% or more of their traffic properly
> multihomed with the new system.
> 
> Until that level is reached, there are only costs and risks in
> installing the new system.  There is no substantial benefit until
> 95%, 99% or whatever of the other hosts in the world have been
> upgraded too.
> 
> > It's clear that once you ask for action by application
> > programmers or non-routine action by end users, the costs
> > become unthinkable.
> 
> Yes.  That is why I think trying to introduce a host-based scalable
> routing solution is a non-starter.  SHIM6 is not regarded as a
> solution, and the only potentially viable host-based solutions
> require changes to applications too, so they all use a new
> hostname-based API.
> 
> I think that LISP, APT, Ivip, TRRP and Six/One Router are all based
> on the belief that a host-based solution is not the way to go.
> 
> There are other, more fundamental, problems with a host-based
> scalable routing solution   - even if there was no problem
> introducing it.  I will write more about these in another message.
> 
> 
>  - Robin
> _______________________________________________
> rrg mailing list
> [email protected]
> https://www.irtf.org/mailman/listinfo/rrg

_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg

Reply via email to