--- 1/draft-ietf-idr-bgp4-21.txt 2006-02-04 23:30:23.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-22.txt 2006-02-04 23:30:23.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Y. Rekhter INTERNET DRAFT Juniper Networks T. Li Procket Networks, Inc. S. Hares NextHop Technologies, Inc. Editors A Border Gateway Protocol 4 (BGP-4) - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. @@ -143,21 +143,21 @@ Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 92 Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 92 Appendix F.5 Control over version negotiation . . . . . . . . . . 93 Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 93 Security Considerations . . . . . . . . . . . . . . . . . . . . . 94 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 94 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Full Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 95 Normative References . . . . . . . . . . . . . . . . . . . . . . 96 Non-normative References . . . . . . . . . . . . . . . . . . . . 96 - Authors Information . . . . . . . . . . . . . . . . . . . . . . . 97 + Authors Information . . . . . . . . . . . . . . . . . . . . . . . 98 Abstract The Border Gateway Protocol (BGP) is an inter-Autonomous System rout- ing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reacha- bility information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This informa- @@ -218,21 +218,21 @@ A router that implements BGP. EBGP External BGP (BGP connection between external peers). External peer Peer that is in a different Autonomous System than the local sys- tem. Feasible route - A route that is available for use. + An advertised route that is available for use by the recipient. IBGP Internal BGP (BGP connection between internal peers). Internal peer Peer that is in the same Autonomous System as the local system. IGP Interior Gateway Protocol - a routing protocol used to exchange routing information among routers within a single Autonomous Sys- @@ -1059,24 +1059,24 @@ 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. 3. Optional transitive. 4. Optional non-transitive. - BGP implementations MUST recognize all well-known attrbutes. Some of - these attributes are mandatory and MUST be included in every UPDATE - message that contains NLRI. Others are discretionary and MAY or MAY - NOT be sent in a particular UPDATE message. + BGP implementations MUST recognize all well-known attributes. Some + of these attributes are mandatory and MUST be included in every + UPDATE message that contains NLRI. Others are discretionary and MAY + or MAY NOT be sent in a particular UPDATE message. Once a BGP peer has updated any well-known attributes, it MUST pass these attributes in any updates it transmits to its peers. In addition to well-known attributes, each path MAY contain one or more optional attributes. It is not required or expected that all BGP implementations support all optional attributes. The handling of an unrecognized optional attribute is determined by the setting of the Transitive bit in the attribute flags octet. Paths with unrecognized transitive optional attributes SHOULD be accepted. If a path with @@ -1711,21 +1711,21 @@ 7) DelayOpenTime 8) DelayOpenTimer 9) IdleHoldTime 10) IdleHoldTimer 11) PassiveTcpEstablishment 12) SendNOTIFICATIONwithoutOPEN 13) TrackTcpState The optional session attributes support different features of the BGP functionality that have implications for the BGP FSM state - transitions. Two groups of the attributes relate to timers are: + transitions. Two groups of the attributes which relate to timers are: group 1: DelayOpen, DelayOpenTime, DelayOpenTimer group 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer The first parameter (DelayOpen, DampPeerOscillations) is an optional attribute that indicates that the Timer function is active. The "Time" value specifies the initial value for "Timer" (DelayOpenTime, IdleHoldTime). The "Timer" specifies the actual timer. Please refer to section 8.1.1 for an explanation of the interaction between these optional attributes and the events @@ -1810,31 +1810,31 @@ Description: The DampPeerOscillations optional session attribute indicates that this BGP connection is using logic that damps BGP peer oscillations in the Idle State. Value: TRUE or FALSE Option 4: IdleHoldTime - Description: The IdleHoldTime is a the value + Description: The IdleHoldTime is the value that is set in the IdleHoldtimer. Values: Time in seconds Option 5: IdleHoldTimer Description: The IdleHoldTimer aids in controlling BGP peer oscillation. The IdleHoldTimer is used to keep the BGP peer in Idle for a particular duration. - The IdleHoldTimer expired event is described + The IdleHoldTimer_Expires event is described in section 8.1.3. Values: Time in seconds Group 2: Unconfigured Peers Optional Session Attributes: AcceptConnectionsUnconfiguredPeers Option 1: AcceptConnectionsUnconfiguredPeers @@ -1873,29 +1873,30 @@ Optionally, the BGP FSM can support additional interaction with the TCP connection negotiation. The interaction with the TCP events may increase the amount of logging the BGP peer connection requires and the number of BGP FSM changes. Value: TRUE or FALSE Group 4: BGP Message Processing - Optional Session Attributes: DelayOpen, DelayOpenTimer, + Optional Session Attributes: DelayOpen, DelayOpenTime, + DelayOpenTimer, SendNOTIFICATIONwithoutOPEN, CollisionDetectEstablishedState Option 1: DelayOpen Description: The DelayOpen optional session attribute allows implementations to be configured to delay - sending an OPEN message for specific time + sending an OPEN message for a specific time period (DelayOpenTime). The delay allows the remote BGP Peer time to send the first OPEN message. Value: TRUE or FALSE Option 2: DelayOpenTime Description: The DelayOpenTime is the initial value that is set in the DelayOpenTimer. @@ -1905,35 +1906,35 @@ Option 3: DelayOpenTimer Description: The DelayOpenTimer optional session attribute specifies a time that the local system will wait prior to sending an OPEN message on the connection. Value: Time in seconds Option 4: SendNOTIFICATIONwithoutOPEN - Description: The SendNOTIFICIATONwithoutOPEN allows a peer to + Description: The SendNOTIFICATIONwithoutOPEN allows a peer to send a NOTIFICATION without first sending an OPEN message. Without this optional session attribute, the BGP connection assumes that an OPEN message must be sent by a peer prior to the peer sending a NOTIFICATION message. Value: True or False Option 5: CollisionDetectEstablishedState Description: Normally, a Detect Collision (6.8) will be ignored in the Established state. This optional session attribute indicates that - this BGP connection processes a + this BGP connection processes collisions in the Established state. Value: True or False Note: The optional session attributes clarify the BGP FSM description for existing features of BGP implementations. The optional session attributes may be pre-defined for an implementation and not readable via management interfaces for existing correct implementations. As newer BGP MIBs (version 2 and beyond) are supported, these fields will be accessible @@ -1995,30 +1995,30 @@ Event3: AutomaticStart Definition: Local system automatically starts the BGP connection. Status: Optional, depending on local system Optional Attribute Status: 1) The AllowAutomaticStart attribute SHOULD be set - if this event occurs. + to TRUE if this event occurs. 2) If the PassiveTcpEstablishment optional session attribute is supported, it SHOULD be set to FALSE. 3) If the DampPeerOscillations is supported, it SHOULD be set to FALSE when this event occurs. Event4: ManualStart_with_PassiveTcpEstablishment - Definition: Local system administrator manually starts the peer - connection, but has the PassiveTcpEstablishment + Definition: Local system administrator manually starts peer + connection, but has PassiveTcpEstablishment enabled. The PassiveTcpEstablishment optional attribute indicates that the peer will listen prior to establishing the connection. Status: Optional, depending on local system Optional Attribute Status: 1) The PassiveTcpEstablishment attribute SHOULD be set to TRUE if this event occurs. @@ -2100,21 +2101,21 @@ Status: Optional, depending on local system Optional Attribute Status: 1) The AllowAutomaticStop attribute SHOULD be TRUE 8.1.3 Timer Events - Event9: ConnectRetryTime_Expires + Event9: ConnectRetryTimer_Expires Definition: An event generated when the ConnectRetryTimer expires. Status: Mandatory Event10: HoldTimer_Expires Definition: An event generated when the HoldTimer expires. Status: Mandatory @@ -2141,21 +2142,21 @@ Definition: An event generated when the IdleHoldTimer expires indicating that the BGP connection has completed waiting for the back-off period to prevent BGP peer oscillation. The IdleHoldTimer is only used when the persistent peer oscillation damping function is enabled by setting the DampPeerOscillations optional attribute - is set to TRUE. + to TRUE. Implementations not implementing the persistent peer oscillation damping function may not have the IdleHoldTimer. Status: Optional Optional Attribute Status: If this event occurs: @@ -2210,21 +2211,21 @@ Status: 1) The TrackTcpState attribute should be set to TRUE if this event occurs. Event16: Tcp_CR_Acked Definition: Event indicating the local system's request to establish a TCP connection to the remote peer. The local system's TCP connection sent a TCP - SYN, and received a TCP SYN/ACK messages, + SYN, and received a TCP SYN/ACK message, and sent a TCP ACK. Status: Mandatory Event17: TcpConnectionConfirmed Definition: Event indicating that the local system has received a confirmation that the TCP connection has been established by the remote site. @@ -2303,27 +2304,27 @@ 6.8 for more information on collision detection. Event23 is an administrative action generated by implementation logic that determines that this connection needs to be dropped per the rules in section 6.8. This event may occur if the FSM is implemented as two linked state machines. - Status: Optional, depending on local system + Status: Optional Optional Attribute Status: If the state machine is to process this - attribute in Established state, - 1) CollisionDetectEstablished + event in Established state, + 1) CollisionDetectEstablishedState optional attribute SHOULD be set to TRUE Please note: The OpenCollisionDump event can occur in Idle, Connect, Active, OpenSent, OpenConfirm without any optional attributes being set. Event24: NotifMsgVerErr Definition: An event is generated when a NOTIFICATION message with "version @@ -2497,21 +2498,21 @@ The exact value of the ConnectRetryTimer is a local matter, but it SHOULD be sufficiently large to allow TCP initialization. If the DampPeerOscillations attribute is set to TRUE, the following three additional events may occur within Idle state: - AutomaticStart_with_DampPeerOscillations (Event6), - AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Event7), - - IdleHoldTimer_Expired (Event 13). + - IdleHoldTimer_Expires (Event 13). Upon receiving these 3 events, the local system will use these events to prevent peer oscillations. The method of preventing persistent peer oscillation is outside the scope of this document. Any other event (Events 9-12, 15-28) received in the Idle state does not cause change in the state of the local system. Connect State: @@ -2539,49 +2540,49 @@ - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the DelayOpenTimer_Expires event (Event12) occurs in the Connect state, the local system: - sends an OPEN message to its peer, - sets the HoldTimer to a large value, and - changes its state to OpenSent. - If the BGP FSM receives a TcpConnection_valid event + If the BGP FSM receives a TcpConnection_Valid event (Event 14), the TCP connection is processed, and the connection remains in the Connect state. If the BGP FSM receives a Tcp_CR_Invalid event (Event 15), the local system rejects the TCP connection, and the connection remains in the Connect state. - If the TCP connection succeeds (Event 16 or - Event 17), the local system checks the DelayOpen attribute prior + If the TCP connection succeeds (Event 16 or Event 17), + the local system checks the DelayOpen attribute prior to processing. If the DelayOpen attribute is set to TRUE, the local system: - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - sets the DelayOpenTimer to the initial value, and - stays in the Connect state. - If the DelayOpen attribute is not set to TRUE, the local system: + If the DelayOpen attribute is set to FALSE, the local system: - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - completes BGP initialization - sends an OPEN message to its peer, - sets HoldTimer to a large value, and - changes its state to OpenSent. A HoldTimer value of 4 minutes is suggested. - If the TCP connection fails (Event18), - the local system checks the DelayOpenTimer. If the - DelayOpenTimer is running, the local system: + If the TCP connection fails (Event18), the local system + checks the DelayOpenTimer. If the DelayOpenTimer is running, + the local system: - restarts the ConnectRetryTimer with initial value, - stops the DelayOpenTimer and resets value to zero, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. If the DelayOpenTimer is not running, the local system: - stops the ConnectRetryTimer to zero, - drops the TCP connection, - releases all BGP resources, and @@ -2591,23 +2592,23 @@ running (Event 20), the local system: - stops the ConnectRetryTimer (if running) and sets the ConnectRetryTimer to zero, - completes the BGP initialization, - stops and clears the DelayOpenTimer (sets the value to zero), - sends an OPEN message, - sends a KEEPALIVE message, - if the HoldTimer initial value is non-zero, - - starts the keepaliveTimer with the initial value and - - resets the hold timer to the negotiated value, - else if HoldTimer Initial value is zero, + - starts the KeepaliveTimer with the initial value and + - resets the HoldTimer to the negotiated value, + else if HoldTimer initial value is zero, - resets the KeepaliveTimer and - resets the HoldTimer value to zero, - and changes its state to OpenConfirm. If the value of the autonomous system field is the same as the local Autonomous System number, set the connection status to an internal connection; otherwise it is "external". If BGP message header checking detects an error (Event 21) or OPEN message checking detects an error (Event 22) (see section @@ -2642,21 +2643,21 @@ - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - performs peer oscillation damping if the DampPeerOscillations attribute is set to True, and - changes its state to Idle. In response to any other events (Events 8,10-11,13,19,23, 25-28) the local system: - if the ConnectRetryTimer is running, - stops and resets the ConnectRetrytimer (sets to zero), + stops and resets the ConnectRetryTimer (sets to zero), - if the DelayOpenTimer is running, stops and resets the DelayOpenTimer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - performs peer oscillation damping if the DampPeerOscillations attribute is set to True, and - changes its state to Idle. Active State: @@ -2672,29 +2673,29 @@ SendNOTIFICATIONwithoutOPEN session attribute is set, the local system sends a NOTIFICATION with a Cease, - releases all BGP resources including stopping the DelayOpenTimer - drops the TCP connection, - sets ConnectRetryCounter to zero, - stops the ConnectRetryTimer and sets the ConnectRetryTimer to zero, and - changes its state to Idle. - In response to a ConnectRetryTimer expires event (Event 9), + In response to a ConnectRetryTimer_Expires event (Event 9), the local system: - restarts the ConnectRetryTimer (with initial value), - initiates a TCP connection to the other BGP peer, - continues to listen for TCP connection that may be initiated by remote BGP peer, and - changes its state to Connect. - If the local system receives an DelayOpenTimer_Expired event + If the local system receives a DelayOpenTimer_Expired event (Event 12), the local system: - sets the ConnectRetryTimer to zero, - stops and clears the DelayOpenTimer (set to zero), - completes the BGP initialization, - sends the OPEN message to its remote peer, - sets its hold timer to a large value, and - changes its state to OpenSent. A HoldTimer value of 4 minutes is also suggested for this state transition. @@ -2807,69 +2808,69 @@ The start events (Event1, 3-7) are ignored in the OpenSent state. If a ManualStop event (Event 2) is issued in OpenSent state, the local system: - sends the NOTIFICATION with a cease, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - - sets ConnectRetryCounter to zero, and + - sets the ConnectRetryCounter to zero, and - changes its state to Idle. If an AutomaticStop event (Event 8) is issued in OpenSent state, the local system: - sends the NOTIFICATION with a cease, - sets the ConnectRetryTimer to zero, - - release all the BGP resources, + - releases all the BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. If the HoldTimer_Expires (Event 10), the local system: - sends a NOTIFICATION message with error code Hold Timer Expired, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) - is received, or a TcpConnectConfirm event (Event 17) is + is received, or a TcpConnectionConfirmed event (Event 17) is received, a second TCP connection may be in progress. This second TCP connection is tracked per Connection Collision processing (Section 6.8) until an OPEN message is received. A TCP Connection Request for an Invalid port (Tcp_CR_Invalid (Event 15)) is ignored. - If a TcpConnectionFails event (Event18) indication is received, + If a TcpConnectionFails event (Event18) is received, the local system: - closes the BGP connection, - restarts the ConnectRetryTimer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - changes its state to Active. When an OPEN message is received, all fields are checked for correctness. If there are no errors in the OPEN message (Event 19), the local system: - resets the DelayOpenTimer to zero, - sets the BGP ConnectRetryTimer to zero, - sends a KEEPALIVE message, and - - sets a KeepAliveTimer (via the text below) + - sets a KeepaliveTimer (via the text below) - sets the HoldTimer according to the negotiated value (see Section 4.2), - changes its state to OpenConfirm. If the negotiated hold time value is zero, then the HoldTimer and KeepaliveTimer are not started. If the value of the Autonomous System field is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is an "external" connection. (This will impact UPDATE processing as described below.) @@ -2886,21 +2887,21 @@ DampPeerOscillations attribute is TRUE, and - changes its state to Idle. Collision detection mechanisms (Section 6.8) need to be applied when a valid BGP OPEN message is received (Event 19 or Event 20). Please refer to Section 6.8 for the details of the comparison. A CollisionDetectDump event occurs when the BGP implementation determines, by a means outside the scope of this document, that a connection collision has occurred. - If a connection in OpenSent is determined to be the + If a connection in OpenSent state is determined to be the connection that must be closed, an OpenCollisionDump (Event 23) is signaled to the state machine. If such an event is received in OpenSent state, the local system: - sends a NOTIFICATION with a Cease - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and @@ -2947,32 +2948,32 @@ - sends the NOTIFICATION message with Cease, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. - If the HoldTime_Expires event (Event 10) occurs before a KEEPALIVE + If the HoldTimer_Expires event (Event 10) occurs before a KEEPALIVE message is received, the local system: - sends the NOTIFICATION message with the error code, - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. - If the local system receives a KEEPALIVETimer_Expires + If the local system receives a KeepaliveTimer_Expires event (Event 11), the system: - sends a KEEPALIVE message, - restarts the KeepaliveTimer, and - remains in OpenConfirmed state. In the event of TcpConnection_Valid event (Event 14), or TCP connection succeeding (Event 16 or Event 17) while in OpenConfirm, the local system needs to track the second connection. If a TCP connection is attempted to an invalid port (Event @@ -3054,21 +3055,21 @@ - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. Established State: In the Established state, the BGP FSM can exchange UPDATE, - NOTFICATION, and KEEPALIVE messages with its peer. + NOTIFICATION, and KEEPALIVE messages with its peer. Any Start event (Event 1, 3-7) is ignored in the Established state. In response to a ManualStop event (initiated by an operator)(Event2), the local system: - sends the NOTIFICATION message with Cease, - sets the ConnectRetryTimer to zero, - deletes all routes associated with this connection, - releases BGP resources, @@ -3101,28 +3102,28 @@ - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. If the KeepaliveTimer_Expires event occurs (Event11), the local system: - sends a KEEPALIVE message, and - - restarts its KeepAliveTimer unless the negotiated + - restarts its KeepaliveTimer unless the negotiated HoldTime value is zero. Each time the local system sends a KEEPALIVE or UPDATE - message, it restarts its KeepAliveTimer, unless the + message, it restarts its KeepaliveTimer, unless the negotiated HoldTime value is zero. - A TcpConnection_valid (Event 14) received for a + A TcpConnection_Valid (Event 14) received for a valid port will cause the second connection to be tracked. An invalid TCP connection (Tcp_CR_Invalid Event (Event 15)), will be ignored. In response to an indication that the TCP connection is successfully established (Event 16 or Event 17), the second connection SHALL be tracked until it sends an OPEN message. @@ -3156,44 +3157,44 @@ - changes its state to Idle. If the local system receives a KEEPALIVE message (Event 26), the local system: - restarts its HoldTimer, if the negotiated HoldTime value is non-zero, and - remains in the Established state. If the local system receives an UPDATE message (Event27), the local system: - - processes the update packet, + - processes the message, - restarts its HoldTimer if the negotiated HoldTime value is non-zero, and - remains in the Established state. If the local system receives an UPDATE message, and the UPDATE message error handling procedure (see Section 6.3) detects an error (Event28), the local system: - sends a NOTIFICATION message with Update error, - - sets the Connect Retry timer to zero, + - sets the ConnectRetryTimer to zero, - deletes all routes associated with this connection, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. In response to any other event (Events 9, 12-13, 20-22) the local system: - sends a NOTIFICATION message with Error Code Finite State Machine Error, - deletes all routes associated with this connection, - - sets the Connect Retry timer to zero, + - sets the ConnectRetryTimer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCounter by 1, - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and - changes its state to Idle. 9. UPDATE Message Handling An UPDATE message may be received only in the Established state. @@ -3483,21 +3484,23 @@ 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 lowest possi- ble MULTI_EXIT_DISC value, i.e. 0. Similarly, neighborAS(n) is a function which returns the neighbor AS from which the route was received. If the route is learned via IBGP, and the other IBGP speaker didn't originate the route, it is the neighbor AS from which the other IBGP speaker learned the route. If the route is learned via IBGP, and the other IBGP - speaker originated the route, it is the local AS. + speaker either (a) originated the route, or (b) created the route + by aggregation and the AS_PATH attribute of the aggregate route is + either empty or begins with an AS_SET, it is the local AS. If a MULTI_EXIT_DISC attribute is removed before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed. If an implemen- tation chooses to remove MULTI_EXIT_DISC, then the optional com- parison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes. The best EBGP learned route may then be compared with IBGP learned routes after the removal of the MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a subset of EBGP learned routes and the selected "best" EBGP learned @@ -3545,22 +3548,22 @@ a) when routes in the Loc-RIB to local destinations have changed b) when locally generated routes learned by means outside of BGP have changed c) when a new BGP speaker - BGP speaker connection has been estab- lished The Phase 3 function is a separate process which completes when it has no further work to do. The Phase 3 Routing Decision function is - blocked from running while the Phase 2 decision function is in pro- - cess. + blocked from running while the Phase 2 decision function is in + process. All routes in the Loc-RIB are processed into Adj-RIBs-Out according to configured policy. This policy MAY exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out. A route SHALL NOT be installed in the Adj-Rib-Out unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table. If a route in Loc-RIB is excluded from a particular Adj-RIB- Out the previously advertised route in that Adj-RIB-Out MUST be with- drawn from service by means of an UPDATE message (see 9.2). @@ -3754,20 +3757,24 @@ Adj-RIBs-Out. Aggregation reduces the amount of information that a BGP speaker must store and exchange with other BGP speakers. Routes can be aggregated by applying the following procedure separately to path attributes of the same type and to the Network Layer Reachability Information. Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be aggregated. + If the aggregated route has an AS_SET as the first element in its + AS_PATH attribute, then the router that originates the route SHOULD + NOT advertise the MULTI_EXIT_DISC attribute with this route. + Path attributes that have different type codes can not be aggregated together. Path attributes of the same type code may be aggregated, according to the following rules: NEXT_HOP: When aggregating routes that have different NEXT_HOP attribute, the NEXT_HOP attribute of the aggregated route SHALL identify an interface on the BGP speaker that performs the aggregation. ORIGIN attribute: @@ -3871,44 +3878,44 @@ "unstable" and "rapid" in the previous sentence will require expe- rience, but the principle is clear. Routes that are unstable can be "penalized" (e.g., by using the procedures described in [RFC2439]). 9.4 Originating BGP routes A BGP speaker may originate BGP routes by injecting routing informa- tion acquired by some other means (e.g. via an IGP) into BGP. A BGP speaker that originates BGP routes assigns the degree of preference - (e.g., via CLI) to these routes by passing them through the Decision - Process (see Section 9.1). These routes MAY also be distributed to - other BGP speakers within the local AS as part of the update process - (see Section 9.2). The decision whether to distribute non-BGP - acquired routes within an AS via BGP or not depends on the environ- - ment within the AS (e.g. type of IGP) and SHOULD be controlled via - configuration. + (e.g., according to local configuration) to these routes by passing + them through the Decision Process (see Section 9.1). These routes MAY + also be distributed to other BGP speakers within the local AS as part + of the update process (see Section 9.2). The decision whether to dis- + tribute non-BGP acquired routes within an AS via BGP or not depends + on the environment within the AS (e.g. type of IGP) and SHOULD be + controlled via configuration. 10 BGP Timers BGP employs five timers: ConnectRetryTimer (see Section 8), HoldTimer - (see Section 4.2), KeepAliveTimer (see Section 8), MinASOrigination- + (see Section 4.2), KeepaliveTimer (see Section 8), MinASOrigination- IntervalTimer (see Section 9.2.1.2), and MinRouteAdvertisementInter- valTimer (see Section 9.2.1.1). Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer by BGP (see section 8). Section 8 describes their use. The full oper- ation of these optional timers is outside the scope of this document. ConnectRetryTime is a mandatory FSM attribute that stores the initial value for the ConnectRetryTimer. The suggested default value for the ConnectRetryTime is 120 seconds. - Holdtime is a mandatory FSM attribute that stores the initial value + HoldTime is a mandatory FSM attribute that stores the initial value for the HoldTimer. The suggested default value for the HoldTime is 90 seconds. During some portions of the state machine (see Section 8), the Hold- Timer is set to a large value. The suggested default for this large value is 4 minutes. The KeepaliveTime is a mandatory FSM attribute that stores the ini- tial value for the KeepaliveTimer. The suggested default value for the KeepaliveTime is 1/3 of the HoldTime. @@ -3921,21 +3928,21 @@ The suggested default value for the MinRouteAdvertisementInterval- Timer on IBGP connections is 5 seconds. An implementation of BGP MUST allow the HoldTimer to be configurable on a per peer basis, and MAY allow the other timers to be config- urable. To minimize the likelihood that the distribution of BGP messages by a given BGP speaker will contain peaks, jitter SHOULD be applied to the - timers associated with MinASOriginationIntervalTimer, KeepAliveTimer, + timers associated with MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer, and ConnectRetryTimer. A given BGP speaker MAY apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter need not be configured on a "per peer" basis. The suggested default amount of jitter SHALL be determined by multi- plying the base value of the appropriate timer by a random factor which is uniformly distributed in the range from 0.75 to 1.0. A new random value SHOULD be picked each time the timer is set. The range of the jitter random value MAY be configurable. @@ -4310,22 +4319,22 @@ [RFC1092] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET Backbone", RFC1092, February 1989. [RFC1093] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, February 1989. [RFC1772] Rekhter, Y., and P. Gross, "Application of the Border Gate- way Protocol in the Internet", RFC1772, March 1995. - [RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address - Allocation with CIDR", RFC 1518, September 1993. + [RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address Allo- + cation with CIDR", RFC 1518, September 1993. [RFC1519] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, September 1993. [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2439] C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap Damping", RFC2439, November 1998.