> From: avri <avri@sm.luth.se>
> The question then becomes whether we can get to such an inherently
> evolutionary architecture, something that would be radically
> different then the current architecture, by evolution.
In my view, no. I think I know what the answer is, and it demands such a
radical restructuring that there's no way to morph from one to the other.
> From a hypothetical point of view, I believe that if the
> evolutionary architecture is sufficiently so then it should be
> possible to absorb the current architecture into its evolutionary
> path and proceed from there.
To put it another way - and this relates to a previous requirements
document discussion - if the new architecture has enough flexibility in
it to allow particular local areas to "do their own thing", then it will
inherently have enough flexibility to allow a migration from the current
architecture.
The method is self-obvious - you treat the existing network as an area
which is doing its own thing.
> One of the first things though seems to be the requirement to delve
> deeper into what it means to be an inherently evolutionary routing
> architecture.
Much the same as is true of *any* inherently evolutionary systems
architecture. How you do that is going to sound a bit like mysticism, but
here goes anyway.
First, you have to really understand what the system is fundamentally
doing. Once you see that clearly, and properly provide that
functionality, you're a big part of the way home. Think about things like
stacks, and processes - we haven't fiddled much with them in a long time,
because we've figured out what the fundamentals are.
Second, you have to properly partition the system into independently
acsessible subsystems, to allow future uses/applications which you
haven't forseen to have the flexibility available to do their thing.
Third, where names are involved, you have to provide a naming system with
enough flexibility. Part of this is providing names with enough
flexibility (i.e the ability to handle as many names as you need - one
failing of IPv4). Another part is recognizing all the different classes
of fundamental objects in your architecture (and this is kind of related
to the first point), and providing separate namespaces for all that need
names (another failing of IPv4).
Noel
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT