Comments inline, but some metacomments first.
I am an added contributor to the FDR requirements draft. I made some
suggestions that weren't practical in the time available, but might
be worth considering. First, FDR should split into a history and a
requirements document. Both have value, but people already familiar
with the history don't want to wade through it.
In the IPng effort, there was what I considered a useful exercise in
getting the requirements of various mostly user communities, roughly
RFC 1667-1680. I think this might be worth redoing, including
getting current perceptions of critical ecommerce, 3G wireless, etc.
I'd be willing to coordinate a solicitation if that makes sense.
>
> o /
>------------------------------- X -------------------------------
> O \
>
>
>
>
>
> IRTF Routing Research Group F. Kastenholz, (ed)
> Internet Draft Unisphere Networks
> Document <draft-wgname-docname-00.txt> August 2001
> Category: Informational
>
>
> Requirements For a New Inter-Domain
> Routing and Addressing Architecture
Perhaps something on the lines of "scalable routing architecture for
the global Internet" might be less controversial.
>
>
> Status of this Memo
>
> This document is an Internet-Draft and is in full conformance
> with all provisions of Section 10 of RFC2026 [1].
>
> Internet-Drafts are working documents of the Internet
> Engineering Task Force (IETF), its areas, and its working
> groups. Note that other groups may also distribute working
> documents as Internet-Drafts. Internet-Drafts are draft
> documents valid for a maximum of six months and may be updated,
> replaced, or obsoleted by other documents at any time. It is
> inappropriate to use Internet- Drafts as reference material or
> to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt
>
> The list of Internet-Draft Shadow Directories can be accessed
> at http://www.ietf.org/shadow.html.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kastenholz (ed) Informational - Expires 2/2002 1
> Inter-domain Routing Requirements August, 2001
>
>
>
>
> Table of Contents
>
> 1 Abstract........................................................3
>
> 2 Conventions used in this document...............................3
>
> 3 Requirements....................................................3
>
> 3.1 Architecture...........................................4
>
> 3.2 Separable Components...................................4
>
> 3.3 Scalable...............................................5
>
> 3.4 Lots of Interconnectivity..............................7
>
> 3.5 Random Structure.......................................7
>
> 3.6 Convergence............................................8
>
> 3.7 Routing System Security...............................10
>
> 3.8 End Host Security.....................................12
>
> 3.9 Rich Policy...........................................12
>
> 3.10 Incremental Deployment..............................13
>
> 3.11 Multi-homing........................................14
>
> 3.12 Multi-path..........................................14
>
> 3.13 Mobility............................................15
>
> 3.14 Address Portability.................................15
>
> 3.15 Multi-Protocol......................................15
>
> 3.16 Abstraction.........................................16
>
> 3.17 Clean Slate.........................................16
>
> 3.18 Interior and Exterior...............................16
>
> 3.19 Simplicity..........................................17
>
> 3.20 Robustness..........................................17
>
> 3.21 Layer 2 Integration.................................18
>
> 3.22 Stand-alone.........................................18
>
> 3.23 Safety of Configuration.............................19
>
> 3.24 Renumbering of Subnets..............................19
>
> 3.25 Multi-prefix Subnets................................19
>
> 3.26 Cooperative Anarchy.................................19
>
> 3.27 Network Layer Protocols and Forwarding Model........19
>
> 3.28 Routing Algorithm...................................19
>
> 3.29 Positive Benefit....................................20
>
> 4 Non-Requirements...............................................20
>
> 4.1 Forwarding Table Optimization.........................20
>
> 4.2 Traffic Engineering...................................20
>
> 4.3 Multicast.............................................20
>
> 4.4 QOS...................................................21
>
> 4.5 IP Prefix Aggregation.................................21
>
> 4.6 Perfect Safety........................................21
>
> 4.7 Dynamic Load Balancing................................22
>
> 4.8 Renumbering of hosts and routers......................22
>
> 5 Discussion of other Inter-Domain Routing Requirements
>
> documents.........................................................22
>
>
>
> Kastenholz Informational -- Expires 2/2002 2
> Inter-domain Routing Requirements August, 2001
>
>
>
> 5.1 Comments on "Architectural Requirements for Inter-Domain
>
> Routing in the Internet"...................................23
>
> 5.2 Comments on "Future Domain Routing Requirements"......24
>
> 6 Security Considerations........................................26
>
> 7 IANA Considerations............................................26
>
> 8 References.....................................................26
>
> 9 Acknowledgments................................................27
>
> 10 Editor's Addresses............................................27
>
>
>
>
>
> 1 Abstract
>
>
> This note contains requirements developed by the Routing
> Research Group, for a new inter-domain routing and addressing
> architecture for the Internet.
>
> The seemingly simple requirement is to "fix routing and
> addressing". However, in order to "fix" it, we also need to
> understand how routing and addressing are _really_ used today.
> This is not a straightforward task. Service providers and
> network administrators have many different operational and
> administrative needs. Quite often, the only tool available to
> meet those needs is the routing system and they have proven
> amazingly crafty at using that tool in ways that were never
> envisioned. Thus, one of the most important steps in
> developing these requirements has been to learn what the
> operational community really is doing with the routing system,
> why they are doing it, and then abstracting those tasks.
>
>
>
> 2 Conventions used in this document
>
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in this document are to be interpreted as described
> in RFC-2119 [2].
>
> Editor's Note:
> We have not yet gone through the document and done the
> required SHOULD/MUST/MAY/etc-ing.
>
>
>
> 3 Requirements
>
>
> This chapter presents each of our requirements. We have
> endeavored to fashion these requirements rather than as a list
> of features to implement; in other words, we are trying to set
> out what the new architecture should do, not how it goes about
> doing it.
>
>
>
> Kastenholz Informational -- Expires 2/2002 3
> Inter-domain Routing Requirements August, 2001
>
>
> The requirements presented in this section are NOT presented in
> any order. A later version of this note may order the
> requirements in some kind of priority.
>
>
> 3.1 Architecture
>
>
> The new routing and addressing protocols, data structures, and
> algorithms MUST be developed from a clear, well thought out,
> documented, architecture.
>
> The new routing and addressing system must have an
> architectural specification which describes all of the routing
> and addressing elements, their interactions, what functions the
> system performs, and how it goes about performing them.
>
> The Architecture should be agnostic with regard to specific
> algorithms and protocols.
>
> Doing architecture before doing detailed protocol design is
> good engineering practice. This allows the architecture to be
> reviewed and commented upon, with changes made as necessary,
> when it is still easy to do so. Also, by producing an
> architecture, the eventual users of the protocols (the operator
> community) will have a better understanding of how the
> designers of the protocols meant them to be used.
>
>
> 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 Internet Routing Architecture should be divided into
> components, each doing a specified, targeted, job. The
> Architecture Specification shall define each of these
> components, their jobs, and their interactions.
>
> Some thoughts to consider along these lines are
>
>
> Kastenholz Informational -- Expires 2/2002 4
> Inter-domain Routing Requirements August, 2001
>
>
> 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.
Let me be sure I understand. By topology, do you mean physical
topology only, and by addressing, you mean logical? Should
identifiers/naming be identified separately here, so we can start the
address overloading jihad early? :-)
I assume there is some consideration of VPN addressing later in the
document. If not, for a non-specialist reader, a few words might be
appropriate.
>
> 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.
>
> o Making policy definition and application a separate
> subsystem, layered overtop of the others.
I agree that policy is a bit of hand-waving here, not unreasonably.
Should there be any mention this early of TE as one kind of policy?
Security policy is more complex, because we have to be concerned with
the overlapping needs of security/integrity of the routing system
itself, as well as security of user information.
>
>
> 3.3 Scalable
>
>
> Scaling is the primary problem facing the routing and
> addressing architecture today. This problem must be solved and
> it must be solved for the long term.
>
> The Architecture must support a large network. Ideally, it
> will serve our needs for the next 20 years. Unfortunately
> 1. We do not really know how big the Internet will grow over
> that time, and
> 2. The architecture developed from these requirements may
> change the fundamental structure of the Internet, and
> therefore its growth patterns. This change makes it
> difficult to predict future growth patterns of the
> Internet.
>
> As a result, we can't really quantify the requirement in any
> meaningful way. Using today's architectural elements as a
> mechanism for describing things, we believe that the network
> could grow to
> 1. Tens of thousands of AS's
> 2. 10's of millions to 100's of millions of prefixes during
> the lifetime of this architecture.
> These sizes are given as a 'flavor' for how we expect the
> Internet to grow. We fully believe that any new architecture
> may eliminate some current architectural elements and introduce
> new ones.
>
> A new routing and addressing architecture designed to a
> specific network size would be inappropriate. First, the cost
> of routing calculations is based only in part on the number of
> AS's or prefixes in the network. The number and locations of
>
>
> Kastenholz Informational -- Expires 2/2002 5
> Inter-domain Routing Requirements August, 2001
>
>
> the links in the network is also a significant factor. Second,
> past predictions of Internet growth and topology patterns have
> proven to be wildly inaccurate so developing an architecture to
> a specific size goal would at best be shortsighted.
>
> So we will not make the scaling requirement based on a specific
> network size. Instead, the new routing and addressing
> architecture should have the ability to constrain the increase
> in load (CPU, memory space and bandwidth, and network
> bandwidth) on ANY SINGLE ROUTER to be less than a specific
> function. We currently see the following functions:
>
> 1. The computational power and memory sizes required to execute
> the routing protocol software and to contain the tables must
> be less than the growth in hardware capabilities described
> by Moore's Law, which has hardware capabilities doubling
> every 18 months or so. Other observations indicate that
> memory sizes double every 2 years or so.
>
> 2. Network bandwidth and latency are some key constraints on
> how fast routing protocol updates can be disseminated (and
> therefore how fast the routing system can adapt to changes).
> Raw network bandwidth seems to quadruple every 3 years or
> so. However, it seems that there are some serious physics
> problems in going faster than 40gbits (OC768). We should
> not expect raw network link speed to grow much beyond OC768.
> In addition, for economic reasons, large swathes of the core
> of the Internet will still operate at lower speeds, possibly
> as slow as DS3.
DS3 is hardly a low speed for mobile communications, which still may
be routed. Consider, for example, military tactical networks and such
things as MANET.
>
> 3. The speeds of high-speed RAMS (SRAMs, used for caches and
> the like) are growing, though slowly. Because of their use
> in caches and other very specific applications, these RAMs
> tend to be small, a few megabits. Furthermore, the size of
> these RAMs is not increasing very rapidly.
>
> On the other hand, the speed of "large" memories (DRAMs) is
> increasing even slower than that for the high speed RAMS.
> This is because the development of these RAMs is driven by
> the PC market, where size is very important, and low speed
> can be made up for by better caches.
>
> Memory access rates should not be expected to increase
> significantly.
>
> The growth in resources available to any one router will
> eventually slow down. It may even stop. Even so, the network
> will continue to grow. The routing and addressing architecture
> must continue to scale in even this extreme condition. We can
> not continue to add more computing power to routers forever.
> Other strategies must be available. Some possible strategies
> are hierarchy, abstraction, and aggregation.
>
>
> Kastenholz Informational -- Expires 2/2002 6
> Inter-domain Routing Requirements August, 2001
>
>
>
> 3.4 Lots of Interconnectivity
>
>
> The new routing and addressing architecture MUST be able to
> cope with a high degree of interconnectivity in the Internet.
> That is, there are large numbers of alternate paths and routes
> among the various elements. Mechanisms are required to prevent
> this interconnectivity (and continued growth in
> interconnectivity) from causing tables, compute time, and
> routing protocol traffic to grow without bound.
>
> Over the past several years, the Internet has seen an increase
> in interconnectivity. That is, individual end sites
> (companies, customers, etc), ISPs, exchange points, and so on,
> all are connecting up to more "other things". Company's multi-
> home to multiple ISPs, ISPs peer with more ISPs, and so on.
> These connections are made for many reasons, such as getting
> more bandwidth, increased reliability and availability, policy,
> and so on. This increased interconnectivity leads to even more
> scaling problems as it increases the number of AS paths in the
> networks.
>
> Any new architecture must assume that the Internet becomes
> "meshier" (as well as messier?). It cannot assume, nor can it
> dictate, certain patterns or limits on how various elements of
> the network interconnect.
>
> Another facet of this requirement is that when there are
> multiple valid paths available, all valid paths should be used
> for forwarding traffic. Forwarding tables are updated and
> traffic is rerouted as individual paths come and go.
>
> This requirement is another facet of the "Random Structure"
> requirement.
>
> 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).
>
>
> 3.5 Random Structure
>
>
> 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 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.
>
> Some have proposed that a geographic addressing scheme be used,
> requiring exchange points to be situated within each geographic
>
>
> Kastenholz Informational -- Expires 2/2002 7
> Inter-domain Routing Requirements August, 2001
>
>
> 'region'. There are many reasons why we believe this to be a
> bad approach, but those arguments are irrelevant. The main
> issue is that the routing architecture should not presume a
> specific network structure.
>
>
> 3.6 Convergence
>
>
> The speed of convergence (also called the "stabilization time")
While I recognize our BMWG work deals specifically with current BGP,
the team involved went through a lot of struggle in trying to come up
with reasonably precise definitions of the MANY KINDS of convergence
time. Our draft is http://www.ietf.org/draft-ietf-bmwg-conterm-00.txt
A similar and broader, yet precise, definition of what we mean by
"convergence" needs to be established early in the new work,
obviously as a living document.
> 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.
>
> The speed of convergence is generally considered to be a
> function of the number of subnetworks in the network and the
> amount of connections between those networks. As either number
> grows, the time it takes to converge increases.
>
> In addition, because of policies embedded in the routing
> system, a change can "ripple" back and forth through the
> system. Simply put, one change can go through the system,
> causing some other router to change its advertised
> connectivity, causing a new change to ripple through. These
> oscillations can take a while to work their way out of the
> network. It is also possible that these ripples never die out.
> In this situation the routing and addressing system is
> unstable; it never converges.
>
> Finally, it is more than likely that the routers comprising the
> Internet never converge simply because the Internet is so large
> and complex. Assume it takes S seconds for the routers to
> stabilize on a solution for any one change to the network (a
> change being a link being added or deleted, a policy update,
> and so on). Also assume that changes occur, on average, every
> C seconds. Because of the size and complexity of the Internet,
> C<S. Therefore, if a change occurs at time T, the routing
> system would stabilize at time T+S, but a new change will occur
> at time T+C, which is before T+S. The system will start
> processing the new change before it's done with the old.
>
> This is not to say that all routers are constantly processing
> changes. The effects of changes are like ripples in a pond.
> They spread outward from where they occur. Some routers will
> be processing just the first change, others the second, others
> both, and others neither.
>
> We have two separate scopes over which we can set requirements
> with respect to convergence:
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 8
> Inter-domain Routing Requirements August, 2001
>
>
> 1. Single Change
> In this requirement a single change of any type (link
> addition or deletion, router failure or restart, etc.) is
> introduced into a stabilized system. No additional changes
> are introduced. The system must restabilize within TBDms.
> This requirement is a fairly abstract one as it would be
> impossible to test in a real network.
>
> 2. System-wide
> Defining a single target for maximum convergence time for
> the real Internet is absurd. As we mentioned earlier, the
> Internet is large enough and diverse enough so that it is
> quite likely that new changes are introduced somewhere
> before the system fully digests old ones.
>
> So, the first requirement here is that mechanisms be
> available to limit the scope of any one change's visibility
> and effects. The number of routers that have to perform
> calculations in response to a change is kept small, as is
> the settling time.
>
> The second requirement is based on the following assumptions
>
> - the scope of a change's visibility and impact can be
> limited. That is, routers within that scope know of
> the change and recalculate their tables based on the
> change. Routers outside of the scope don't see it at
> all.
>
> - Within any scope, S, network changes are constantly
> occurring and the average inter-change interval is Tc
> seconds.
>
> - There are Rs routers within scope S
>
> - A subset of the destinations known to the routers in
> S, Ds, are impacted by a given change.
>
> - We can state that Z% of the time, within Y% of Tc
> seconds after a change, C, X% of the Rs routers have
> their routes to Ds settled to a useful answer (useful
> meaning that packets can get to Ds, thought perhaps
> not by the optimal path -- this allows some 'hunting'
> for the optimal solution)
>
> X, Y, Z, ARE TBD
>
> This requirement implies that the scopes can be kept
> relatively small in order to minimize Rs and maximize Tc.
>
> The growth rate of the convergence time must not be related to
> the growth rate of the Internet as a whole. This implies that
> the convergence time either
>
> Kastenholz Informational -- Expires 2/2002 9
> Inter-domain Routing Requirements August, 2001
>
>
> 1. Not be a function of basic network elements (such as
> prefixes and links/paths), and/or
> 2. That the Internet be continuously divisible into chunks that
> limit the scope and effect of a change, thereby limiting the
> number of routers, prefixes, links, and so on involved in
> the new calculations.
>
>
> 3.7 Routing System Security
>
>
> The security of the Internet's routing system is paramount. If
> the routing system is compromised or attacked, the entire
> Internet can fail. This is unacceptable. Any new Architecture
> must be secure.
>
> Security means different things to different people. In order
> for this requirement to be useful, we must define what we mean
> by security. We do this by identifying the attackers and
> threats we wish to protect against. They are:
>
> Masquerading
> The system, including its protocols, must be secure against
> intruders adopting the identity of other known, trusted,
> elements of the routing system and then using that position
> for carrying out other attacks.
>
> DOS Attacks
> The architecture and protocols should be secure against DOS
> attacks directed at the routers.
>
> The new architecture should also provide as much information
> as it can to allow administrators to track down sources of
> DOS and DDOS attacks.
>
> 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
> munge the traffic.
>
> Topology Hiding
> Any new architecture and protocols must provide mechanisms
> to allow network owners to hide the details of their
>
>
>
> Kastenholz Informational -- Expires 2/2002 10
> Inter-domain Routing Requirements August, 2001
>
>
> internal topologies, yet maintaining the desired levels of
> connectivity and reachability.
>
> Privacy
> By "privacy" we mean privacy of the routing protocol
> exchanges between routers. In the past this has not been
> considered important for routing protocols.
>
> When the routers are on point-to-point links, with routers
> at each end, there is no need to encrypt the routing
> protocol traffic; there is no possibility of a third party
> intercepting the traffic, and if one of the two routers are
> compromised then it doesn't matter. This is not sufficient.
> We believe that it is important to have the ability to
> protect routing protocol traffic in two cases:
> 1. When the routers are on a shared network it is possible
> that there are hosts on the network that have been
> compromised. These hosts could surreptitiously monitor
> the protocol traffic.
> 2. When two routers are exchanging information "at a
> distance" (over intervening routers and, possibly,
> administrative domains). In this case, the security of
> the intervening routers, links, and so on, cannot be
> assured. Thus, the ability to encrypt this traffic is
> important.
>
> Therefore, we believe that the option to encrypt routing
> protocol traffic is required.
>
> 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 two routers,
> neither of which is malicious, to "break" a third router.
>
> Editor's Note:
> This is poorly worded. I'm trying to say that there
> should be no otherwise good data that, when combined on
> some other router, conspire to break that router or
> routing in general. Good text desperately sought!
>
> Security is provided through a combination of approaches, some
> in the routing, operation, and administration protocols and
> others in the fundamental architecture.
>
> Where security mechanisms are provided, they must use methods
> that are considered to be cryptographically secure (e.g. using
> cryptographically strong encryption and signatures -- no clear
> text passwords!).
>
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 11
> Inter-domain Routing Requirements August, 2001
>
>
>
> 3.8 End Host Security
>
>
> The Architecture must not prevent individual host-to-host
> communications sessions from being secured (i.e. it cannot
> interfere with things like IPSEC).
>
> There are also concerns about the privacy of hosts. In
> particular, "stamping" each host with an invariant and possibly
> widely known "ID" is considered unacceptable. The architecture
> must not rely on any such host ID.
>
> We do note, however, that things like host addresses need to be
> fairly invariant and entered into DNS in order to effect
> communications.
>
>
> 3.9 Rich Policy
>
>
> Editor's Note
> I am unhappy with this section. I think it says what I
> think I heard people say they think they want out of what
> they think they call "policy" (!). But I, obviously, am
> not sure. Also, I do not like the way the wording has
> turned out, editorially. And I still feel that something
> is "missing" (though I can't say what). Sigh.
>
> 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 administrative influences that alter the
> criteria used in the path and next-hop selection procedures
> of the routing software.
>
> That is, policy is what drives the configuration information
> that administrators enter into the system in order to change
> what next hops, paths, and so on, the routing system chooses.
> The main motivators for influencing path and next-hop selection
> seem to be transit rules, business decisions and load
> management.
>
> The transit rules define for whom a given service provider will
> carry traffic. Backbone networks tend to carry traffic going
> to any destination in the Internet while access networks tend
> to limit traffic to that going to or from their customers.
> There are, of course, many other variants.
>
> The business reasons for altering path selection are as varied
> as the number of service providers. Some considerations are
> NEED MORE ABOUT THE BUSINESS MODEL GLORP
> 1. Giving different routing information to different peers,
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 12
> Inter-domain Routing Requirements August, 2001
>
>
> 2. Causing certain customers' traffic to take "special" routes
> (e.g., a 'gold' customer's traffic might get shunted to a
> special path)
>
> Load Management is sometimes called traffic engineering today.
> Some of the basic goals are
> 1. To prevent overloads (and to route around them when they
> appear)
> 2. To prevent imbalances in traffic flows (eg, if there are two
> otherwise equally valid paths, traffic should be relatively
> balanced over them
> 3. To try and get outbound traffic off of a provider's network
> as soon as possible (and to keep inbound traffic out of the
> network for as long as possible). Of course, these are
> conflicting goals in a multi-provider environment.
>
> WHAT ELSE DO I PUT IN HERE?????????????????????????????
"Multihoming" (whatever it is -- see
http://www.ietf.org/draft-berkowitz-multireq-02.txt ) deals with both
TE and fault tolerance. I suggest that availability is another
component to be considered here, or perhaps moving section 3.11 up
here and then dealing with TE and availability as subcases.
>
> For the purposes of this note, "policy" does not does not cover
> things that are local to a single router. We believe that
> these are implementation issues. I NEED MORE DETAIL ON WHAT IS
> "NOT" A POLICY HERE!!!!
>
> The new Architecture must support rich policy mechanisms.
> Furthermore, the policy definition and dissemination processes
> should be separated from the network topology and connectivity
> dissemination processes. Policy must inform and control the
> generation of the forwarding table and the abstraction,
> filtering, aggregation, and dissemination of topology
> information.
>
> The finest granularity of a policy is an IPv4/6 prefix. The
> prefix could be the source prefix or the destination prefix.
> Things that are explicitly outside the scope of Policy are:
> o Protocol and port based functions,
> o TOS/QOS/DiffServ related operations
> o Per-host operations (i.e. /32s for IPv4 and /128s for
> IPv6),
> o Traffic matrices (e.g., traffic from prefix X and to
> prefix Y).
>
> 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
>
>
> 3.10 Incremental Deployment
>
>
> The reality of the Internet is that there can be no Internet-
> wide cutover from one architecture and protocol set to another.
> This means that any new architecture needs to be incrementally
> deployable; ISPs will need to set up small sections of the new
>
>
> Kastenholz Informational -- Expires 2/2002 13
> Inter-domain Routing Requirements August, 2001
>
>
> architecture, check it out, and then slowly grow the sections.
> Eventually, these sections will "touch" and "squeeze out" the
> old architecture.
>
> The Architecture must be incrementally deployable.
>
> 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.
>
> The architecture's addressing system must not force existing
> address allocations to be redone: no renumbering!
>
>
> 3.11 Multi-homing
>
>
> The Architecture must provide for multi-homing of all elements
> of the Internet. That is, multihoming of end-sites, "low-
> level" ISPs, and backbones (i.e. lots of redundant
> interconnections) must be supported. Multi-homing is done for
> reliability, to support load sharing, for performance tuning,
> among other reasons.
>
> The architecture must not limit the number of alternate paths
> to a multi-homed site.
>
> When multi-homing, it must be possible to use one, some (more
> than one but less than all) or all of the available paths to
> the multi-homed site. The multi-homed site must have the
> ability to declare which path(s) are used and under what
> conditions.
>
> 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.
>
>
> 3.12 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 metrics.
> Policies are to be used to disseminate the metrics 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
>
>
> Kastenholz Informational -- Expires 2/2002 14
> Inter-domain Routing Requirements August, 2001
>
>
> 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.
>
>
> 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.
>
> 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.
>
> Network mobility is when an entire network (identified by an IP
> Address prefix) moves from here to there. Examples might be
> cars, or personal area networks. The new 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. Thus, the Architecture
> MUST provide complete address portability.
>
>
> 3.15 Multi-Protocol
>
>
> The Internet is expected to be "multi-protocol" for at least
> the next several years. IPv4 and IPv6 will co-exist in many
> different ways during a transition period. Any new routing and
>
>
> Kastenholz Informational -- Expires 2/2002 15
> Inter-domain Routing Requirements August, 2001
>
>
> addressing architecture must be able to handle both IPv4 and
> IPv6 addresses.
>
> Furthermore, the architecture cannot assume any given
> relationships between a topological element's IPv4 address and
> its IPv6 address. The architecture cannot assume that all
> topological elements have IPv4 addresses/prefixes, nor can it
> assume that they have IPv6 addresses/prefixes.
>
> Editor's Note:
> Does MPLS get rolled in here too? How about all the other
> sub-ip-glorp?
>
>
> 3.16 Abstraction
>
>
> The architecture must provide mechanisms to for network
> designers and operators to
> o Group elements together for administrative control
> purposes,
> o Hide the internal structure and topology of those
> groupings for administrative and security reasons,
> o Limit the amount of topology information that is exported
> from the groupings in order to control the load placed on
> external routers,
> o Define rules for traffic transiting or terminating in the
> grouping.
>
> The architecture MUST allow the current Autonomous System
> structure to be mapped into any new administrative domains.
>
>
> 3.17 Clean Slate
>
>
> For the purposes of development of the architecture, we assume
> that there is a 'clean slate'. We explicitly assume that the
> concepts and mechanisms of the current IDR architecture do not
> need to be carried forward in the new architecture.
>
> Obviously, this point must be "used with care". Equal care
> must be taken to the competing need for the architecture to be
> deployable, and incrementally deployable. For example, if the
> architecture was designed so that every end-node of the
> Internet needed to be upgraded simultaneously, that
> architecture would not be valid (yes, this is an extreme
> example, but it serves to make the point).
>
>
> 3.18 Interior and Exterior
>
>
> We explicitly reject the notion that, architecturally, the
> "interior" of a topological element is somehow fundamentally
> different from its "exterior". The exterior of one topological
> element may be the interior of another (and vice versa). As
>
>
>
> Kastenholz Informational -- Expires 2/2002 16
> Inter-domain Routing Requirements August, 2001
>
>
> described in "Abstractions", above, these elements can be
> connected together in various ways.
>
> The architecture must not constrain certain protocols, or
> classes of protocols, to operate at specific levels of a
> hierarchy or in an "exterior" or an "interior" role.
>
> To state this more concretely with regard to the current
> routing architecture, the new architecture shall not have the
> EGP/IGP split.
>
> Clarification:
> We do recognize that at different points in the
> Internet, routing protocols with different properties
> and capabilities are desired and this need has driven
> the EGP/IGP split. What we reject is that it must be a
> two-way split and only a two-way split.
Agreed. Perhaps somewhere in the security section, or also here, we
need something about scope of administrative control.
>
> Editor's Note:
> We need words here to say that we are not replacing all
> routing protocols in one big go -- there must be co-
> existence, and we must be able to subsume some existing
> protocols in places -- OSPF/ISIS/RIP all work well in
> their corners of the net]
>
>
> 3.19 Simplicity
>
>
> The architecture MUST be sufficiently simple that Radia
> canexplain all the important concepts in less than an hour.
>
> 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".
>
> By keeping the architecture simple, the protocols and software
> used to implement the architecture are simpler. This
> simplicity in turn leads to:
>
> 1. Faster implementation of the protocols. If there are fewer
> bells and whistles, then there are fewer things that need to
> be implemented.
>
> 2. More reliable implementations. With fewer components, there
> is less code, reducing bug counts, and fewer interactions
> between components that could lead to unforeseen and
> incorrect behavior
>
>
> 3.20 Robustness
>
>
> The architecture, and the protocols implementing it, should be
> robust. Robustness comes in many different flavors. Some
>
>
> Kastenholz Informational -- Expires 2/2002 17
> Inter-domain Routing Requirements August, 2001
>
>
> considerations with regard to robustness include (but are not
> limited to):
> o Defective (even malicious) trusted routers.
> o Network failures. Whenever possible, valid alternate
> paths are to be found and used.
> o Failures must be localized. That is, the architecture
> must limit the "spread" of any adverse effects of a
> misconfiguration or failure. Badness must not spread.
> o ??????????????????????????????????????????????????There's
> got to be more!
I go back and forth about the relevance of the operator interface
here, but I remind everyone of Sue Hares' pithy observation that
"router jocks don't scale." We've talked of the lack of scalability
of semiconductor memory, but we need to consider the lack of
scalability of available human memory/processing. There needs to be
attention paid to what should be moved to algorithmic configuration
and response, in order to lessen the operational skill load. While a
true routing expert may be able to optimize beyond the algorithms
(well, OK, heuristics as well), a scalable architecture is scalable
in its requirements for human resources. See Sections 3.23 and 4.6.
>
> Of course, the general robustness principle of being liberal in
> what's accepted and conservative in what's sent must also be
> applied.
>
> EDITOR'S NOTE:
> I made this a separate, robustness, requirement even
> though Radia suggested/implied/I-read-her-note-as-saying
> it should be a part of security. First, security in too
> many peoples' minds means "protection from break-ins"
> and the like. This goes beyond that. So I figure by
> making a new requirement, things would be clearer.
> Second, by adding 'robustness' we have a new thing to
> talk about...
>
>
> 3.21 Layer 2 Integration
>
>
> While it is an article of faith that IP operates over a wide
> variety of lower layers, layer-3 (i.e., IP) routing must take
> an agnostic view towards any "routing" or "topology" services
> that are offered by layer 2. That is, the new architecture
> MUST NOT be designed to integrate with any specific layer-2
> topology management or routing scheme. A strict layer-2/layer-
> 3 separation MUST be honored.
>
> The routing architecture must assume, and must work over, the
> simplest possible layer-2.
>
> The routing and addressing architecture can certainly make use
> of Layer-2 information when and where available, and to the
> extent that IP routing wishes.
>
>
> 3.22 Stand-alone
>
>
> The routing architecture and protocols must not rely on other
> components of the Internet (such as DNS) for their correct
> operation. Routing is the fundamental procedure by which data
> "finds its way around the Internet" and most, if not all, of
> those other components rely on routing to properly forward
> their data. Thus, Routing cannot rely on any Internet systems,
> services or capabilities that in turn rely on Routing. If it
> did, a dependency loop would result.
>
>
> Kastenholz Informational -- Expires 2/2002 18
> Inter-domain Routing Requirements August, 2001
>
>
>
> 3.23 Safety of Configuration
>
>
> The architecture, protocols, and standard implementation
> defaults must be such that a router installed "out of the box"
> with no configuration/etc by the operators will not cause "bad
> things" to happen to the rest of the routing system (no dialup
> customers advertising routes to 18/8!)
>
>
> 3.24 Renumbering of Subnets
>
>
> The routing system must allow for subnets to be renumbered.
>
>
> 3.25 Multi-prefix Subnets
>
>
> The routing system must allow subnets to have multiple
> prefixes. This may be required for renumbering.
>
>
> 3.26 Cooperative Anarchy
>
>
> As RFC1726[5] said:
>
> A major contributor to the Internet's success is the fact
> that there is no single, centralized, point of control or
> promulgator of policy for the entire network. This allows
> individual constituents of the network to tailor their own
> networks, environments, and policies to suit their own needs.
> The individual constituents must cooperate only to the degree
> necessary to ensure that they interoperate.
>
> This decentralization, called "cooperative anarchy", is still a
> key feature of the Internet today. The new routing
> architecture MUST retain this feature. There can be no
> centralized point of control or promulgator of policy for the
> entire Internet.
>
>
> 3.27 Network Layer Protocols and Forwarding Model
>
>
> Any new routing and addressing architecture and protocols MUST
> work with IPv4 and IPv6 using the traditional "hop by hop"
> forwarding model. Additional forwarding models MAY be added.
>
> Editor's Note
> MPLS?
>
>
> 3.28 Routing Algorithm
>
>
> The architecture MUST NOT require a particular routing
> algorithm family. That is to say, the architecture must be
> agnostic with regard to using link-state, distance-vector, or
> path-vector routing algorithms.
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 19
> Inter-domain Routing Requirements August, 2001
>
>
>
> 3.29 Positive Benefit
>
>
> Finally, the architecture must show benefits, in terms of
> increased stability, decreased operational costs, and increased
> functionality and lifetime over the current schemes. This
> benefit must remain even after the inevitable costs of
> developing and debugging the new protocols, enduring the
> inevitable instabilities as things get shaken out, and so on.
>
>
>
> 4 Non-Requirements
>
>
> The following are not required or are non-goals. This should
> not be taken to mean that these issues must not be addressed by
> a new architecture. Rather, addressing these issues or not is
> purely a matter for the architects. The only caveat is that
> the architecture must not deal with one of these issues at the
> expense of not dealing with the required issues.
>
>
> 4.1 Forwarding Table Optimization
>
>
> We believe that it is not necessary for the architecture to
> minimize the size of the forwarding tables (FIBS). Current
> memory sizes, speeds, and prices, along with processor and ASIC
> capabilities allow forwarding tables to be very large, O(E6),
> and fast (100M lookups/second) tables to be built with little
> difficulty.
>
>
> 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.
I suspect that one can separate the higher-layer requirement of TE
from the lower-level routing requirement of multihoming.
>
>
> 4.3 Multicast
>
>
> The new architecture is not designed explicitly to be an inter-
> domain multicast routing architecture. However, given the
> notable lack of a viable, robust, and widely deployed inter-
> domain multicast routing architecture, the architecture should
> not hinder the development and deployment of inter-domain
> multicast routing without adverse effect on meeting the other
> requirements.
>
> We do note however that one respected network sage has said
> (roughly)
> When you see a bunch of engineers standing around
> congratulating themselves for solving some particularly
>
>
> Kastenholz Informational -- Expires 2/2002 20
> Inter-domain Routing Requirements August, 2001
>
>
> ugly problem in networking, go up to them, whisper
> "multicast", jump back, and watch the fun begin...
>
>
> 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.
>
>
> 4.5 IP Prefix Aggregation
>
>
> There are no requirements that IP Prefix aggregation be done by
> the new architecture. In fact, it is an explicit goal not to
> do so. Address allocation policies, societal pressure, and the
> random growth and structure of the Internet have all conspired
> to make prefix aggregation extraordinarily difficult, if not
> impossible.
>
> This means that large numbers of prefixes will be sloshing
> about in the routing system and that forwarding tables will
> grow quite big. This is a cost that we believe must be borne.
>
> Nothing in this non-requirement should be interpreted as saying
> that prefix aggregation is explicitly prohibited. Wherever, by
> good fortune, it can be done, it should be done.
>
>
> 4.6 Perfect Safety
>
>
> Making the system impossible to misconfigure is, we believe,
> not required. The checking, constraints, and controls
> necessary to achieve this could, we believe, prevent operators
> from performing necessary tasks in the face of unforeseen
> circumstances.
>
> However, safety is always a "good thing", and any results from
> research in this area should certainly be taken into
> consideration and, where practical, incorporated into the new
> routing architecture.
>
>
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 21
> Inter-domain Routing Requirements August, 2001
>
>
>
> 4.7 Dynamic Load Balancing
>
>
> Past history has shown that using the routing system to perform
> highly dynamic load balancing among multiple more-or-less-equal
> paths usually ends up causing all kinds of instability, etc, in
> the network. Thus, we do not require such a capability.
>
> However, this is an area that is ripe for additional research,
> and some believe that the capability will be necessary in the
> future. Thus, the architecture and protocols should be
> "malleable" enough to allow development and deployment of
> dynamic load balancing capabilities, should we ever figure out
> how to do it.
>
>
> 4.8 Renumbering of hosts and routers
>
>
> We believe that the routing system is not required to "do
> renumbering" of hosts and routers. That's an IP issue.
>
> Of course, the routing and addressing architecture must be able
> to deal with renumbering when it happens.
>
>
>
> 5 Discussion of other Inter-Domain Routing Requirements documents
>
>
> Recently, two other Internet Drafts have been published that
> set out some requirements for a new Inter-Domain routing
> architecture. These drafts are "Future Domain Routing
> Requirements" by Elwyn Davies, et al [3], and "Architectural
> Requirements for Inter-Domain Routing in the Internet" by Geoff
> Huston [4].
>
> Rather than use these documents, we decided to develop our own
> set of requirements for a future inter-domain routing
> architecture. The reasons are
>
> 1. There are requirements in [3] and [4] with which we do not
> agree, plus we have additional requirements that are not
> in those documents.
>
> 2. We do not agree with the methodology in [3] and [4]. In
> particular, [3]'s list of requirements seems to us like an
> exhaustive list of things, falling dangerously close to
> the "My Layer MUST solve all of networking's problems"
> disease. One of the hardest parts of setting requirements
> is to determine what problems will NOT be solved.
>
> [3] and [4] each provide excellent historical background
> information. Rather than repeat the information here, readers
> are encouraged to consult those documents.
>
> Discussions and commentary on each internet-draft follow.
>
>
> Kastenholz Informational -- Expires 2/2002 22
> Inter-domain Routing Requirements August, 2001
>
>
>
> 5.1 Comments on "Architectural Requirements for Inter-Domain
>
> Routing in the Internet"
>
>
> The IAB have developed an internet-draft titled "Architectural
> Requirements for Inter-Domain Routing in the Internet" [4].
> Rather than using [4], we have produced our own document.
>
> A good part of [4] is a detailed explanation of the current
> problems in routing and addressing. This work is valuable. We
> chose not to replicate it in this note.
>
> The main reason we decided not to use [4] is that it is too
> rooted in the current BGP/AS model. We believe that the
> charter for the Routing Research Group is to work on longer-
> term futures, including the possibility of replacing that
> model. We wish to develop our requirements in a forward-
> looking manner and using requirements rooted in the old model
> may cause us to unwittingly constrain our thinking.
>
> [4] Enumerates four requirements for a new routing
> architecture. These requirements are fairly broad and loose.
> They are:
>
> Scalability
> We agree. The new architecture must be scalable. We have
> included a requirement for scalability.
>
> Stability and Predictability
> Yes, the routing and addressing architecture should be
> stable and predictable. However, we are not sure that
> overall this is possible.
>
> Convergence
> Fast convergence would be nice. However, the size and
> complexity of the Internet are such that we do not believe
> that the entire net can ever converge. Changes with global
> impact will always be happening and their effects will be
> constantly propagating through the network. We expect that
> any routing system will, at best, be able to converge
> incrementally. That is, in any one place, convergence with
> respect to one change can occur, but before the entire net
> converges, another change will occur, requiring a new set
> of calculations and a "new" convergence.
>
> We prefer to believe that convergence at any single point
> and after any single change must occur quickly. Also,
> since we expect that the network will constantly by (re-
> converging, so the load of those attempts must be minimal.
>
> Routing Overhead
> Routing overhead should be minimized. True.
>
>
>
> Kastenholz Informational -- Expires 2/2002 23
> Inter-domain Routing Requirements August, 2001
>
>
>
> 5.2 Comments on "Future Domain Routing Requirements"
>
>
> A separate group is developing a document titled "Future Domain
> Routing Requirements" [3].
>
> Rather than using [3], we have produced our own document. As
> with [4] we believe that this document is too rooted in the
> current BGP/AS model, which is not a useful context for
> developing long-term future architectures.
>
> We have a number of observations on [3], in no particular
> order:
>
> 1. The introductory/historical/background is fine. In fact,
> that material should be considered "required reading" to
> understand the background and current problems of Internet
> Routing. We commend the authors of [3] for putting this
> material together.
>
> 2. The "goals" section (1.2) seems to be heavily oriented to
> specific issues and tasks that network designers and
> administrators face today. Our charter calls for us to
> consider the very long term. Thus, it is hard to say what
> specific tasks the operations community needs to perform.
> Therefore, we prefer to take a broader view of what
> routing should do and have written our document
> accordingly.
>
> 3. [3] Seems still wedded to the old BGP/AS model of doing
> inter-domain routing. That may well be an adequate model.
> However, the Routing Research Group's charter is to
> consider and develop long-term future directions in
> routing. We prefer to develop our own document, trying to
> avoid falling into the "traps" of the past.
>
> 4. The document seems to be an exhaustive wish list of
> things. The hardest part of doing requirements is to
> figure out what not to require. Coincident with that
> observation, there were a couple of "would be nice" and
> "might be needed" sorts of things. The fear is that they
> fell into the trap of "All problems must be solved in our
> layer", which leads to very poor architectures and
> designs.
>
> 5. They call for "support for NATs and other mid-boxes". If
> the Routing and Addressing architecture is "right" then
> there is no need for them, at least as far as Routing and
> Addressing are concerned.
>
> Also, we are confused as to what "support for NATs..."
> actually means.
>
>
>
> Kastenholz Informational -- Expires 2/2002 24
> Inter-domain Routing Requirements August, 2001
>
>
> 6. The authors of [3] talk a fair bit about some low-level
> things they want. Our opinion is that we are looking "too
> far out" to talk about detailed, low-level requirements.
> We really don't know what the operators of 2007 will want.
> Besides solving the basic problem of getting topological
> and addressing information "around", we need to think more
> about how to keep the architecture (and design and
> implementation) flexible and open so that in 2006 when
> someone says "We need a gonkulator!" we can say "Easy, it
> gets plugged in here..."
>
> 7. Multicast/Anycast
> We do not believe that multicast routing is a part of our
> charter.
>
> Anycast is a fairly nebulous technology. To require that
> routing "support" it at this stage in its development is
> premature. To require that routing support anycast means,
> in effect, that we first define what it is.
>
> 8. Support for renumbering
> We take this to mean either that
> o The routing-and-addressing system actually does the
> renumbering, to which we reply "Is this really
> something for routing to do?", or
> o The routing-and-addressing system must continue to
> operate when elements of the network are renumbered.
> We have a requirement for this
>
> 9. Statistics support
> This seems to us to be a low-level protocol issue. Yes
> the protocol needs a MIB. But we do not believe that this
> is an architectural or requirements issue.
>
> This also indicates to us that [3] is more concerned with
> lower-level protocol and implementation issues rather than
> taking the proverbial "step back" to look at "the big
> picture".
>
> 10. There were some comments about convergence that
> seemed to indicate that the authors of [3] are thinking of
> global convergence. We have observed that global
> convergence is probably not doable anymore. We believe
> that "permanent change" is the order of the day...
>
> 11. One of their open-issues indicates that the
> authors of [3] are thinking about whether the EGP/IGP
> split is good or not. It's good they are thinking about
> it. It's bad that they consider it open. We consider
> this split to be A Bad Thing -- there should be no such
> split in the architecture.
>
>
>
> Kastenholz Informational -- Expires 2/2002 25
> Inter-domain Routing Requirements August, 2001
>
>
> 12. One example of the too fine a level of detail they
> are getting into is that in 7.2.2 they talk about having a
> number of specific path attributes. But, if say in 2007
> we discover a need for a gonkulation attribute, it's not
> in the list in [3]. Perhaps we are taking their document
> too literally, but someone taking [3] and designing to it
> would maybe make attributes TLV's and leave it at that.
> They really wouldn't consider the effects of unconsidered
> new attributes. We prefer to think of things in the
> reverse order:
>
> We know we need attributes, but we don't know what they
> all are. Therefore the attribute mechanism must be
> flexible and allow growth in weird new directions
> without causing problems on the rest of the system --
> so how do we do that.
>
>
>
> 6 Security Considerations
>
>
> We address security issues in the individual requirements. We
> do require that the Architecture and protocols developed
> against this set of requirements be "secure".
>
>
>
> 7 IANA Considerations
>
>
> This document is a set of requirements from which a new routing
> and addressing architecture will be developed. From that
> architecture, a new protocol, or set of protocols, may be
> developed.
>
> While this note poses no new tasks for IANA, the architecture
> and protocols developed from this document probably will have
> issues to be dealt with by IANA.
>
>
>
> 8 References
>
>
> [1] Bradner, S., "The Internet Standards Process - Revision 3",
> BCP9, RFC2026, October 1996.
>
> [2] Bradner, S., "Key words for use in RFCs to Indicate
> Requirements Levels", BCP 14 RFC 2119, March 1997.
>
> [3] Davies, E., et al, "Future Domain Routing Requirements",
> draft-davies-fdr-reqs-01.txt, July 2001, Work In Progress.
>
> [4] Huston, G., "Architectural Requirements for Inter-Domain
> Routing in the Internet" draft-iab-bgparch-01.txt, May
> 2001, Work In Progress.
>
>
>
> Kastenholz Informational -- Expires 2/2002 26
> Inter-domain Routing Requirements August, 2001
>
>
> [5] Partridge, C., and F. Kastenholz, "Technical Criteria for
> Choosing IP The Next Generation (IPng)", RFC 1726. December
> 1994.
>
> [6] Perkins, C., "IP Mobility Support." RFC2002, October 1996.
>
>
>
> 9 Acknowledgments
>
>
> This document is the product of the IRTF Routing Research
> Group’s sub-group on Inter-domain routing requirements. The
> members of the group are
>
> Abha Ahuja Danny McPherson
> J. Noel Chiappa David Meyer
> Sean Doran Mike O’Dell
> JJ Garcia-Luna-Aceves Andrew Partan
> Susan Hares Radia Perlman
> Geoff Huston Yakov Rehkter
> Frank Kastenholz John Scudder
> Dave Katz Curtis Villamizar
> Tony Li Dave Ward
>
>
>
> 10 Editor's Addresses
>
>
> Frank Kastenholz
> Unisphere Networks
> 10 Technology Park
> Westford, MA, 01886, USA
>
> Phone: +1 978 589 0286
> Email: fkastenholz@unispherenetworks.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 27
> Inter-domain Routing Requirements August, 2001
>
>
>
>
> Full Copyright Statement
>
> "Copyright (C) The Internet Society (date). All Rights
> Reserved. This document and translations of it may be copied
> and furnished to others, and derivative works that comment on
> or otherwise explain it or assist in its implementation may be
> prepared, copied, published and distributed, in whole or in
> part, without restriction of any kind, provided that the above
> copyright notice and this paragraph are included on all such
> copies and derivative works. However, this document itself may
> not be modified in any way, such as by removing the copyright
> notice or references to the Internet Society or other Internet
> organizations, except as needed for the purpose of developing
> Internet standards in which case the procedures for copyrights
> defined in the Internet Standards process must be followed, or
> as required to translate it into
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kastenholz Informational -- Expires 2/2002 28
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT