rfc3221.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,299 行 · 第 1/5 页

   that the global requirement for stability implies some degree of
   locality in the behavior of the system.



Huston                       Informational                     [Page 14]

RFC 3221           Commentary on Inter-Domain Routing      December 2001


6.3  Convergence

   Any routing system should have adequate convergence properties.  By
   adequate it is implied that within a finite time following a change
   in the external environment, the routing system will have reached a
   shared common description of the network's topology that accurately
   describes the current state of the network and is stable.  In this
   case finite time implies a time limit that is bounded by some upper
   limit, and this upper limit reflects the requirements of the routing
   system.  In the case of the Internet this convergence time is
   currently of the order of hundreds of seconds as an upper bound on
   convergence.  This long convergence time is perceived as having a
   negative impact on various applications, particularly those that are
   time critical.  A more useful upper bound for convergence is of the
   order of seconds or lower if it is desired to support a broad range
   of application classes.

   It is not a requirement to be able to undertake full convergence of
   the inter-domain routing system in the sub-second timescale.

6.4  Routing Overhead

   The greater the amount of information passed within the routing
   system, and the greater the frequency of such information exchanges,
   the greater the level of expectation that the routing system can
   maintain an accurate view of the connectivity of the network.
   Equally, the greater the amount of information passed within the
   routing system, and the higher the frequency of information exchange,
   the higher the level of overhead consumed by operation of the routing
   system.  There is an element of design compromise in a routing system
   to pass enough information across the system to allow each routing
   element to have adequate local information to reach a coherent local
   view of the network, yet ensure that the total routing overhead is
   low.

7.  Architectural approaches to a scalable Exterior Routing Protocol

   This document does not attempt to define an inter-domain routing
   protocol that possess all the attributes as listed above, but a
   number of architectural considerations can be identified that would
   form an integral part of the protocol design process.

7.1  Policy opaqueness vs. policy transparency

   The two major approaches to routing protocols are distance vector and
   link state.





Huston                       Informational                     [Page 15]

RFC 3221           Commentary on Inter-Domain Routing      December 2001


   In the distance vector protocol a routing node gathers information
   from its neighbors, applies local policy to this information and then
   distributes this updated information to its neighbors.  In this model
   the nature of the local policy applied to the routing information is
   not necessarily visible to the node's neighbors, and the process of
   converting received route advertisements into advertised route
   advertisements uses a local policy process whose policy rules are not
   visible externally.  This scenario can be described as 'policy
   opaque'.  The side effect of such an environment is that a third
   party cannot remotely compute which routes a network may accept and
   which may be re-advertised to each neighbor.

   In link state protocols a routing node effectively broadcasts its
   local adjacencies, and the policies it has with respect to these
   adjacencies, to all nodes within the link state domain.  Every node
   can perform an identical computation upon this set of adjacencies and
   associated policies in order to compute the local forwarding table.
   The essential attribute of this environment is that the routing node
   has to announce its routing policies, in order to allow a remote node
   to compute which routes will be accepted from which neighbor, and
   which routes will be advertised to each neighbor and what, if any,
   attributes are placed on the advertisement.  Within an interior
   routing domain the local policies are in effect metrics of each link
   and these polices can be announced within the routing domain without
   any consequent impact.

   In the exterior routing domain it is not the case that
   interconnection policies between networks are always fully
   transparent.  Various permutations of supplier / customer
   relationships and peering relationships have associated policy
   qualifications that are not publicly announced for business
   competitive reasons.  The current diversity of interconnection
   arrangements appears to be predicated on policy opaqueness, and to
   mandate a change to a model of open interconnection policies may be
   contrary to operational business imperatives.

   An inter-domain routing tool should be able to support models of
   interconnection where the policy associated with the interconnection
   is not visible to any third party.  If the architectural choice is a
   constrained one between distance vector and link state, then this
   consideration would appear to favor the continued use of a distance
   vector approach to inter-domain routing.  This choice, in turn, has
   implications on the convergence properties and stability of the
   inter-domain routing environment.  If there is a broader spectrum of
   choice, the considerations of policy-opaqueness would still apply.






Huston                       Informational                     [Page 16]

RFC 3221           Commentary on Inter-Domain Routing      December 2001


7.2  The number of routing objects

   The current issues with the trend behaviors of the BGP space can be
   coarsely summarized as the growth in the number of distinct routing
   objects, the increased level of dynamic behaviors of these objects
   (in the form of announcements and withdrawals).

   This entails evaluating possible measures that can address the growth
   rate in the number of objects in the inter-domain routing table, and
   separately examining measures that can reduce the level of dynamic
   change in the routing table.  The current routing architecture
   defines a basic unit of a route object as an originating AS number
   and an address prefix.

   In looking at the growth rate in the number of route objects, the
   salient observation is that the number of route objects is the
   byproduct of the density of the interconnection mesh and the number
   of discrete points where policy is imposed of route objects.  One
   approach to reduce the growth in the number of objects is to allow
   each object to describe larger segments of infrastructure.  Such an
   approach could use a single route object to describe a set of address
   prefixes, or a collection of ASs, or a combination of the two.  The
   most direct form of extension would be to preserve the assumption
   that each routing object represents an indivisible policy entity.
   However, given that one of the drivers of the increasing number of
   route objects is a proliferation of discrete route objects, it is not
   immediately apparent that this form of aggregation will prove capable
   in addressing the growth in the number of route objects.

   If single route objects are to be used that encompass a set of
   address prefixes and a collection of ASs, then it appears necessary
   to define additional attributes within the route object to further
   qualify the policies associated with the object in terms of specific
   prefixes, specific ASs and specific policy semantics that may be
   considered as policy exceptions to the overall aggregate

   Another approach to reduce the number of route objects is to reduce
   the scope of advertisement of each routing object, allowing the
   object to be removed and proxy aggregated into some larger object
   once the logical scope of the object has been reached.  This approach
   would entail the addition of route attributes that could be used to
   define the circumstances where a specific route object would be
   subsumed by an aggregate route object without impacting the policy
   objectives associated with the original set of advertisements.







Huston                       Informational                     [Page 17]

RFC 3221           Commentary on Inter-Domain Routing      December 2001


7.3  Inter-domain Traffic Engineering

   Attempting to place greater levels of detail into route objects is
   intended to address the dual role of the current BGP system as both
   an inter-domain connectivity maintenance protocol and as an implicit
   traffic engineering tool.

   In the current environment, advertisement of more specific prefixes
   with unique policy but with the same origin AS is often intended to
   create a traffic engineering response, where incoming traffic to an
   AS may be balanced across multiple paths.  The outcome is that the
   control of the relative profile of load is placed with the
   originating AS.  The way this is achieved is by using limited
   knowledge of the remote AS's route selection policy to explicitly
   limit the number of egress choices available to a remote AS.  The
   most common route selection policy is the preference for more
   specific prefixes over larger address blocks.  By advertising
   specific prefixes along specific neighbor AS connections with
   specific route attributes, traffic destined to these addresses is
   passed through the selected transit paths.  This limitation of choice
   allows the originating AS to override the potential policy choices of
   all other ASs, imposing its traffic import policies at a higher level
   than the remote AS's egress policies.

   An alternative approach is the use of a class of traffic engineering
   attributes that are attached to an aggregate route object.  The
   intent of such attributes is to direct each remote AS to respond to
   the route object in a manner that equates to the current response to
   more specific advertisements, but without the need to advertise
   specific prefix route objects.  However, even this approach uses
   route objects to communicate traffic engineering policy, and the same
   risk remains that the route table is used to carry fine-detailed
   traffic path policies.

   An alternative direction is to separate the functions of connectivity
   maintenance and traffic engineering, using the routing protocol to
   identify a number of viable paths from a source AS to a destination
   AS, and use a distinct collection of traffic engineering tools to
   allow a traffic source AS to make egress path selections that match
   the desired traffic service profile for the traffic.

   There is one critical difference between traffic engineering
   approaches as used in intra-domain environments and the current
   inter-domain operating practices.  Whereas the intra-domain
   environment uses the ingress network element to make the appropriate
   path choice to the egress point, the inter domain traffic engineering
   has the opposite intent, where a downstream AS (or egress point) is
   attempting to influence the path choice of an upstream AS (or ingress



Huston                       Informational                     [Page 18]

RFC 3221           Commentary on Inter-Domain Routing      December 2001


   point).  If explicit traffic engineering were undertaken within the
   inter-domain space, it is highly likely that the current structure
   would be altered.  Instead of the downstream element attempting to
   constrain the path choices of an upstream element, a probable
   approach is the downstream element placing a number of advisory
   constraints on the upstream elements, and the upstream elements using
   a combination of these advisory constraints, dynamic information
   relating to path service characteristics and local policies to make
   an egress choice.

   From the perspective of the inter-domain routing environment, such
   measures offer the potential to remove the advertisement of specific
   routes for traffic engineering purposes.  However, there is a need to
   adding traffic engineering information into advertised route blocks,
   requiring the definition of the syntax and semantics of traffic
   engineering attributes that can be attached to route objects.

7.4  Hierarchical Routing Models

   The CIDR routing model assumed a hierarchy of providers, where at
   each level in the hierarchy the routing policies and address space of
   networks at the lower level of hierarchy were subsumed by the next
   level up (or 'upstream') provider.  The connectivity policy assumed
   by this model is also a hierarchical model, where horizontal
   connections within a single level of the hierarchy are not visible
   beyond the networks of the two parties.