At 08:47 AM 3/7/02 -0500, Russ White wrote:
> 3.2 Separable Components
>
>
> The architecture MUST place different functions into separate
> components.
>
> Separating functions, capabilities, and so forth, into
> individual components, and making each component "stand alone"
> is generally considered by system architects to be "A Good
> Thing". It allows individual elements of the system to be
> designed and tuned to do their jobs "very well". It also
> allows for piecemeal replacement and upgrading of elements as
> new technologies and algorithms become available.
>
> The architecture MUST have the ability to replace or upgrade
> existing components, and to add new ones, without disrupting
> the remaining parts of the system. Operators must be able to
> roll out these changes and additions incrementally (i.e. no
> "flag days"). These abilities are needed to allow the
> architecture to evolve as the Internet changes.
>
>I assume you mean here that layering is a good thing, and layer
>violations are a bad thing? It doesn't say so explicitely,
>but.... I'm actually kindof trying to figure out what it does say
>explicitely. :-)
It most certainly does not mean _layering_. Nor does it mean
_not_layering_. It means that there are separate components.
Some might be "layered" over others, some might not. It really
depends on the architecture one develops.
> o Making topology and addressing separate subsystems. This
> may allow highly optimized topology management and
> discovery without constraining the addressing structure or
> physical topology in unacceptable ways.
>
>Do you mean here to have one address which indicates the topology
>point of attachment for a device, and another address which
>identifies the device? How do you propogate topology information
>without assigning some identifier to topology elemnts and
>propogating those identifiers?
This is simply an item to stir up the little gray cells.
> o Separate "fault detection and healing" from basic
> topology. From Mike O'Dell:
> "Historically the same machinery is used for both.
> While attractive for many reasons, the availability of
> exogenous topology information (i.e., the intended
> topology) should, it seems, make some tasks easier than
> the general case of starting with zero knowledge. It
> certainly helps with recovery in the case of constraint
> satisfaction. In fact, the intended topology is a
> powerful way to state certain kinds of policy.
>
>Since the way we generally heal after we've detected a fault is
>to change the path through the topology, I'm not certain I
>understand how you can seperate the two? In other words, a fault
>is actually more readily seen as a change in topology, rather
>than as a failure. Or should failures be treated differently than
>intentional changes in topology?
More food for the little gray cells.
> The architecture should also separate topology. routing and
> addressing from the application that use those components.
> This implies that applications such as policy definition,
> forwarding, and circuit and tunnel management are separate
> subsystems layered overtop of the basic topology, routing, and
> addressing systems.
>
>I think you are saying here that the application should not use
>or rely on topology information to do it's work (?). I'm not
>certain how applications will be able to seperate themselves from
>addressing, since they must have an address to know what to
>connect to.
"Are separate subsystems layered overtop of the basic topology"...
implies that they use the basic topology/... system. We have to
be careful here -- we don't want the requirements specification
to actually specify the architecture :-)
> Another facet of this requirement is that there may be multiple
> valid paths available to a destination. When there are
> multiple valid paths available, all valid paths MUST be
> available for forwarding traffic.
>
>I would say 'loop-free' in here some place, since it seems to be
>a clearer statement than a 'valid path.'
Well, there may be other considerations besides "loop free"
(eg, it has to get you where you want to go :-). I've added
the term loop-free to the text for the next version.
> The routing and addressing architecture MUST NOT make any
> constraints on or assumptions about the topology or
> connectedness of the elements comprising the Internet. The
> routing and addressing architecture MUST NOT presume any
> particular network structure. The network does not have a
> "nice" structure. In the past we used to believe that there
> was this nice "backbone/tier-1/tier-2/end-site" sort of
> hierarchy. This is not so. Therefore, any new Architecture
> must not presume any such structure.
>
>Hmmm.... This seems a little harsh. You must assume a
>hierarchical structure which provides aggregation points, or
>otherwise the routing system must suppose 2^128th addresses as
>individual, routable, addresses. In fact, the paper earlier
>states that aggregation is one method to reduce perceived
>network complexity, among others--each of these methods brings an
>implied netowrk structure of some type.
Maybe this requirement can not be met. Maybe by stating it
(harshly, as you say) it will inspire someone to have an
Aha! moment...
Also, if you presuppose a certain type of topology then the
problem gets easy. But that means that for an architecture
to work, someone will have to tell _all_ the ISPs in the world
to redesign their networks, connectivity, peering, and so on.
I will _not_ be the one to do that :-)
> The Architecture MUST NOT prevent individual host-to-host
> communications sessions from being secured (i.e. it cannot
> interfere with things like IPSEC).
>
>The counter to this is that mechanisms which secure
>communications between the attached hosts must not rely on
>topology point of attachment information to provide security in
>any way. This is a layering violation, and as such, is a bad
>thing.
Well, that's a part of it. I think that our wording is
more what we want. Your text says that security can not
rely on topology. But there are other possible interactions
that would kill security. Suppose, for example, that one
would propose an architecture that required looking at
the payload of the packets (this is hypothetical - I
have no idea what kind of architecture this is!). You
could not encrypt your packets if this architecture
is in place. Our text eliminates this type of solution,
yours would not.
> The Architecture MUST provide multi-homing for all elements of
> the Internet. That is, multihoming of end-sites, "low-level"
> ISPs, and backbones (i.e. lots of redundant interconnections)
>
>I would include hosts here, as people start wanting reliable
>communcations to their cell phones. It's just a matter of time,
>you know.... :-)
Sigh.
> The requirement is that the routing architecture be kept as
> simple as possible. This requires careful evaluation of
> possible features and functions with a merciless weeding out of
> those that "might be nice".
>
>But any protocols also need to be extensible in a simple,
>lightweight way, to account for things not thought of here....
Yup - that is a 'feature' of the "component" requirement, section 3.2
> 4.5 IP Prefix Aggregation
>
>This section seems to contradict the earlier section which states
>that the system must be scalable. :-)
We're just saying that if you can come up with a way to scale
without aggregating prefixes, that is just fine...
==================================================
My preferrred signature is:
This information is for the sole use of
whoever receives it and may contain confusing,
enlightening, enraging, entertaining,
irritating, or just plain stupid information,
including without limitation, double-secret-
probation information belonging to [CENSORED
BY THE NSA/FBI/MOUSE]. Any unauthorized review,
use, disclosure, or distribution outside of an
establishment serving alchohol is prohibited on
days that do not end in Y.
But our ******'d lawyers would rather have:
=======================================
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