[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scope of solution..



Bora Akyol wrote:
> 
> 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.

See below. I didn't say I believed we were there. I did say that's the
argument. It may be based on questionable assumptions.

> 
> 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?

These are all excellent questions, and are the same ones in many
peoples' minds. Changing to this model involves a significant and
fundamental shift. It may be the right thing to do, or it may not.
That's less clear. The complexity of it should not be underestimated,
nor its impact on application designers. Given all the effort required,
I expect this solution would result in something closer to universal
implementation of NAT/NAPT, since it's the path of least resistance.

> 
> 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).

Agree there's lots of headroom if people build products to go there. The
usual pushback is from network operators who are concerned that their
PRESENT equipment can't handle the strain. But they do replace the gear
with faster units, with more memory available, and so forth. As with the
address space crunch, we have at least to some extent created a
political/policy reason why we're having a crisis rather than allowing
the marketplace to progress unimpeded.

> 
> 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
> >


-- 
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com