Draft changes

[Tony Li <[e-mail]>]

*** bgp.ms	1996/10/17 04:42:49	1.1
--- bgp.ms	1996/10/17 07:19:29
***************
*** 51,57 ****
  .sp
  .in 0
  .ne 4
! 1. Acknowledgements
  .sp
  .in 3
  This document was originally published as RFC 1267 in October 1991,
--- 51,57 ----
  .sp
  .in 0
  .ne 4
! 1. Acknowledgments
  .sp
  .in 3
  This document was originally published as RFC 1267 in October 1991,
***************
*** 132,138 ****
   
  BGP runs over a reliable transport protocol.  This eliminates the
  need to implement explicit update fragmentation, retransmission,
! acknowledgement, and sequencing.  Any authentication scheme used by
  the transport protocol may be used in addition to BGP's own
  authentication mechanisms.  The error notification mechanism used in
  BGP assumes that the transport protocol supports a "graceful" close,
--- 132,138 ----
   
  BGP runs over a reliable transport protocol.  This eliminates the
  need to implement explicit update fragmentation, retransmission,
! acknowledgment, and sequencing.  Any authentication scheme used by
  the transport protocol may be used in addition to BGP's own
  authentication mechanisms.  The error notification mechanism used in
  BGP assumes that the transport protocol supports a "graceful" close,
***************
*** 207,213 ****
  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
--- 207,213 ----
  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 provided.  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
***************
*** 824,830 ****
  e) LOCAL_PREF (Type Code 5):
  .in 12
   
! LOCAL_PREF is a well-known discretionary attribute that is
  a four octet non-negative integer. It is used by a BGP speaker
  to inform other internal peers 
  of the originating speaker's degree of preference for an
--- 824,830 ----
  e) LOCAL_PREF (Type Code 5):
  .in 12
   
! LOCAL_PREF is a well-known mandatory attribute that is
  a four octet non-negative integer. It is used by a BGP speaker
  to inform other internal peers 
  of the originating speaker's degree of preference for an
***************
*** 1121,1127 ****
  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
  discretionary, or discretionary, required, or disallowed in certain
--- 1121,1127 ----
  The same attribute cannot appear more than once within the Path
  Attributes field of a particular UPDATE message.
  
! The mandatory 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
  discretionary, or discretionary, required, or disallowed in certain
***************
*** 1133,1139 ****
        NEXT_HOP           mandatory               mandatory
        MULTI_EXIT_DISC    discretionary           discretionary
        LOCAL_PREF         disallowed              required
!       ATOMIC_AGGREGATE   discretionary           discretionary
        AGGREGATOR         discretionary           discretionary
  
  
--- 1133,1139 ----
        NEXT_HOP           mandatory               mandatory
        MULTI_EXIT_DISC    discretionary           discretionary
        LOCAL_PREF         disallowed              required
!       ATOMIC_AGGREGATE   see section 5.1.6 and 9.1.4
        AGGREGATOR         discretionary           discretionary
  
  
***************
*** 1240,1246 ****
  shares a common subnet with the NEXT_HOP address.  This is a second
  form of "third party" NEXT_HOP attribute.
  
! Normally the NEXT_HOP attribute is choosen such that the shortest
  available path will be taken.  A BGP speaker must be able to support
  disabling advertisement of third party NEXT_HOP attributes to handle
  imperfectly bridged media.
--- 1240,1246 ----
  shares a common subnet with the NEXT_HOP address.  This is a second
  form of "third party" NEXT_HOP attribute.
  
! Normally the NEXT_HOP attribute is chosen such that the shortest
  available path will be taken.  A BGP speaker must be able to support
  disabling advertisement of third party NEXT_HOP attributes to handle
  imperfectly bridged media.
***************
*** 1269,1277 ****
  is a four octet unsigned number which is called a metric.  All other
  factors being equal, the exit or entry point with lower metric
  should be 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 received
! from an internal peer shall never be propagated to external peers.
   
  .sp
  .in 0
--- 1269,1288 ----
  is a four octet unsigned number which is called a metric.  All other
  factors being equal, the exit or entry point with lower metric
  should be 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 received
! from a neighboring AS MUST NOT be propagated to other neighboring ASs.
!  
! A BGP speaker MUST IMPLEMENT a mechanism based on local configuration which
! allows the MULTI_EXIT_DISC attribute to be removed from a route.  This MAY
! be done either prior to or after determining the degree of preference of
! the route and performing route selection (decision process phases 1 and 2).
! 
! An implementation MAY also (based on local configuration) alter the
! value of the MULTI_EXIT_DISC attribute received over an external link.
! If it does so, it shall do so prior to determining the degree of
! preference of the route and performing route selection (decision
! process phases 1 and 2).
  
  .sp
  .in 0
***************
*** 1280,1297 ****
  .sp
  .in 3
   
! LOCAL_PREF is a well-known discretionary attribute that shall be
  included in all UPDATE messages that a given BGP speaker sends to the
  other internal peers. A BGP
! speaker shall calculate the degree of preference for each external
  route and include the degree of preference when advertising a route
! to its internal peers. The higher degree of preference should be
  preferred. A BGP speaker shall use the degree of preference learned
  via LOCAL_PREF in its decision process (see section 9.1.1).
   
! A BGP speaker shall not include this attribute in UPDATE messages that
  it sends to external peers.  If it is contained in an UPDATE message
! that is received from an external peer, then this attribute shall be
  ignored by the receiving speaker.
   
  .sp
--- 1291,1308 ----
  .sp
  .in 3
   
! LOCAL_PREF is a well-known mandatory attribute that SHALL be
  included in all UPDATE messages that a given BGP speaker sends to the
  other internal peers. A BGP
! speaker SHALL calculate the degree of preference for each external
  route and include the degree of preference when advertising a route
! to its internal peers. The higher degree of preference MUST be
  preferred. A BGP speaker shall use the degree of preference learned
  via LOCAL_PREF in its decision process (see section 9.1.1).
   
! A BGP speaker MUST NOT include this attribute in UPDATE messages that
  it sends to external peers.  If it is contained in an UPDATE message
! that is received from an external peer, then this attribute MUST be
  ignored by the receiving speaker.
   
  .sp
***************
*** 1304,1316 ****
  ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
  speaker, when presented with a set of overlapping routes from one of
  its peers (see 9.1.4), selects the less specific route without
! selecting the more specific one, then the local system shall attach
  the ATOMIC_AGGREGATE attribute to the route when propagating it to
  other BGP speakers (if that attribute is not already present in the
  received less specific route). A BGP speaker that receives a route
! with the ATOMIC_AGGREGATE attribute shall not remove the attribute
  from the route when propagating it to other speakers. A BGP speaker
! that receives a route with the ATOMIC_AGGREGATE attribute shall not
  make any NLRI of that route more specific (as defined in 9.1.4) when
  advertising this route to other BGP speakers.  A BGP speaker that
  receives a route with the ATOMIC_AGGREGATE attribute needs to be
--- 1315,1327 ----
  ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
  speaker, when presented with a set of overlapping routes from one of
  its peers (see 9.1.4), selects the less specific route without
! selecting the more specific one, then the local system MUST attach
  the ATOMIC_AGGREGATE attribute to the route when propagating it to
  other BGP speakers (if that attribute is not already present in the
  received less specific route). A BGP speaker that receives a route
! with the ATOMIC_AGGREGATE attribute MUST NOT remove the attribute
  from the route when propagating it to other speakers. A BGP speaker
! that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT
  make any NLRI of that route more specific (as defined in 9.1.4) when
  advertising this route to other BGP speakers.  A BGP speaker that
  receives a route with the ATOMIC_AGGREGATE attribute needs to be
***************
*** 2122,2160 ****
  .sp
  .in 3
   
! 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 internal peers, and those received from
! external peers.
   
  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:
   
! .in 6
! 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:
   
! .in 9
! - if at least one of the candidate routes was advertised by the external peer,
! select the route that was advertised by the
! external peer whose BGP Identifier has
! the lowest value among all other external peers;
   
! - otherwise, select the route that was advertised by the BGP speaker
! whose BGP Identifier has the lowest value.
   
  .sp
  .in 0
--- 2133,2211 ----
  .sp
  .in 3
   
! 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 routes with the same degrees of
! preference, both those received from internal peers, and those received
! from external peers.
  
  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.
   
! The tie-breaking algorithm begins by considering all equally preferable
! routes and then selects routes to be removed from consideration.  The
! algorithm terminates as soon as only one route remains in consideration.
! The criteria must be applied in the order specified.
! 
! Several of the criteria are described using pseudo-code.  Note that
! the pseudo-code shown was chosen for clarity, not efficiency.  It
! is not intended to specify any particular implementation.  BGP
! implementations MAY use any algorithm which produces the same
! results as those described here.
! 
! .in 6
! a) Remove from consideration routes with less-preferred MULTI_EXIT_DISC
! attributes.  MULTI_EXIT_DISC is only comparable between routes learned from
! the same neighboring AS.  Routes which do not have the MULTI_EXIT_DISC
! attribute are considered to have the highest possible MULTI_EXIT_DISC
! value.
  
! This is also described in the following procedure:
  
! .nf
!       for m = all routes still under consideration
!           for n = all routes still under consideration
!               if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
!                   remove route m from consideration
! .fi
! 
! In the pseudo-code above, MED(n) is a function which returns
! the value of route n's MULTI_EXIT_DISC attribute.  If route n
! has no MULTI_EXIT_DISC attribute, the function returns the
! highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.
! 
! Similarly, neighborAS(n) is a function which returns the
! neighbor AS from which the route was received.
! 
! b) Remove from consideration any routes with less-preferred interior cost.
! The interior cost of a route is determined by calculating the metric to the
! next hop for the route using the interior routing protocol(s).  If the next
! hop for a route is reachable, but no cost can be determined, then this step
! should be should be skipped (equivalently, consider all routes to have
! equal costs).
! 
! This is also described in the following procedure.  
! 
! .nf
!       for m = all routes still under consideration
!           for n = all routes in still under consideration
!               if (cost(n) is better than cost(m))
!                   remove m from consideration
! .fi
! 
! In the pseudo-code above, cost(n) is a function which returns the cost of
! the path (interior distance) to the address given in the NEXT_HOP attribute
! of the route.
! 
! c) If at least one of the candidate routes was received from an external
! peer in a neighboring autonomous system, remove from consideration all
! routes which were received from internal peers.
  
! d) Remove from consideration all routes other than the route that was
! advertised by the BGP speaker whose BGP Identifier has the lowest value.
  
  .sp
  .in 0
***************
*** 2248,2277 ****
  described by the overlap will still be reachable using 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:
   
! .in 6
! 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
!  
! .in 3
! If a BGP speaker chooses e), then it shall 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
  can not be made more specific.  Forwarding along
--- 2299,2311 ----
  described by the overlap will still be reachable using the less specific
  route.
   
! If a BGP speaker receives overlapping routes, the Decision Process MUST
! consider both routes based on the configured acceptance policy.  If both a
! less and a more specific route are accepted, then the Decision Process MUST
! either install both the less and the more specific routes or it MUST
! aggregate the two routes and install the aggregated route.
  
! If a BGP speaker chooses to aggregate, then it MUST 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
  can not be made more specific.  Forwarding along
***************
*** 2316,2338 ****
  message to other internal peers.
   
  When a BGP speaker receives a new route from an external peer,
! it shall advertise that route to
  all other internal peers by means of an UPDATE
! message if any of the following conditions occur:
!  
! .in 6
! 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 external peers, or
!  
! 2) there are no other routes that have been received from 
! external peers, 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).
   
  .in 3
  When a BGP speaker receives an UPDATE message with a non-empty
--- 2350,2359 ----
  message to other internal peers.
   
  When a BGP speaker receives a new route from an external peer,
! it MUST advertise that route to
  all other internal peers by means of an UPDATE
! message if this routes has been installed in its Loc-RIB according to the
! route selection rules in 9.1.2.
  
  .in 3
  When a BGP speaker receives an UPDATE message with a non-empty
***************
*** 3046,3052 ****
   
  To avoid excessive route flapping a BGP speaker which needs to
  withdraw a destination and send an update about a more specific
! or less specific route shall combine them into the same UPDATE
  message.
   
  .sp
--- 3067,3073 ----
   
  To avoid excessive route flapping a BGP speaker which needs to
  withdraw a destination and send an update about a more specific
! or less specific route SHOULD combine them into the same UPDATE
  message.
   
  .sp
***************
*** 3223,3229 ****
  3260 Jay St.
  Santa Clara, CA 95051
  [phone]
! email: [e-mail]
  .fi
  .sp
  
--- 3244,3250 ----
  3260 Jay St.
  Santa Clara, CA 95051
  [phone]
! email: [e-mail]
  .fi
  .sp