Re: scope of solution..

[Jim Bound <seamus@bit-net.com>]

sorry slip of ctrl key...

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

I don't think failure notification should be done with the way we may
learn it today thru routing topology alterations and we should not declare
hosts should have to support routing protocols. We could do it as I
suggested with a rtr-renumb like ND cascade from failure point to the
host.  Or another approach would be to use an anycast message to the site
router for the src packet.  But those are TBD and require drafts.

But the quick fix is as Greg suggested to move pairwise DNS dst addrs to
the retransmission code on a host.  Which is the quick fix.  This could be
done as out-of-band code as one example at the resolver when getnameinfo()
library execs and an ioctl could load the e2e-mullti6-cache (ignoring
port space et al for now) to set it up.  The app would just keep on
ticking.

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

No. The packet would be sent out the correct path with the Ohta-san,
Odell-san, or a hybrid compromise models.  But I do think we need to
notify the app via async interrupt even with non-block send or recv op and
getpeer() should then return the address if the 'who' has changed which it
may not.

Also this is for IPv6 apps not IPv4 necessarily.  We have time to educate
ISVs and pub domain shareware. 

> How does DNS work in such a scenario?

DNS works now in all trials I have seen.  DNS Dyn Updates is built into
many IPv6 implementations as part of addrconf.  Dyn Update within an IPv6
site I don't see as performance problem at all.
 
> How does the network decide where (and whom) to send the failure
> notifications?

It could be based on the src address who or from the path whence it came
to find where.
 
> 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.

I think that is prudent but whats the scalable solution you propose to
make things better with IPv6.  When IPv6 mobile nodes and Internet
appliances start sending packets on the Internet I predict the traffic
will quadrupel instanteously at that pervasive market penetration point.
We need to be ready for that.

/jim