--- 1/draft-ietf-idr-bgp4-19.txt 2006-02-04 23:30:17.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-20.txt 2006-02-04 23:30:18.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. @@ -30,21 +30,21 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. - TTaabbllee ooff CCoonntteennttss + Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Definition of commonly used terms . . . . . . . . . . . . . . 4 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 3. Summary of Operation . . . . . . . . . . . . . . . . . . . . . 7 3.1 Routes: Advertisement and Storage . . . . . . . . . . . . . . 9 3.2 Routing Information Bases . . . . . . . . . . . . . . . . . . 10 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 Message Header Format . . . . . . . . . . . . . . . . . . . . 11 4.2 OPEN Message Format . . . . . . . . . . . . . . . . . . . . . 12 @@ -66,62 +66,65 @@ 6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 32 6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 34 6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 34 6.6 Finite State Machine error handling . . . . . . . . . . . . . 34 6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.8 BGP connection collision detection . . . . . . . . . . . . . 35 7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 36 8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 36 8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 37 8.1.1 Administrative Events . . . . . . . . . . . . . . . . . . 37 - 8.1.2 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 38 - 8.1.3 TCP connection based Events . . . . . . . . . . . . . . . . 39 - 8.1.4 BGP Messages based Events . . . . . . . . . . . . . . . . . 41 - 8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 43 - 8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 43 - 8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 43 - 8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 44 - 8.2.2 Finite State Machine . . . . . . . . . . . . . . . . . . . 44 - 9. UPDATE Message Handling . . . . . . . . . . . . . . . . . . . 57 - 9.1 Decision Process . . . . . . . . . . . . . . . . . . . . . . 58 - 9.1.1 Phase 1: Calculation of Degree of Preference . . . . . . . 59 - 9.1.2 Phase 2: Route Selection . . . . . . . . . . . . . . . . . 60 - 9.1.2.1 Route Resolvability Condition . . . . . . . . . . . . . . 61 - 9.1.2.2 Breaking Ties (Phase 2) . . . . . . . . . . . . . . . . . 62 - 9.1.3 Phase 3: Route Dissemination . . . . . . . . . . . . . . . 64 - 9.1.4 Overlapping Routes . . . . . . . . . . . . . . . . . . . . 65 - 9.2 Update-Send Process . . . . . . . . . . . . . . . . . . . . . 66 - 9.2.1 Controlling Routing Traffic Overhead . . . . . . . . . . . 67 - 9.2.1.1 Frequency of Route Advertisement . . . . . . . . . . . . 67 - 9.2.1.2 Frequency of Route Origination . . . . . . . . . . . . . 68 - 9.2.2 Efficient Organization of Routing Information . . . . . . . 68 - 9.2.2.1 Information Reduction . . . . . . . . . . . . . . . . . . 68 - 9.2.2.2 Aggregating Routing Information . . . . . . . . . . . . . 69 - 9.3 Route Selection Criteria . . . . . . . . . . . . . . . . . . 72 - 9.4 Originating BGP routes . . . . . . . . . . . . . . . . . . . 72 - 10. BGP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 72 - Appendix A. Comparison with RFC1771 . . . . . . . . . . . . . . . 73 - Appendix B. Comparison with RFC1267 . . . . . . . . . . . . . . . 74 - Appendix C. Comparison with RFC 1163 . . . . . . . . . . . . . . 75 - Appendix D. Comparison with RFC 1105 . . . . . . . . . . . . . . 75 - Appendix E. TCP options that may be used with BGP . . . . . . . . 76 - Appendix F. Implementation Recommendations . . . . . . . . . . . 76 - Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 76 - Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 77 - Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 77 - Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 77 - Appendix F.5 Control over version negotiation . . . . . . . . . . 78 - Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 78 - Security Considerations . . . . . . . . . . . . . . . . . . . . . 79 - IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 79 - References . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 - Authors Information . . . . . . . . . . . . . . . . . . . . . . . 80 + 8.1.2 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 40 + 8.1.3 TCP connection based Events . . . . . . . . . . . . . . . . 41 + 8.1.4 BGP Messages based Events . . . . . . . . . . . . . . . . . 43 + 8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 45 + 8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 45 + 8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 46 + 8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 46 + 8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 47 + 8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 47 + 8.2.2 Finite State Machine . . . . . . . . . . . . . . . . . . . 47 + 9. UPDATE Message Handling . . . . . . . . . . . . . . . . . . . 62 + 9.1 Decision Process . . . . . . . . . . . . . . . . . . . . . . 63 + 9.1.1 Phase 1: Calculation of Degree of Preference . . . . . . . 64 + 9.1.2 Phase 2: Route Selection . . . . . . . . . . . . . . . . . 65 + 9.1.2.1 Route Resolvability Condition . . . . . . . . . . . . . . 66 + 9.1.2.2 Breaking Ties (Phase 2) . . . . . . . . . . . . . . . . . 67 + 9.1.3 Phase 3: Route Dissemination . . . . . . . . . . . . . . . 69 + 9.1.4 Overlapping Routes . . . . . . . . . . . . . . . . . . . . 70 + 9.2 Update-Send Process . . . . . . . . . . . . . . . . . . . . . 71 + 9.2.1 Controlling Routing Traffic Overhead . . . . . . . . . . . 72 + 9.2.1.1 Frequency of Route Advertisement . . . . . . . . . . . . 72 + 9.2.1.2 Frequency of Route Origination . . . . . . . . . . . . . 73 + 9.2.2 Efficient Organization of Routing Information . . . . . . . 73 + 9.2.2.1 Information Reduction . . . . . . . . . . . . . . . . . . 73 + 9.2.2.2 Aggregating Routing Information . . . . . . . . . . . . . 74 + 9.3 Route Selection Criteria . . . . . . . . . . . . . . . . . . 76 + 9.4 Originating BGP routes . . . . . . . . . . . . . . . . . . . 77 + 10. BGP Timers . . . . . . . . . . . . . . . . . . . . . . . . . 77 + Appendix A. Comparison with RFC1771 . . . . . . . . . . . . . . . 78 + Appendix B. Comparison with RFC1267 . . . . . . . . . . . . . . . 79 + Appendix C. Comparison with RFC 1163 . . . . . . . . . . . . . . 80 + Appendix D. Comparison with RFC 1105 . . . . . . . . . . . . . . 80 + Appendix E. TCP options that may be used with BGP . . . . . . . . 81 + Appendix F. Implementation Recommendations . . . . . . . . . . . 81 + Appendix F.1 Multiple Networks Per Message . . . . . . . . . . . 81 + Appendix F.2 Reducing route flapping . . . . . . . . . . . . . . 82 + Appendix F.3 Path attribute ordering . . . . . . . . . . . . . . 82 + Appendix F.4 AS_SET sorting . . . . . . . . . . . . . . . . . . . 82 + Appendix F.5 Control over version negotiation . . . . . . . . . . 83 + Appendix F.6 Complex AS_PATH aggregation . . . . . . . . . . . . 83 + Security Considerations . . . . . . . . . . . . . . . . . . . . . 84 + IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 84 + Normative References . . . . . . . . . . . . . . . . . . . . . . 84 + Non-normative References . . . . . . . . . . . . . . . . . . . . 85 + Authors Information . . . . . . . . . . . . . . . . . . . . . . . 86 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- @@ -142,92 +145,92 @@ header of the packet. This, in turn, reflects the set of policy deci- sions that can (and can not) be enforced using BGP. BGP can support only the policies conforming to the destination-based forwarding paradigm. 1. Definition of commonly used terms This section provides definition for terms that have a specific mean- ing to the BGP protocol and that are used throughout the text. + Adj-RIB-In + The Adj-RIBs-In contain unprocessed routing information that has + been advertised to the local BGP speaker by its peers. + + Adj-RIB-Out + The Adj-RIBs-Out contains the routes for advertisement to specific + peers by means of the local speaker's UPDATE messages. + Autonomous System (AS) The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route pack- ets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASs. Since this classic definition was developed, it has become common for a single AS to use several IGPs and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the adminis- tration of an AS appears to other ASs to have a single coherent interior routing plan and presents a consistent picture of what destinations are reachable through it. - BGP speaker - A router that implements BGP. - BGP Identifier A 4-octet unsigned integer indicating the BGP Identifier of the sender of BGP messages. A given BGP speaker sets the value of its BGP Identifier to an IP address assigned to that BGP speaker. The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. - Internal peer - Peer that is in the same Autonomous System as the local system. + BGP speaker + A router that implements BGP. - IBGP - Internal BGP (BGP connection between internal peers). + EBGP + External BGP (BGP connection between external peers). External peer Peer that is in a different Autonomous System than the local sys- tem. - EBGP - External BGP (BGP connection between external peers). + Feasible route + A route that is available for use. + + 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- + tem. + + Loc-RIB + The Loc-RIB contains the routes that have been selected by the + local BGP speaker's Decision Process. NLRI Network Layer Reachability Information. Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destina- tions are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Informa- tion (NLRI) field of an UPDATE message. The path is the informa- tion reported in the path attributes field of the same UPDATE mes- sage. RIB Routing Information Base. - Adj-RIB-In - The Adj-RIBs-In contain unprocessed routing information that has - been advertised to the local BGP speaker by its peers. - - Loc-RIB - The Loc-RIB contains the routes that have been selected by the - local BGP speaker's Decision Process. - - Adj-RIB-Out - The Adj-RIBs-Out contains the routes for advertisement to specific - peers by means of the local speaker's UPDATE messages. - - IGP - Interior Gateway Protocol - a routing protocol used to exchange - routing information among routers within a single Autonomous Sys- - tem. - - Feasible route - A route that is available for use. - Unfeasible route A previously advertised feasible route that is no longer available for use. 2. Acknowledgments This document was originally published as RFC 1267 in October 1991, jointly authored by Kirk Lougheed and Yakov Rekhter. We would like to express our thanks to Guy Almes, Len Bosack, and @@ -1607,30 +1610,36 @@ of BGP MUST retain the format of the OPEN and NOTIFICATION messages. 8. BGP Finite State machine This section specifies the BGP operation in terms of a Finite State Machine (FSM). The section falls into 2 parts: 1) Description of Events for the State machine (Section 8.1) 2) Description of the FSM (Section 8.2) - Session Attributes required for each connection are; + The data structures and FSM described in this document are conceptual + and do not have to be implemented precisely as described here, as + long as the implementations support the described functionality and + their externally visible behavior is the same. + + Session Attributes required for each connection are: 1) State 2) Connect Retry timer 3) Hold timer 4) Hold time 5) Keepalive timer 6) Keepalive time 7) Connect Retry Count 8) Connect Retry Initial Value + The optional Session attributes are listed below. These optional attributes may be supported either per connection or per local sys- tem: 1) Delay Open flag 2) Open Delay Timer 3) Perform automatic start flag 4) Perform automatic stop flag 5) Passive TCP establishment flag 6) Perform BGP peer oscillation damping flag @@ -1655,34 +1664,34 @@ Definition: Local system administrator manually starts peer connection. Status: Mandatory Optional attributes: Passive TCP establishment flag SHOULD not be set. Event2: Manual stop - Definition: Local system administrator manually stops the peer connection. Status: Mandatory + Event3: Automatic start Definition: Local system automatically starts the BGP connection. Status: Optional depending on local system. Optional - attributes: 1) Perform automatic start flag SHOULD be set. + attributes: 1) Perform automatic start flag SHOULD be set if this event occurs. 2) if the passive Passive TCP establishment flag is supported, it SHOULD not be set if this event occurs. 3) if bgp peer oscillation damping is supported, the BGP stop_peer_flap flag should not be set when this event occurs. Event4: Manual start with passive TCP flag @@ -1691,21 +1700,21 @@ enabled. The passive TCP establishment flag indicates that the peer will listen prior to establishing the connection. Status: Optional depending on local system. Optional attributes: 1) Passive TCP Establishment flag SHOULD be set. if this event occurs. 2) If bgp peer oscilation damping is supported, the - stop_peer_flap falg should not be set when + stop_peer_flap flag should not be set when this event occurs. Event5: Automatic start with passive TCP flag Definition: Local system automatically starts the BGP connection with the passive flag enabled. The passive flag indicates that the peer will listen prior to establishing a connection. @@ -2015,24 +2023,24 @@ 8.2 Description of FSM 8.2.1 FSM Definition BGP MUST maintain a separate FSM for each configured peer, Each BGP peer paired in a potential connection unless configured to remain in the idle state, or configured to remain passive, will attempt to to connect to the other. For the purpose of this discussion, the active or connect side of the TCP connection (the side of a TCP connection - (the side sending the first TCP SYN packet) is called outgoing. The - passive or listening side (the sender of the first SYN ACK) is called - an incoming connection (see Section 8.2.1.1 on the terms active and - passive below). + sending the first TCP SYN packet) is called outgoing. The passive or + listening side (the sender of the first SYN ACK) is called an incom- + ing connection (see Section 8.2.1.1 on the terms active and passive + below). A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers. For each incoming connection, a state machine MUST be instantiated. There exists a period in which the identity of the peer on the other end of an incoming connection is known but the BGP identifier is not known. During this time, both an incoming and an outgoing connection for the same configured peering may exist. This is referred to as a connection collision (see Section 6.8). @@ -2067,375 +2075,380 @@ The collision detection identifies the case where there is more than one connection per peer and provides guidance for which connection to get rid of. When this occurs, the corresponding FSM for the connec- tion that is closed SHOULD be disposed of. 8.2.1.3 FSM and Optional Attributes Optional Attributes specify either flags that augment the normal pro- cessing of the BGP FSM, or optional timers. If a Optional attribute can be set on a system, the Events and the BGP FSM actions must be - support. For example, if the following options can be set in a BGP + supported. For example, if the following options can be set in a BGP implementation: AutoStart and Passive TCP connection Establishment flag, then the events 3, 4 and 5 must be supported. - If an Optional attribute is cannot be set (that is declared always - off logically), the events supporting that set of options do not have - to be supported. + If an Optional attribute cannot be set (that is declared always off + logically), the events supporting that set of options do not have to + be supported. 8.2.1.4 FSM Event numbers The Event numbers (1-28) utilized in this state machine description aid in specifying the behavior of the BGP state machine. Implementa- tions MAY use these numbers to provide network management informa- - tion. + tion. The exact form of the FSM and the FSM events is specific to + each implementation. 8.2.2 Finite State Machine Idle state: Initially BGP is in the Idle state. In this state BGP refuses all incoming BGP connections. No resources are allocated to the peer. In response to a manual start event(Event1) or an automatic start event(Event3), the local system: - initializes all BGP resources, - sets ConnectRetryCnt (the connect retry counter) to zero - - starts the connect retry timer with initial value, + - starts the Connect Retry timer with initial value, - initiates a TCP connection to the other BGP peer, - listens for a connection that may be initiated by the remote BGP peer, and - changes its state to Connect. - An manual stop event (Event2) and Auto stop (Event 8) events are + The manual stop event (Event2) and Automatic stop event (Event 8) are ignored in the Idle state. In response to a manual start event with the passive TCP connection flag (Event 4) or automatic start with the passive TCP connection flag (Event 5), the local system: - initializes all BGP resources, - sets ConnectRetryCnt (the connect retry counter) to zero, - - starts the connect retry timer with initial value, + - starts the Connect Retry timer with initial value, - listens for a connection that may be initiated by the remote peer, and - changes its state to Active. The exact value of the ConnectRetry timer is a local matter, but it SHOULD be sufficiently large to allow TCP initialization. If the persistent peer oscillation damping function is enabled, three additional events may occur within Idle state: - Automatic start with peer_stop_flap set [Event6], - - Automatic start with peer_stop_flag set [Event7], + - Automatic start with peer_stop_flap set and + passive TCP establishment flag set [Event7], - Idle Hold Timer expired [Event 13]. The method of preventing persistent peer oscillation is outside the scope of this document. - Any other events [Events 9-12, 15-28] received in the Idle state does - not cause change in the state of the local system. + Any other events [Events 9-12, 15-28] received in the Idle state + does not cause change in the state of the local system. Connect State: In this state, BGP is waiting for the TCP connection to be completed. The start events [Event 1, 3-7] are ignored in connect state. In response to a manual stop event [Event2], the local system: - drops the TCP connection, - releases all BGP resources, - sets ConnectRetryCnt (the connect retry count) to zero - - resets the connect retry timer (sets to zero), and + - sets the Connect Retry timer to zero, and - changes its state to Idle. - In response to the connect retry timer expires event [Event + In response to the Connect Retry timer expires event [Event 9], the local system: - drops the TCP connection, - - restarts the connect retry timer, + - restarts the Connect Retry timer, - stops the Open Delay timer and resets the timer to zero, - initiates a TCP connection to the other BGP peer, - continues to listen for a connection that may be initiated by the remote BGP peer, and - stays in Connect state. If the Open Delay timer expires [Event12] in the connect state, the local system: - sends an OPEN message to its peer, - sets the hold timer to a large value, and - changes its state to OpenSent. If the BGP port receives a valid TCP connection indication [Event 14], the TCP connection is processed and the connection remains in the Connect state. If the TCP connection receives an invalid indication [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 Delay Open flag prior - to processing. If the Delay Open flag is set, the local system: - - clears the connect retry timer, + If the TCP connection succeeds [Event 16 or Event 17], + the local system checks the Delay Open flag prior to + processing. If the Delay Open flag is set, the local system: + - sets the Connect Retry timer to zero, - set the Open Delay timer to the initial value, and - stays in the Connect state. If the Delay Open flag is not set, the local system: - - clears the connect retry timer, + - sets the Connect Retry timer to zero, - completes BGP initialization - sends an OPEN message to its peer, - sets hold timer to a large value, and - changes its state to OpenSent. A hold timer value of 4 minutes is suggested. If the TCP connection fails [Event18], the local system checks the Open Delay Timer. If the Open Delay timer is running, the local system: - restarts the connect retry time with initial value, - stops the Open Delay timer 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 open Delay timer is not running, the local system: - - - resets the connect retry timer (sets to zero), and - - Drops the TCP connection, - - Releases all BGP resources, - - and goes to Idle State. + - sets the Connect Retry timer to zero, + - drops the TCP connection, + - releases all BGP resources, and + - changes its state to Idle. If an OPEN message is received with the Open Delay timer is running [Event 20], the local system: - - clears the connect retry timer (cleared to zero), + - sets the Connect Retry timer to zero, - completes the BGP initialization, - - stops and clears the Open Delay timer, + - stops and clears the Open Delay timer (sets the value to zero), - sends an OPEN message, - - sends a Keepalive message, + - sends a KEEPALIVE message, - If the hold timer value is non-zero, - start the keepalive timer to inital value, - reset the hold timer to the negotiated value, else if hold timer value is zero, - - reset the keepalive timer. and - - reset the hold timer value to zero. + - reset the keepalive timer, and + - reset the hold timer 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 6.2), the local system: - (optionally) If the Send Notification without Open flag is set, then the local system first sends a NOTIFICATION message with the appropriate error code, and then - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - - [optionally] performs peer oscillation damping, - - and goes to Idle. + - optionally performs peer oscillation damping, + - and changes its state to Idle. If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. + If the Open Delay timer is running, the local system: - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - stops and reset the Open Delay timer (sets to zero), - releases all BGP resources, - - drops the TCP connection, + - drops the TCP connection, and - changes its state to Idle. If the Open Delay timer is not running, the local system: - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, 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 connect retry timer is running, - stop and reset the connect retry timer (sets to zero), - - if the Delay Open timer is running, - stop and reset the Delay Open timer (sets to zero), + - if the Connect Retry timer is running, + stop and reset the Connect Retry timer (sets to zero), + - if the Open Delay timer is running, + stop and reset the Open Delay timer (sets to zero), - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. Active State: In this state BGP is trying to acquire a peer by listening for and accepting a TCP connection. The start events [Event1, 3-7] are ignored in the Active state. - A manual stop event[Event2], the local system: - - If the Delay Open timer is running and the + In response to a manual stop event[Event2], the local system: + - If the Open Delay timer is running and the Send NOTIFICATION without Open flag is set, the local system Sends a NOTIFICATION with a Cease, - releases all BGP resources including - stopping the Open delay timer - drops the TCP connection, - sets ConnectRetryCnt (connect retry count) to zero - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, and - changes its state to Idle. In response the ConnectRetry timer expires event[Event9], the local system: - - restarts the connect retry timer (with initial value), + - restarts the Connect Retry timer (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. + initiated by remote BGP peer, and + - changes its state to Connect. If the local system has the Open Delay timer expired [Event12], the local system: - - clears the connect retry timer (set to zero), + - sets the Connect Retry timer to zero, - stops and clears the Open Delay timer (set to zero), - completes the BGP initialization, - sends the OPEN message to it's remote peer, - sets its hold timer to a large value, and - changes its state to OpenSent. A hold timer value of 4 minutes is also suggested for this state transition. If the local system receives a valid TCP indication [Event 14], the local system processes the TCP connection flags, and stays in Active state. If the local system receives an invalid TCP indication [Event 15]: the local system rejects the TCP connection, and stays in the Active State. - A TCP connection succeeds [Event 16 or Event 17], the + In response to a TCP connection succeeds [Event 16 or Event 17], the local system checks the "Delay Open Flag" prior to processing. If the Delay Open flag is set, the local system - o clears the connect retry timer, - o sets the BGP Open Delay timer to the initial value, and + o sets the Connect Retry timer to zero, + o sets the Open Delay timer to the initial value, and o stays in the Active state. -If the Delay Open flag is not set, the local system - o clears the connect retry timer, + o sets the Connect Retry timer to zero, o completes the BGP initialization, o sends the OPEN message to it's peer, o sets its hold timer to a large value, and o changes its state to OpenSent. A hold timer value of 4 minutes is suggested as a "large value" for the hold timer. If the local system receives a TCP connection fails event [Event 18], the local system will: - - restart connect retry timer (with initial value), - - stops and clears Open Delay Timer (sets the value to zero), + - restart the Connect Retry timer (with initial value), + - stops and clears the Open Delay Timer (sets the value to zero), - release all BGP resources - Acknowledge the drop of TCP connection if TCP disconnect (send a FIN ACK), - Increment ConnectRetryCnt (connect retry count) by 1, and - - optionally perform peer oscillation damping, - - and go to to Idle. + - optionally perform peer oscillation damping, and + - changes its state to Idle. If an OPEN message is received with the Open Delay timer is running [Event 20], the local system - - clears the connect retry timer (cleared to zero), + - sets the Connect Retry timer to zero, - stops and clears the Open Delay timer - completes the BGP initialization, - sends an OPEN message, - - send a Keepalive message, and + - sends a KEEPALIVE message, and - if the hold timer value is non-zero, - starts the keepalive timer to initial value, - resets the hold timer to the negotiated value, else if the hold timer is zero - resets the keepalive timer (set to zero), - - resets the hold timer to zero. - - changes its state to OpenConfirm. + - resets the hold timer 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 6.2), the local system: - (optionally) sends NOTIFICATION message with the appropriate error code, - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - - [optionally] performs peer oscillation damping, - - and goes to Idle. + - optionally performs peer oscillation damping, + - and changes its state to Idle. If a NOTIFICATION message is received with a version error[Event24], the local system checks the Open Delay timer. If the Open Delay timer is running, the local system: - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - stops and reset the Open Delay timer (sets to zero, - releases all BGP resources, - - drops the TCP connection, + - drops the TCP connection, and - changes its state to Idle. If the Open Delay timer is not running, the local system: - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - - changes its state to Idle + - changes its state to Idle. In response to any other event [Events 8,10-11,13,19,23,25-28], the local system: - - resets the connect retry timer (sets to zero), - - drops the TCP connection, + - sets the Connect Retry timer to zero, - releases all BGP resources, + - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by one, - optionally performs peer oscillation damping, and - changes its state to Idle. OpenSent: In this state BGP waits for an OPEN message from its peer. The Start events [Event1, 3-7] are ignored in the OpenSent state. If a manual stop event [Event 2] is issued in Open sent state, the local system: - sends the NOTIFICATION with a cease, + - sets the Connect Retry timer to zero, - release all BGP resources, - drops the TCP connection, - - set ConnectRetryCnt (connect retry count) to zero, - - resets the Connect Retry timer (set to zero), and + - set ConnectRetryCnt (connect retry count) to zero, and - changes its state to Idle. If an automatic stop event [Event 8] is issued in OpenSent state, the local system: - sends the NOTIFICATION with a cease, + - sets the Connect Retry timer to zero, - release all the BGP resources - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If the Hold Timer expires[Event 10], the local system: + - send a NOTIFICATION message with error code Hold Timer Expired, - - reset the connect retry timer (sets to zero), + - set the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - - increments the ConnectRetryCnt (connect retry count) by 1, and + - increments the ConnectRetryCnt (connect retry count) by 1, + - optionally performs peer oscillation damping, and - changes its state to Idle. If a TCP indication is received for valid connection [Event 14] or TCP request aknowledgement [Event 16] is received, or a TCP connect confirm [Event 17] is received a second TCP session may be in progress. This second TCP session is tracked per the Connection Collision processing (Section 6.8) until an OPEN message is received. A TCP connection for an invalid port [Event 15] is ignored. @@ -2445,21 +2458,21 @@ - closes the BGP connection, - restarts the Connect Retry timer, - 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 Open Delay timer to zero, - - reset BGP Connect Timer to zero, + - sets the BGP Connect Retry timer to zero, - sends a KEEPALIVE message and - sets a KeepAlive timer (via the text below) - sets the hold timer according to the negotiated value (see Section 4.2), and - changes its state to OpenConfirm. If the negotiated hold time value is zero, then the Hold and KeepAlive timers 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 @@ -2461,247 +2474,244 @@ If the negotiated hold time value is zero, then the Hold and KeepAlive timers 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.) If the BGP message header checking [Event21] or OPEN message check detects an error (see Section 6.2)[Event22], the local system: + - sends a NOTIFICATION message with appropriate error code, - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection - increments the ConnectRetryCnt (connect retry cout) by 1, - optionally performs peer oscillation damping, 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. An administrative collision detect is when - BGP implementation determines my means outside the scope of + BGP implementation determines by means outside the scope of this document that a connection collision has occurred. If a connection in OpenSent is determined to be the connection that must be closed, an open collision dump [Event 23] is signaled to the state machine. If such an event is received in OpenSent, the local system: - sends a NOTIFICATION with a Cease - - resets the connect retry timer, + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - - increments ConnectRetryCnt (connect rery count) by 1, + - increments ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If a NOTIFICATION message is received with a version error[Event24], the local system: - - resets the connect retry timer (sets to zero) + - sets the Connect Retry timer to zero - releases all BGP resources, - drops the TCP connection, - changes its state to Idle. In response to any other event [Events 9, 11-13,20,25-28], the local system: - sends the NOTIFICATION with the Error Code Finite state machine error, - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. OpenConfirm State: In this state BGP waits for a KEEPALIVE or NOTIFICATION message. Any start event [Event1, 3-7] is ignored in the OpenConfirm state. In response to a manual stop event[Event 2] initiated by the operator, the local system: - sends the NOTIFICATION message with Cease, - releases all BGP resources, - drop the TCP connection, - sets the ConnectRetryCnt (connect retry count) to zero - - sets the connect retry timer to zero, and + - sets the Connect Retry timer to zero, and - changes its state to Idle. In response to the Automatic stop event initiated by the system[Event 8], the local system: - sends the NOTIFICATION message with Cease, - - connect retry timer reset (set to zero) + - sets the Connect Retry timer to zero, - release all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - - optionally performs peer oscillation damping, + - optionally performs peer oscillation damping, and - changes its state to Idle. If the Hold Timer expires before a KEEPALIVE message is received [Event 10], the local system: - send the NOTIFICATION message with the error code set to Hold Time Expired, - - resets the connect retry timer (sets the timer to to - zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - - increments the ConnectRetryCnt (connect retry count) - by 1, - - optionally performs peer oscillation damping, - and + - increments the ConnectRetryCnt (connect retry count) by 1, + - optionally performs peer oscillation damping, and - changes its state to Idle. If the local system receives a KEEPALIVE timer expires event [Event 11], the system: - sends a KEEPALIVE message, - restarts the Keepalive timer, and - remains in OpenConfirmed state. In the event of TCP connection valid indication [Event 14], or TCP connection succeeding [Event 16 or Event 17] while in OpenConfirm, the local system needs to track the 2nd connection. If a TCP connection is attempted to an invalid port [Event 15], the local system will ignore the second connection attempt. If the local system receives a TCP connection fails event - [Event 18] from the underlying TCP. or a NOTIFICATION + [Event 18] from the underlying TCP, or a NOTIFICATION message [Event 25] the local system: - - resets the connect retry timer (sets the timer to - zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - - optionally performs peer oscillation damping, + - optionally performs peer oscillation damping, and - changes its state to Idle. - If the local system receives a NOTIFICATION message [Event 24] with - a version error, the local system: - - resets the connect retry timer (sets the timer to zero), + If the local system receives a NOTIFICATION message [Event 24] + with a version error, the local system: + - sets the Connect Retry timer to zero, - releases all BGP resources, - - drops the TCP connection, - - changes its state to Idle. [Verify this/or above] + - drops the TCP connection, and + - changes its state to Idle. - If the OPEN message is valid [Event 19], the collision - detect function is processed per Section 6.8. If this + If the local system receives a valid OPEN message [Event 19], the + collision detect function is processed per Section 6.8. If this connection is to be dropped due to connection collision, the local system: - sends a NOTIFICATION with a Cease - - resets the Connect timer (set to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection (send TCP FIN), - - increments the ConnectRetryCnt by 1 (connect retry count), and - - optionally performs peer oscillation damping. + - increments the ConnectRetryCnt by 1 (connect retry count), + - optionally performs peer oscillation damping, and + - changes its state to Idle. If an OPEN message is received, all fields are check for correctness. If the BGP message header checking [Event21] or OPEN message check detects an error (see Section 6.2)[Event22], the local system: - sends a NOTIFICATION message with appropriate error code, - - resets the connect retry timer (sets the timer to - zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If during the processing of another OPEN message, the BGP - implementation determines my means outside the scope of + implementation determines by means outside the scope of this document that a connection collision has occurred and this connection is to be closed, the local system will issue a open collision dump [Event 23]. When the local system receives a open collision dump event [Event 23], the local system: - - send a NOTIFICATION with a Cease - - resets the connect retry timer, + - sends a NOTIFICATION with a Cease + - sets the Connect Retry timer to zero, - releases all BGP resources - drops all TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If the local system receives a KEEPALIVE message[Event 26], - restarts the Hold timer, and - changes its state to Established. - In response to any other event [Events 9, 12-13, 27-28], + In response to any other event [Events 9, 12-13, 20, 27-28], the local system: - sends a NOTIFICATION with a code of Finite State Machine Error, - - resets the connect retry timer (sets to zero) + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retrycount) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. Established State: In the Established state BGP can exchange UPDATE, NOTFICATION, and KEEPALIVE messages with its peer. Any start event (Event 1, 3-7) is ignored in the Established state. In response to a manual stop event (initiated by an operator)[Event2], the local sytem: - sends the NOTIFICATION message with Cease, - - resets the connect retry timer to zero (0), + - sets the Connect Retry timer to zero, - delete all routes associated with this connection, - release BGP resources, - drops TCP connection, - sets ConnectRetryCnt (connect retry count) to zero (0), and - changes its state to Idle. In response to an automatic stop event initiated by the system (automatic) [Event8], the local system: - sends a NOTIFICATION with Cease, - - resets the connect retry timer (sets to zero) + - sets the Connect Retry timer to zero - deletes all routes associated with this connection, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. An example automatic stop event is exceeding the number of prefixes for a given peer and the local system automatically disconnecting the peer. If the Hold timer expires [Event10], the local system: - sends a NOTIFICATION message with Error Code Hold Timer Expired, - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If the KeepAlive timer expires [Event11], the local system sends a KEEPALIVE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero. - Each time time the local system sends a KEEPALIVE or UPDATE + Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, unless the negotiated Hold Time value is zero. A TCP connection indication [Event 14] received for a valid port will cause the 2nd connection to be tracked. A TCP connection indications for invalid port [Event 15], will be ignored. @@ -2709,35 +2719,35 @@ or Event 17], the 2nd connection SHALL be tracked until it sends an OPEN message. If a valid OPEN message [Event 19] is received, it will be checked to see if it collides (Section 6.8) with any other session. If the BGP implementation determines that this connection needs to be terminated, it will process an open collision dump event[Event 23]. If this session needs to be terminated, the connection will be terminated by: - - send a NOTIFICATION with a Cease, - - resets the connect retry time (sets to zero), + - sends a NOTIFICATION with a Cease, + - sets the Connect Retry timer to zero, - deletes all routes associated with this connection, - - release all BGP resources, + - releases all BGP resources, - drops the TCP connection, - increments ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. If the local system receives a NOTIFICATION message [Event24 or Event 25] or a TCP connections fails [Event18] from the underlying TCP, it: - - resets the connect retry timer (sets to zero), - - delete all routes associated with this connection, + - sets the Connect Retry timer to zero, + - deletes all routes associated with this connection, - releases all the BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, and - changes its state to Idle. If the local system receives a KEEPALIVE message [Event 26], the local system will: - restarts its Hold Timer, if the negotiated Hold Time value is non-zero, and @@ -2747,35 +2757,35 @@ the local system will: - process the update packet - restarts its Hold timer, if the negotiated Hold Time value is non-zero, and - remain 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, - - resets the connect retry timer (sets to zero), + - sets the Connect Retry timer to zero, - delets all routes associated with this connection, - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, 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, - - resets the connect retry timer (sets to zero) + - sets the Connect Retry timer to zero - releases all BGP resources, - drops the TCP connection, - increments the ConnectRetryCnt (connect retry count) by 1, - optionally performs peer oscillation damping, and - changes its state to Idle. 9. UPDATE Message Handling An UPDATE message may be received only in the Established state. @@ -3210,21 +3222,21 @@ When a BGP speaker receives an UPDATE message from an internal peer, the receiving BGP speaker SHALL NOT re-distribute the routing infor- mation contained in that UPDATE message to other internal peers, unless the speaker acts as a BGP Route Reflector [RFC2796]. As part of Phase 3 of the route selection process, the BGP speaker has updated its Adj-RIBs-Out. All newly installed routes and all newly unfeasible routes for which there is no replacement route SHALL be advertised to its peers by means of an UPDATE message. - A BGP speaker SHOULT NOT advertise a given feasible BGP route from + A BGP speaker SHOULD NOT advertise a given feasible BGP route from its Adj-RIB-Out if it would produce an UPDATE message containing the same BGP route as was previously advertised. Any routes in the Loc-RIB marked as unfeasible SHALL be removed. Changes to the reachable destinations within its own autonomous sys- tem SHALL also be advertised in an UPDATE message. If due to the limits on the maximum size of an UPDATE message (see Section 4) a single route doesn't fit into the message, the BGP speaker MUST not advertise the route to its peers and MAY choose to @@ -3242,29 +3254,29 @@ The parameter MinRouteAdvertisementInterval determines the minimum amount of time that must elapse between advertisement and/or with- drawal of routes to a particular destination by a BGP speaker to a peer. This rate limiting procedure applies on a per-destination basis, although the value of MinRouteAdvertisementInterval is set on a per BGP peer basis. Two UPDATE messages sent by a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common - set of destinations MUST be separated by at least - MinRouteAdvertisementInterval. Clearly, this can only be achieved - precisely by keeping a separate timer for each common set of destina- - tions. This would be unwarranted overhead. Any technique which - ensures that the interval between two UPDATE messages sent from a BGP - speaker to a peer that advertise feasible routes and/or withdrawal of - unfeasible routes to some common set of destinations will be at least - MinRouteAdvertisementInterval, and will also ensure a constant upper - bound on the interval is acceptable. + set of destinations MUST be separated by at least MinRouteAdvertise- + mentInterval. Clearly, this can only be achieved precisely by keeping + a separate timer for each common set of destinations. This would be + unwarranted overhead. Any technique which ensures that the interval + between two UPDATE messages sent from a BGP speaker to a peer that + advertise feasible routes and/or withdrawal of unfeasible routes to + some common set of destinations will be at least MinRouteAdvertise- + mentInterval, and will also ensure a constant upper bound on the + interval is acceptable. Since fast convergence is needed within an autonomous system, either (a) the MinRouteAdvertisementInterval used for internal peers SHOULD be shorter than the MinRouteAdvertisementInterval used for external peers, or (b) the procedure describe in this section SHOULD NOT apply for routes sent to internal peers. This procedure does not limit the rate of route selection, but only the rate of route advertisement. If new routes are selected multiple times while awaiting the expiration of MinRouteAdvertisementInterval, @@ -3284,22 +3296,22 @@ BGP speaker may avail itself of several methods to organize this information in an efficient manner. 9.2.2.1 Information Reduction Information reduction may imply a reduction in granularity of policy control - after information is collapsed, the same policies will apply to all destinations and paths in the equivalence class. The Decision Process may optionally reduce the amount of information - that it will place in the Adj-RIBs-Out by any of the following - methods: + that it will place in the Adj-RIBs-Out by any of the following meth- + ods: a) Network Layer Reachability Information (NLRI): Destination IP addresses can be represented as IP address pre- fixes. In cases where there is a correspondence between the address structure and the systems under control of an autonomous system administrator, it will be possible to reduce the size of the NLRI carried in the UPDATE messages. b) AS_PATHs: @@ -3418,29 +3430,29 @@ fies the conditions and allows for more complex policy configu- rations. ATOMIC_AGGREGATE: If at least one of the routes to be aggregated has ATOMIC_AGGREGATE path attribute, then the aggregated route SHALL have this attribute as well. AGGREGATOR: Any AGGREGATOR attributes from the routes to be aggregated MUST - NOT be included in the aggregated route. The BGP speaker per- - forming the route aggregation MAY attach a new AGGREGATOR + NOT be included in the aggregated route. The BGP speaker + performing the route aggregation MAY attach a new AGGREGATOR attribute (see Section 5.1.7). 9.3 Route Selection Criteria - Generally speaking, additional rules for comparing routes among - several alternatives are outside the scope of this document. There - are two exceptions: + Generally speaking, additional rules for comparing routes among sev- + eral alternatives are outside the scope of this document. There are + two exceptions: - If the local AS appears in the AS path of the new route being considered, then that new route can not be viewed as better than any other route (provided that the speaker is configured to accept such routes). If such a route were ever used, a routing loop could result. - In order to achieve successful distributed operation, only routes with a likelihood of stability can be chosen. Thus, an AS SHOULD avoid using unstable routes, and it SHOULD NOT make rapid @@ -3537,21 +3549,21 @@ deprecated. UPDATE Message Error subcode 7 (AS Routing Loop) has been depre- cated. OPEN Message Error subcode 5 (Authentication Failure) has been deprecated. Use of the Marker field for authentication has been deprecated. - Use of TCP MD5 [RFC2385] for authentication is mandatory. + Implementations MUST support TCP MD5 [RFC2385] for authentication. Appendix B. Comparison with RFC1267 All the changes listed in Appendix A, plus the following. BGP-4 is capable of operating in an environment where a set of reach- able destinations may be expressed via a single IP prefix. The con- cept of network classes, or subnetting is foreign to BGP-4. To accommodate these capabilities BGP-4 changes semantics and encoding associated with the AS_PATH attribute. New text has been added to @@ -3753,22 +3766,21 @@ more than once within the aggregated AS_PATH attribute, all, but the last instance (rightmost occurrence) of that AS number SHOULD be removed from the aggregated AS_PATH attribute. Security Considerations The authentication mechanism that an implementation of BGP MUST sup- port is specified in [RFC2385]. The authentication provided by this mechanism could be done on a per peer basis. - Security issues with BGP routing information dissemination are dis- - cussed in [XXX]. + BGP vulnerabilities analysis is discussed in [XXX]. IANA Considerations All extensions to this protocol, including new message types and Path Attributes MUST only be made using the Standards Action process defined in [RFC2434]. Normative References [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Pro-