I freely admit that I have made comments in the places where issues
first caught
my eye, rather than trying for the best editorial placement. In many cases\
where I make comments, forward references may be all that's needed.
:-) I bought a new Dremel router yesterday. Talk about different architectures!
>
>
> 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.
>
> The Architecture Specification shall define each of these
> components, their jobs, and their interactions.
>
> Some thoughts to consider along these lines are
>
> 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.
This is the first point where I see a continuing problem. "Address"
is not used in
an unambiguous way, or at least not used here with appropriate
caveats. There are
several places where "address" later on could be an identifier, a
locator, or both. It
is unclear if "users", especially mobile users, have unique
identifiers at the routing
level.
>
> 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.
A nod here to sub-IP fault detection & healing, as complementary to
the main routing
system, would not be out of place. Later in the architecture, it may
be no more than
a standard set of service interfaces between RoutingNG and SubIP.
>
> o Making policy definition and application a separate
> subsystem, layered overtop of the others.
Is policy distribution within scope?
>
>
>
> Another facet of this requirement is that there may be multiple
> valid, loop free, paths available to a destination. When there
> are multiple valid, loop free, paths available, all such paths
> MUST be available for forwarding traffic.
Clarify that "valid" means valid in terms of financial/
>
> We wryly note that one of the original design goals of IP was
> to support a large, heavily interconnected, network, which
> would be highly survivable (such as in the face of a nuclear
> war).
Is the urban myth that ARPANET was intended to do this? Was this a
specific IP goal?
I honestly don't know. I did have access to nuclear war
communications designs in
the late 70s, and I can remember no mention of IP.
>
> 3.6 Multi-homing
>
>
> The Architecture MUST provide multi-homing for all elements of
> the Internet. That is, multihoming of hosts, subnetworks, end-
> sites, "low-level" ISPs, and backbones (i.e. lots of redundant
> interconnections) must be supported. Among the reasons to
> multi-home are reliability, load sharing, and performance
> tuning.
>
> The term "multihoming" may be interpreted in its broadest sense
> -- one "place" has multiple connections or links to another
> "place".
Even here, this is not the broadest sense. There certainly is
multihomed routing, but
there are also multihoming at other layers. See
draft-berkowitz-multireq-02.txt for
a possible taxonomy.
>
>
> A current problem in the Internet is that multihoming leads to
> undue increases in the size of the BGP routing tables. The new
> architecture must support multi-homing without causing undue
> routing table growth.
Ahem...wasn't group B criticized for considering BGP?;-)
>
>
> 3.7 Multi-path
>
>
> As a corollary to multi-homing, the Architecture MUST allow for
> multiple paths from a source to a destination to be active at
> the same time. These paths need not have the same attributes.
> Policies are to be used to disseminate the attributes and to
> classify traffic for the different paths.
>
> There must be a rich "language" for use in specifying the rules
> for classifying the traffic and assigning classes of traffic to
> different paths (or prohibiting it from certain paths). The
> rules for classification should allow traffic to be classified
> based on
> o IPv6 FlowIDs
> o TOS byte
> o Source and/or Destination prefixes
> o Random selections at some probability
> o ...
>
> A mechanism is needed that allows operators to plan and manage
> the traffic load on the various paths. To start, this
> mechanism can be semi-automatic, or even manual. Eventually it
> ought to become fully automatic.
>
>
> When multi-path forwarding is used, options must be available
> to preserve packet ordering where appropriate (such as for
> individual TCP connections).
>
> Past experience with dynamic load-balancing and management over
> multiple paths has been bad. Typically, traffic would
> oscillate, first all traffic would go over one path, then it
> would all be 'migrated' to a different path, and then back
> again. Significant research is needed in this area.
While I recognize both this area and the later are on "traffic
engineering" are tough to
define, it seems as if you're coming very close here to what I would
call traffic
engineering, yet you say it's undefinable later on.
>
>
> 3.8 Convergence
>
>
> The speed of convergence (also called the "stabilization time")
> is the time it takes for a router's routing processes to come
> up with a new, stable, "solution" (i.e. forwarding information
> base) after a change someplace in the network. In effect, what
> happens is that the output of the routing calculations
> stabilizes -- the Nth iteration of the software produces the
> same results as the N-1th iteration.
There is a lack of unambiguous terminology here. In BMWG, we have
attempted to define
it for the EGP That Cannot Be Named, and indeed are starting for
OSPF. The currently
posted version is draft-bmwg-conterm-01.txt; we do have an -02 about
ready for Last Call.
I would have no problem whatsoever with this architecture having some
formal definitions
of convergence. In our work, we recognize that there are at least
three kinds of convergence
to consider: single router, local system of routers, and global.
Our present effort deals
only with the first, although we may extend to the second.
In this document, you've actually made a start on the third. There
is other applicable work
here, such as Abha & Craig's research.
>
>
>
>
> No Bad Data
> Any new architecture and protocols must provide protection
> against the introduction of bad, bogus, or misleading, data
> by attackers. Of particular importance, an attacker must
> not be able to redirect traffic flows, with the intent of
>
> o Directing legitimate traffic away from a target, causing
> a denial-of-service attack by preventing legitimate data
> from reaching its destination,
> o Directing additional traffic (going to other
> destinations which are 'innocent bystanders') to a
> target, causing the target to be overloaded, or
> o Directing traffic addressed to the target to a place
> where the attacker can copy, snoop, alter, or otherwise
> affect the traffic.
Is this, or the paragraph below, to be read as Byzantine-robust?
Radia, care to comment?
>
>
> Data Consistency
> A router should be able to detect and recover from any data
> that is received from other routers which is inconsistent.
> That is, it MUST NOT be possible for data from multiple
> routers, none of which is malicious, to "break" another
> router.
>
>
>
> 3.11 Rich Policy
>
>
> Before setting out Policy requirements, we need to define the
> term. Like "security", "policy" means many things to many
> people. For our purposes, we define policy as
>
> Policy is the set of administrative influences that alter
> the path determination and next-hop selection procedures of
> the routing software.
>
> The main motivators for influencing path and next-hop selection
> seem to be transit rules, business decisions and load
> management.
>
> The new Architecture must support rich policy mechanisms.
> Furthermore, the policy definition and dissemination
> mechanismsshould be separated from the network topology and
> connectivity dissemination mechanisms. Policy provides input
> to and controls the generation of the forwarding table and the
> abstraction, filtering, aggregation, and dissemination of
> topology information.
>
> Note that if the architecture is properly divided into
> subsystems then at a later time, new policy subsystems that
> include new features and capabilities could be developed and
> installed as needed.
>
> We divide the general area of policy into two sub-categories,
> routing information and traffic control. Routing Information
> Policies control what routing information is disseminated or
> accepted, how it is disseminated, and how routers determine
> paths and next-hops from the received information. Traffic
> Control Policies determine how traffic is classified and
> assigned to routes.
The architecture should permit both dynamic policy distribution (in
the sense of ORF) as
well as policy registries that can be queried.
>
> 3.12 Incremental Deployment
>
>
> The reality of the Internet is that there can be no Internet-
> wide cutover from one architecture and protocol to another.
> This means that any new architecture and protocol MUST be
> incrementally deployable; ISPs must be able to set up small
> sections of the new architecture, check it out, and then slowly
> grow the sections. Eventually, these sections will "touch" and
> "squeeze out" the old architecture.
>
> The protocols that implement the Architecture MUST be able to
> interoperate at "production levels" with currently existing
> routing protocols. Furthermore, the protocol specifications
> MUST define how the interoperability is done.
>
> We also believe that sections of the Internet will never
> convert over to the new architecture. Thus, it is important
> that the new architecture and its protocols be able to
> interoperate with "old architecture" regions of the network
> indefinitely.
>
> The architecture's addressing system MUST NOT force existing
> address allocations to be redone: no renumbering!
>
>
> 3.13 Mobility
>
>
> There are two kinds of mobility; host mobility and network
> mobility. Host mobility is when an individual host moves from
> where it was to where it is. Network mobility is when an
> entire network (or subnetwork) moves.
Probably need to differentiate between host mobility (e.g., a host in
a moving vehicle)
and user mobility.
>
> The architecture MUST support network level mobility.
>
>
>
> 3.14 Address Portability
>
>
> One of the big "hot items" in the current Internet political
> climate is portability of IP addresses (both V4 and V6). The
> short explanation is that people do not like to renumber and do
> not trust automated renumbering tools.
>
> The Architecture MUST provide complete address portability.
But what does an address _DO_? Locator, Identifier, both, even more?
>
> 3.17 Simplicity
>
>
> The architecture MUST be simple enough so that Radia Perlman
> can explain all the important concepts in less than an hour.
I like this: definition of a fundamental unit, the Radia.
We may need other units, or at least ranges in the units. The
classical (in more
than one way) is the Helen, the unit of face that causes the launching of 1000
reference ships. The milliHelen, of course, launches one ship, while
the microHelen
probably causes someone to think about untying a rowboat from the
pier, and deciding
against it.
I'll be fascinated to know, for example, the scope of a deciRadia.
>
>
>
> 3.19 Media Independence
>
>
> While it is an article of faith that IP operates over a wide
> variety of media (such as Ethernet, X.25, ATM, and so on), IP
> routing must take an agnostic view towards any "routing" or
> "topology" services that are offered by the medium over which
> IP is operating. That is, the new architecture MUST NOT be
> designed to integrate with any media-specific topology
> management or routing scheme.
I prefer sub-IP to media here. If anything, RoutingNG is apt to talk
more to GMPLS
than medium specific interfaces, although I doubt this will ever be pure.
>
> The routing architecture must assume, and must work over, the
> simplest possible media.
>
> The routing and addressing architecture can certainly make use
> of lower-layer information and services, when and where
> available, and to the extent that IP routing wishes.
>
>
>
>
> 4.2 Traffic Engineering
>
>
> Traffic Engineering is one of those terms that has become
> terribly overloaded. If you ask N people what traffic
> engineering is, you get something like N! disjoint answers.
> Therefore, we elect not to require "traffic engineering", per
> se. Instead, we have endeavored to determine what the ultimate
> intent is when operators "traffic engineer" their networks and
> then make those capabilities an inherent part of the system.
See comments above.
>
>
> 4.4 QOS
>
>
> The Architecture concerns itself primarily with disseminating
> network topology information so that routers may select paths
> to destinations and build appropriate forwarding tables. QOS
> is not a part of this function and we make no requirements with
> respect to QOS.
>
> However, QOS is an area of great and evolving interest. It is
> reasonable to expect that in the not too distant future,
> sophisticated QOS facilities will be deployed in the Internet.
> Any new architecture and protocols should be developed with an
> eye towards these future evolutions. Extensibility mechanisms,
> allowing future QOS routing and signaling protocols to "piggy-
> back" on top of the basic routing system are desired.
>
> We do require the ability to assign attributes to entities and
> then do path generation and selection based on those
> attributes. Some may call this QOS.
Again, you allude to this earlier.
>
>
>
>
> 4.9 Host Mobility
>
>
> In the Internet Architecture, host-mobility is handled on a
> per-host basis by a dedicated, Mobile-IP protocol [6]. Traffic
> destined for a mobile-host is explicitly forwarded by dedicated
> relay agents. Mobile-IP [6] adequately solves the host-
> mobility problem and we do not see a need for any additional
> requirements in this area. Of course, the new architecture
> MUST NOT impede or conflict with Mobile-IP.
Given we have said this is to be revolutionary, and even examples
using BGP have
been criticized, I'd hesitate to say Mobile IP is an adequate
solution. We also need
to differentiate between host mobility on a common medium, as well as
movement to
different logical domains. We need to be clear when we are talking
about addressable
host mobility and when we are talking about user mobility.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT