Eliot Lear wrote:
I am not mandating any such thing. I am saying that you are architecting toward a solution that is best solved elsewhere. AND what we have works without such constructs - with two notable exceptions:
We do need to handle the disconnected and intermittenly connected network carefully and in a reasonable way. Here I don't think we have good answers -- YET. I do not wish to sweep this one under the rug.
In the interest of not seeing this swept under the rug as you say, let's discuss
the disconnected/intermittently-connected network case. We require stable
addressing for apps within such networks independent of what may be going
on with the provider point(s) of attachment. This seems to rule out provider-
assigned prefixes, since these are not portable and expire after extended
periods of disconnected operation. (Do you have a differing opinion on this?)
It seems to me that if the world were perfect, each "site" could procure its
own global prefixes independent of any provider and arrange to have the them
advertised into the global backbone by their current provider; even if they skip
around to different provider points of attachment from time to time. But, we
all know that this would lead to an immediate scaling issue for the global routing
table. If someone knows that a solution for scalable global routing in a flat address
space is close at hand, I wish they would speak up so that we could all get on with
the business of deploying it! Failing such, we seem to have limited range addressing
and "graceful" renumbering as alternative options. Perhaps there are others also?
And then there is the case of renumbering and managing networks through renumbers. That's where Fred's stuff comes in.
Yes, but if you read the draft, the renumbering procedures Fred (Baker) describes
are anything *but* "graceful". I shudder at the prospect of "finding all the places"
(where addresses to be renumbered lurk) in anything but the simplest of networks.
I'd sure like to hear Fred's perspective on this, however.
Fred [EMAIL PROTECTED]
Eliot
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
