diffs to draft-ietf-idr-bgp4-03.txt

[Curtis Villamizar <[e-mail]>]

Yakov et al.

Here are some suggested changes to the BGP4 draft.  Briefly, there are
a few separable issues:

  1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)

  2.  Proposing "BGP resynchronization".  See below.

  3.  Replace descriptions of route selection with something more
      clear and accurate.

  4.  Replace some text about route overlap that is wrong and reflects
      earlier indecision on the part of the WG.

The "BGP resynchronization" warents further mention.  The idea was to
make something 100% compatible with current BGP4 implementations that
addresses the following:

  1.  Allows a better recovery if running a hosed implementation.  No
      more clearing the BGP conection.

  2.  Allows a cheap policy reconfig (maybe less desirable than a true
      dynamic reconfig) that doesn't involve clearing the BGP conection.

  3.  Reduces the impact of occasional loss of BGP connections.  Might
      even allow you to squeeze in a reload if it was real fast.

  4.  Reduces the exposure to TCP RST attacks.

Given some of the talk on the NANOG list, #4 might not be a bad
feature.  Fixing BGP to use UDP is a bigger job and this and a good
TCP PCB hashing and long listen queue for TCP SYN attack could prove
very valuable changes.

Curtis



Just apply the diffs to draft-ietf-idr-bgp4-03.txt to get the new
document.  The diff hunks are:

  1  an attempt to clear up wording regarding IBGP, EBGP, and IGP and
     the role of IBGP.

  2  First mention of BGP resynchronization

  3  I couldn't resist.  Might want to leave this one out.

  4  Add RESYNCHRONIZATION message type

  5  Define RESYNCHRONIZATION message format

  6  Clarifying sentence - path attributes are for the purpose
     of supporting a protocol extension mechanism.

  7  Added the table with discresionary, required, or disallowed, etc.

  8  Clarification of MULTI_EXIT_DISC usage.

  9  Add BGP resynchronization to Error Handling section.

 10  Allow marking routes for withdrawl on disconnect.

 11  BGP Resynchronization section

 12&13  Fixed overlap route jabber that was just plain wrong.

 14  Clarified setting LOCAL_PREF.

 16  Replaced description of route slection with one that is much more
     concise and clear and covers the route loop avoidance, including
     a brief description of the reasons loops can form.

 17  Got rid of unclear tie breaker section.

 18&19  Replaced the route overlap section with one that reflects
     reality now that we have plenty of experience with BGP4.

 20&21  Eliminated a great deal of repitition and referred back to 9.1.2.
     btw- why can't 9.2.1 be as simple as 9.2.2 - or does 9.2.2 need
     to spell things out in detail like 9.2.1?


*** draft-ietf-idr-bgp4-03.txt	Sat Aug 17 08:34:53 1996
--- draft-ietf-idr-bgp4-03.txt.new	Sat Sep 14 00:01:33 1996
***************
*** 205,230 ****
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct BGP connections
!    with each other.  Using a common set of policies, the BGP speakers
!    arrive at an agreement as to which border routers will serve as
!    exit/entry points for particular destinations outside the AS.  This
!    information is communicated to the AS's internal routers, possibly
!    via the interior routing protocol.  Care must be taken to ensure that
!    the interior routers have all been updated with transit information
!    before the BGP speakers announce to other ASs that transit service is
!    being provided.
! 
!    Connections between BGP speakers of different ASs are referred to as
!    "external" links.  BGP connections between BGP speakers within the
!    same AS are referred to as "internal" links.  Similarly, a peer in a
!    different AS is referred to as an external peer, while a peer in the
!    same AS may be described as an internal peer.
  
  
  
--- 205,231 ----
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
+    Connections between BGP speakers of different ASs are referred to as
+    "external" links.  BGP connections between BGP speakers within the
+    same AS are referred to as "internal" links.  Similarly, a peer in a
+    different AS is referred to as an external peer, while a peer in the
+    same AS may be described as an internal peer.  Internal BGP and
+    external BGP are commonly abbreviated IBGP and EBGP.
+ 
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct IBGP connections
!    with each other.  Alternately the interior routing protocol can
!    pass BGP information among routers within an AS, taking care not to
!    lose BGP attributes that will be needed by EBGP speakers if transit
!    connectivity is being providided.  For the purpose of discussion,
!    it is assumed that BGP information is passed within an AS using
!    IBGP.  Care must be taken to ensure that the interior routers have
!    all been updated with transit information before the EBGP speakers
!    announce to other ASs that transit service is being provided.
  
  
  
***************
*** 282,291 ****
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly removes from service all routes which the pair of
!       speakers had advertised to each other.
! 
! 
  
  
  
--- 283,297 ----
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly marks all routes hte pair of speakers had advertised
!       to each other for removal from service if a connection is not
!       reestablished and the routes readvertised before a resynchronization
!       completed message or before a configured expiration timer elapses.
! 
!       d) the BGP speaker or listenner may request a resynchronization
!       which explicitly marks all routes for removal from service if not
!       readvertised before a resynchronization completed message or before
!       a configured expiration timer elapses.
  
  
  
***************
*** 333,339 ****
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.
  
  4.  Message Formats
  
--- 339,346 ----
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.  And in fact you'd be pretty stupid to maintain separate
!    copies though it has been tried.
  
  4.  Message Formats
  
***************
*** 435,440 ****
--- 442,448 ----
                                      2 - UPDATE
                                      3 - NOTIFICATION
                                      4 - KEEPALIVE
+ 				    5 - RESYNCHRONIZATION
  
  
  4.2 OPEN Message Format
***************
*** 1127,1135 ****
--- 1135,1182 ----
  
  
  
+ 4.5 RESYNCHRONIZATION Message Format
+ 
+ 
+    A RESYNCHRONIZATION message is sent when there is reason to believe
+    that routing information in either the speaker of the listenner is
+    not correct or routing policy has been changed and the speaker is
+    unable to process the routing policy change without readvertising
+    the full set of routes.  A RESYNCHRONIZATION message should never
+    be required except where a policy change has occurred or unless
+    either the speaker of listenner implementation is in error.
+ 
+ 
+    In addition to the fixed-size BGP header, the RESYNCHRONIZATION
+    message contains the following fields:
+ 
+ 
+         0                   1                   2                   3
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        | Request Type  | Reserved      |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
  
  
+       Request Type:
+ 
+          This 1-octet unsigned integer indicates the type of
+          RESYNCHRONIZATION request.  The following Request Codes have
+          been defined:
+ 
+             Request Code     Symbolic Name               Reference
+ 
+               1         Sender Resynchronizing Request   Section 6.9
+ 
+               2         Receiver Resynchronize Request   Section 6.9
+ 
+               3         Resynchronizion Completed        Section 6.9
+ 
+ The length of the RESYNCHRONIZATION message is 21 octets (including
+ message header).
+ 
+ 
  
  Expiration Date February 1996                                  [Page 19]
  
***************
*** 1145,1151 ****
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
--- 1192,1199 ----
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories for the purpose
!    of supporting a protocol extension mechanism:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
***************
*** 1208,1213 ****
--- 1256,1275 ----
     The same attribute cannot appear more than once within the Path
     Attributes field of a particular UPDATE message.
  
+    The manditory category refers to a field which must be present in
+    both IBGP and EBGP exchanges.  Attributes classified as optional
+    for the purpose of the protocol extension mechanism may be purely
+    discresionary, or discresionary, required, or disallowed in certain
+    contexts.
+ 
+       attribute           EBGP                    IBGP
+        ORIGIN             manditory               manditory
+        AS_PATH            manditory               manditory
+        NEXT_HOP           discresionary           discresionary
+        MULTI_EXIT_DISC    discresionary           discresionary
+        LOCAL_PREF         disallowed              required
+        ATOMIC_AGGREGATE   discresionary           discresionary
+        AGGREGATOR         discresionary           discresionary
  
  
  5.1 Path Attribute Usage
***************
*** 1342,1348 ****
     preferred.  If received over external links, the MULTI_EXIT_DISC
     attribute may be propagated over internal links to other BGP speakers
     within the same AS.  The MULTI_EXIT_DISC attribute is never
!    propagated to other BGP speakers in neighboring AS's.
  
  
  5.1.5   LOCAL_PREF
--- 1404,1410 ----
     preferred.  If received over external links, the MULTI_EXIT_DISC
     attribute may be propagated over internal links to other BGP speakers
     within the same AS.  The MULTI_EXIT_DISC attribute is never
!    propagated from IBGP to other BGP speakers in neighboring AS's.
  
  
  5.1.5   LOCAL_PREF
***************
*** 1411,1423 ****
     attribute which shall contain its own AS number and IP address.
  
  
! 6.  BGP Error Handling.
  
  
     This section describes actions to be taken when errors are detected
!    while processing BGP messages.
  
!    When any of the conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
--- 1473,1485 ----
     attribute which shall contain its own AS number and IP address.
  
  
! 6.  BGP Error and Resynchronization Handling.
  
  
     This section describes actions to be taken when errors are detected
!    while processing BGP messages or during resynchronization.
  
!    When any erro conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
***************
*** 1425,1431 ****
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are marked as invalid.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
--- 1487,1494 ----
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are either marked as invalid or
!    optionally marked as if a resynchronization had occurred.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
***************
*** 1754,1759 ****
--- 1817,1888 ----
        message with the Error Code Cease.
  
  
+ 6.9 BGP Resynchronization
+ 
+ 
+    BGP implementation may optionally support a form of graceful
+    resynchronization rather than closing the BGP connection in certain
+    conditions and may optionally allow resynchronization rather than
+    immediate route withdrawl when a BGP connection is closed.  BGP
+    implementation which support resynchronization must be prepared to
+    detect and interoperate with implementations which do not.
+ 
+    A resynchronization request will generally be made in response to
+    operator intervention.  A resynchronization request can also be
+    made when conditions indicate internal inconsistency, such as
+    failure of a coded assertion.  Implementations which require
+    resynchronization should be considered in error, however the BGP
+    protocol accomodates the possibility that errant implementation may
+    exist (transiently) and provides resynchronization as a means to
+    restore operational integrity with minimal disruption.
+ 
+    After sending a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or receiving a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the sender must empty the associated Adj-RIBs-Out
+    and readvertise all route in its Loc-RIB to its peer as described
+    in section 9.1.3, as if no routes had ever been advertised to that
+    peer.
+ 
+    After receiving a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or sending a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the receiver must mark all entries in the Loc-RIB
+    for removal and empty the Adj-RIBs-In.  As the Adj-RIBs-In is
+    repopulated the marks in the associated Loc-RIB entires are
+    removed.  After a configured expiration timer has elapsed or a
+    RESYNCHRONIZATION message with a Resynchronizion Completed (Request
+    Code 3) is received, all entries in the Loc-RIB still marked are
+    removed as it they had been withdrawn.
+ 
+    Optionally when a BGP connection is closed the Loc-RIB entries may
+    be treated in the same way they would be when receiving a
+    RESYNCHRONIZATION message with a Sender Resynchronizing Request.
+    It should be possible to configure a different expiration timer
+    value for this condition or disable it entirely.
+ 
+    Optionally a BGP speaker may send a RESYNCHRONIZATION message with
+    a Resynchronizion Completed after a connection has been
+    established, in effect treating the entry to the established state
+    as an implied RESYNCHRONIZATION message with a Receiver Resynchronize 
+    Request from the peer.
+ 
+    An implementation which does not support BGP Resynchronization must
+    send a NOTIFICATION with a Message Header Error (Error Code 1) and a
+    Bad Message Type (Error subcode 3).  
+ 
+    An implementation which does support BGP Resynchronization must
+    have the ability to configure a peer as not supporting BGP
+    Resynchronization and not send any form of RESYNCHRONIZATION
+    message to such a peer.  It must also be able to record the fact
+    that a peer has sent a NOTIFICATION in response to a
+    RESYNCHRONIZATION message and disable sending any further
+    RESYNCHRONIZATION messages to that peer, even after the BGP
+    connection if broken and reestablished, unless that peer later
+    sends a RESYNCHRONIZATION message (which would be interpretted as a
+    code update adding support for BGP Resynchronization).
+ 
+ 
  7.  BGP Version Negotiation.
  
  
***************
*** 2085,2095 ****
     shall run its Decision Process since the older route is no longer
     available for use.
  
-    ii) If the new route is an overlapping route that is included (see
-    9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP
-    speaker shall run its Decision Process since the more specific route
- 
- 
  
  Expiration Date February 1996                                  [Page 35]
  
--- 2214,2219 ----
***************
*** 2100,2121 ****
  INTERNET DRAFT                                               August 1996
  
  
!    has implicitly made a portion of the less specific route unavailable
!    for use.
! 
!    iii) If the new route has identical path attributes to an earlier
!    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
!    than the earlier route, no further actions are necessary.
! 
!    iv) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, then the new route shall
!    be placed in the Adj-RIB-In. The BGP speaker shall run its Decision
!    Process.
! 
!    v) If the new route is an overlapping route that is less specific
!    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
!    BGP speaker shall run its Decision Process on the set of destinations
!    described only by the less specific route.
  
  
  9.1 Decision Process
--- 2224,2235 ----
  INTERNET DRAFT                                               August 1996
  
  
!    ii) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, regardless of whether
!    the new route overlaps an earlier route contained in the Adj-RIB-In
!    that is either more specific or less specific (see 9.1.4), then the
!    new route shall be placed in the Adj-RIB-In. The BGP speaker shall
!    run its Decision Process.
  
  
  9.1 Decision Process
***************
*** 2199,2213 ****
     operating on all new or unfeasible routes contained within it.
  
     For each newly received or replacement feasible route, the local BGP
!    speaker shall determine a degree of preference. If the route is
!    learned from a BGP speaker in the local autonomous system, either the
     value of the LOCAL_PREF attribute shall be taken as the degree of
!    preference, or the local system shall compute the degree of
!    preference of the route based on preconfigured policy information. If
!    the route is learned from a BGP speaker in a neighboring autonomous
!    system, then the degree of preference shall be computed based on
!    preconfigured policy information.  The exact nature of this policy
!    information and the computation involved is a local matter.  The
  
  
  
--- 2313,2327 ----
     operating on all new or unfeasible routes contained within it.
  
     For each newly received or replacement feasible route, the local BGP
!    speaker shall determine a degree of preference.  If the route is
!    learned from a BGP speaker in the local autonomous system, the
     value of the LOCAL_PREF attribute shall be taken as the degree of
!    preference.  If the route is learned from a BGP speaker in a
!    neighboring autonomous system, then the degree of preference shall
!    be computed based on preconfigured policy information and used as
!    the LOCAL_PREF value in any IBGP readvertisement.  The exact nature
!    of this policy information and the computation involved is a local
!    matter.  The 
  
  
  
***************
*** 2243,2259 ****
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!    For each set of destinations for which a feasible route exists in the
!    Adj-RIBs-In, the local BGP speaker shall identify the route that has:
! 
!       a) the highest degree of preference of any route to the same set
!       of destinations, or
! 
!       b) is the only route to that destination, or
! 
!       c) is selected as a result of the Phase 2 tie breaking rules
!       specified in 9.1.2.1.
! 
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
--- 2357,2416 ----
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!   It is critical that routers within an AS do not make conflicting
!   decisions regarding route selection that would cause forwarding
!   loops to occur (routers pointing traffic as each other or in a
!   cycle).  BGP speakers will consider the following attributes in
!   determining preference and will consider no others.
! 
!        1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
!            not provided, the advertising router must be reachable)
! 
!        1.  LOCAL_PREF.
! 
!        2.  MULTI_EXIT_DISC.  This comparison is applicable only when
!            comparing MULTI_EXIT_DISC received from the same
!            neighboring AS, including those received from the same
!            neighboring AS and passed via IBGP.
! 
!        3.  Internal routing protocol cost.  Lower costs are preferred.
!            Select the route that has the lowest cost (interior
!            distance) to the entity depicted by the NEXT_HOP attribute
!            of the route.
! 
!        4.  Advertising router BGP Identifier.  If at least one of the
!            candidate routes was advertised by the BGP speaker in a
!            neighboring autonomous system, select the route that was
!            advertised by the BGP speaker in a neighboring autonomous
!            system whose BGP Identifier has the lowest value among all
!            other BGP speakers in neighboring autonomous systems.
!            Otherwise, select the route that was advertised by the BGP
!            speaker whose BGP Identifier has the lowest value.
! 
!   The MULTI_EXIT_DISC may be dropped when passing a route via IBGP.
!   To prevent routing loops a route with a MULTI_EXIT_DISC (if the
!   routes and received from the same neighboring AS and therefore the
!   comparison is applicable) is preferred over one without.
! 
!   The outcome of a comparison must be independent of the order in
!   which routes are placed in the Adj-Rib-In and Local-Rib.  Due to
!   difference in the backlog of propogated routes among IBGP peers, the
!   same set of routes may arrive in different orders on differnt
!   routers.  If routes are compared in arbitrary order, under certain
!   conditions routing loops can occur.  This is a consequence of the
!   use of MULTI_EXIT_DISC in comparing routes received from the same
!   neighboring AS but not considering MULTI_EXIT_DISC when comparing
!   routes received from differing neighboring AS.
! 
!   The comparison algorithm must insure a deterministic decision
!   outcome.  To accomplish this, routes are compared in a constrained
!   order.  First all routes are checked for feasibility, insuring that
!   the NEXT_HOP is reachable.  All routes from the same neighboring AS
!   are first compared using the criteria above, LOCAL_PREF,
!   MULTI_EXIT_DISC, internal routing protocol cost, and Advertising
!   router IP address.  Then the best route selected from each
!   neighboring AS are compared using the criteria, LOCAL_PREF, internal
!   routing protocol cost, and Advertising router BGP Identifier.
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
***************
*** 2280,2325 ****
  INTERNET DRAFT                                               August 1996
  
  
!    RIBs-In.
! 
! 
! 9.1.2.1 Breaking Ties (Phase 2)
! 
! 
!    In its Adj-RIBs-In a BGP speaker may have several routes to the same
!    destination that have the same degree of preference. The local
!    speaker can select only one of these routes for inclusion in the
!    associated Loc-RIB. The local speaker considers all equally
!    preferable routes, both those received from BGP speakers located in
!    neighboring autonomous systems, and those received from other BGP
!    speakers located in the local speaker's autonomous system.
! 
!    The following tie-breaking procedure assumes that for each candidate
!    route all the BGP speakers within an autonomous system can ascertain
!    the cost of a path (interior distance) to the address depicted by the
!    NEXT_HOP attribute of the route.  Ties shall be broken according to
!    the following algorithm:
! 
!       a) If the local system is configured to take into account
!       MULTI_EXIT_DISC, and the candidate routes differ in their
!       MULTI_EXIT_DISC attribute, select the route that has the lowest
!       value of the MULTI_EXIT_DISC attribute.  A route with
!       MULTI_EXIT_DISC shall be preferred to a route without
!       MULTI_EXIT_DIST.
! 
!       b) Otherwise, select the route that has the lowest cost (interior
!       distance) to the entity depicted by the NEXT_HOP attribute of the
!       route.  If there are several routes with the same cost, then the
!       tie-breaking shall be broken as follows:
! 
!          - if at least one of the candidate routes was advertised by the
!          BGP speaker in a neighboring autonomous system, select the
!          route that was advertised by the BGP speaker in a neighboring
!          autonomous system whose BGP Identifier has the lowest value
!          among all other BGP speakers in neighboring autonomous systems;
! 
!          - otherwise, select the route that was advertised by the BGP
!          speaker whose BGP Identifier has the lowest value.
  
  
  9.1.3   Phase 3: Route Dissemination
--- 2437,2443 ----
  INTERNET DRAFT                                               August 1996
  
  
!    RIB-In.
  
  
  9.1.3   Phase 3: Route Dissemination
***************
*** 2425,2451 ****
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall take into account the semantics of the overlapping routes. In
!    particular, if a BGP speaker accepts the less specific route while
!    rejecting the more specific route from the same peer, then the
!    destinations represented by the overlap may not forward along the ASs
!    listed in the AS_PATH attribute of that route. Therefore, a BGP
!    speaker has the following choices:
! 
!       a)   Install both the less and the more specific routes
! 
!       b)   Install the more specific route only
! 
!       c)   Install the non-overlapping part of the less specific
!                  route only (that implies de-aggregation)
! 
!       d)   Aggregate the two routes and install the aggregated route
! 
!       e)   Install the less specific route only
! 
!       f)   Install neither route
  
!    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
--- 2543,2554 ----
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall consider both routes based on configured acceptance policy.
!    If both are accepted the Decision Process will install both the
!    less and the more specific routes or aggregate the two routes and
!    install the aggregated route.
  
!    If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
***************
*** 2462,2470 ****
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
!    it must not advertise the more general route without the more
!    specific route.
  
  
  9.2 Update-Send Process
--- 2565,2573 ----
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses to
!    install both routes it must not advertise the more general route
!    without the more specific route.
  
  
  9.2 Update-Send Process
***************
*** 2500,2531 ****
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if any of the following conditions occur:
! 
!       1) the degree of preference assigned to the newly received route
!       by the local BGP speaker is higher than the degree of preference
!       that the local speaker has assigned to other routes that have been
!       received from BGP speakers in neighboring autonomous systems, or
! 
!       2) there are no other routes that have been received from BGP
! 
! 
! 
! Expiration Date February 1996                                  [Page 42]
! 
! 
! 
! 
! 
! INTERNET DRAFT                                               August 1996
! 
! 
!       speakers in neighboring autonomous systems, or
! 
!       3) the newly received route is selected as a result of breaking a
!       tie between several routes which have the highest degree of
!       preference, and the same destination (the tie-breaking procedure
!       is specified in 9.2.1.1).
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
--- 2603,2610 ----
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if this route has become the best route installed in the
!    Local-Rib according to the route selection rules in 9.1.2.
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
***************
*** 2554,2598 ****
     All feasible routes which are advertised shall be placed in the
     appropriate Adj-RIBs-Out, and all unfeasible routes which are
     advertised shall be removed from the Adj-RIBs-Out.
- 
- 
- 9.2.1.1 Breaking Ties (Internal Updates)
- 
- 
-    If a local BGP speaker has connections to several BGP speakers in
-    neighboring autonomous systems, there will be multiple Adj-RIBs-In
-    associated with these peers. These Adj-RIBs-In might contain several
-    equally preferable routes to the same destination, all of which were
-    advertised by BGP speakers located in neighboring autonomous systems.
-    The local BGP speaker shall select one of these routes according to
-    the following rules:
- 
-       a) If the candidate routes differ only in their NEXT_HOP and
- 
- 
- 
- Expiration Date February 1996                                  [Page 43]
- 
- 
- 
- 
- 
- INTERNET DRAFT                                               August 1996
- 
- 
-       MULTI_EXIT_DISC attributes, and the local system is configured to
-       take into account the MULTI_EXIT_DISC attribute, select the route
-       that has the lowest value of the MULTI_EXIT_DISC attribute. A
-       route with the MULTI_EXIT_DISC attribute shall be preferred to a
-       route without the MULTI_EXIT_DISC attribute.
- 
-       b) If the local system can ascertain the cost of a path to the
-       entity depicted by the NEXT_HOP attribute of the candidate route,
-       select the route with the lowest cost.
- 
-       c) In all other cases, select the route that was advertised by the
-       BGP speaker whose BGP Identifier has the lowest value.
- 
  
  
  9.2.2 External Updates
--- 2633,2638 ----