Re: scope of solution..

[Bora Akyol <akyol@pluris.com>]

I was aware of both of these arguments.

The routers today are not nearly as close to exploding due to prefix/path
bloat as the trade rags will have you believe.

By shifting the load of multi-homing to hosts rather that the routers and
the network, we are essentially shifting the most of the load to the
hosts. One can argue that this is a more scalable approach (I can already
ifconfig more than one IP address on my box on one interface). But I
cringe when I hear of "failure" notifications sent around the network all
the way to the hosts so that they can switch the IP addresses that they
use or auto-configure themselves with a new address.

What about services such as sendmail, http, ircd etc that depend on the IP
address (and reverse resolution). Does it mean that I have to restart my
servers everytime the IP address gets reconfigured.

How does DNS work in such a scenario?

How does the network decide where (and whom) to send the failure
notifications?

Coming back to my initial statement, I have seen routers handle upwards of
500,000 prefixes with rich PATH attributes already, and as
implementations get more efficient (and distributed) I believe BGP can be
made to scale (depending on the router hw that you choose to buy).

Hence, the WG should consider both sides of the story.

Bora


On Wed, 11 Apr 2001, Daniel Senie wrote:

> Bora Akyol wrote:
> >
> > Why is it a good idea to involve the hosts in a site as part of the
> > multi-homing solution?
> >
>
> If you've got two blocks of addresses, from two separate upstreams, and
> one link croaks, you'd either need the hosts (end stations) to be able
> to change which source address they're using, or you have to do
> multi-homing the way we presently do on IPv4 (and on IPv6 presently),
> that being to have the multi-homing done by announcing address space
> into the core.
>
> > If this WG decides to involve the hosts as part of the multi-homing for
> > IPv6, to what extent will they be involved.
> >
> > My own inclination is to support multi-homing at the router level and do
> > not require anything other than a basic default route for most hosts.
>
> The issue is that argument ties to either the present style of
> multihoming, or a requirement to use NAT in the router to make things
> continue to work in the event of an outage. Since the NAT case is
> guaranteed to blow up many applications, that's not real practical. The
> general claim is that our present method of multihoming isn't scaling.
> This leads to the question of doing something at the host level. It's
> essentially moving what's presently done in some NAT-box-multihoming
> products into the host.
>
> >
> > Bora
> >
> > On Wed, 11 Apr 2001, Bill Sommerfeld wrote:
> >
> > > one of Margaret Wasserman's notes talked about the solution coming
> > > from either "the routing system" or "the hosts".
> > >
> > > Since we're talking about *site* multihoming, there are (at least)
> > > three scopes here:
> > >
> > >  - the routing systems of the ISP's outside the site
> > >
> > >  - the routing system within the site
> > >
> > >  - the hosts within the site.
> > >
> > > A scalable multihoming solution could involve some form of
> > > coordination between the site's routers and the site's hosts..
> > >
> > >
>
>
> --
> -----------------------------------------------------------------
> Daniel Senie                                        dts@senie.com
> Amaranth Networks Inc.                    http://www.amaranth.com
>