Re: Evolution and the routing architecture

From: Kastenholz, Frank (FKastenholz@unispherenetworks.com)
Date: Mon Apr 08 2002 - 08:47:20 EDT


One can look at evolution/revolution in a couple of different
ways
1. How the new architecture changes over time. That is, can the
   new routing architecture change and adapt to changes in the
   environment. As the Internet changes, so too must the routing
   and addressing architecture.

   My, perhaps erroneous, view is that this is generally accepted
   as being a fundamental requirement.

2. How we get from the current architecture to the new one. That is,
   what is the transition model. I think that everyone agrees that
   flag days are Bad Things and we can not have one.

   That said, there are at least two ways to change the network
   over. One is to make a series of small, incremental, changes to
   the current architecture over a period of N years. So, after N
   years, we look at the net and say "Gee, it's running the new
   architecture". A second approach is a roll-out deployment
   approach. The "new stuff" is initially deployed in limited
   areas of the network, with a well-defined translation function
   between the new-stuff and the old-stuff. Over time, the
   new-stuff is deployed in more and more areas of the network.

   I am under the impression that there is a difference of opinion
   in this area. I believe in the second model since I feel that it
   offers advantages over the first
    - The first model limits the "end point" to some place that
      you can get to using small steps from the current place.
    - The second model lets us see the "final architecture" in
      operation (albeit in limited areas) fairly quickly. We can
      then evaluate it and decide whether it's the right answer
      or not. If it isn't, it's easy to dispose since it's
      deployed in limited areas. With the first model, we do not
      see the final architecture running until the entire net
    - One of the big problems with the current architecture is
      scaling. Scaling is also something that can be very hard
      to get right. if we use the second model then we can
      evaluate the scaling properties of the new architecture
      as we increase the load placed upon it.

3. Finally, the third way to look at evolution/revolution
   is in the process of figuring out what the new requirements
   and architecture should be. One could look at the current
   network and figure out what can be changed/added/deleted
   and where one can get to via that process. You are rooted in
   the current architecture. Or one could decide what needs to
   be done, regardless of the relative change w.r.t. the
   current system, and then figure out how to get there.

Frank Kastenholz

=======================================
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT