--- 1/draft-ietf-idr-bgp4-25.txt 2006-02-04 23:30:29.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-26.txt 2006-02-04 23:30:29.000000000 +0100 @@ -1,18 +1,17 @@ - Network Working Group Y. Rekhter INTERNET DRAFT T.Li Obsoletes: RFC1771 S. Hares 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. @@ -93,21 +92,22 @@ 6.2 OPEN message error handling . . . . . . . . . . . . . . . . . 32 6.3 UPDATE message error handling . . . . . . . . . . . . . . . . 33 6.4 NOTIFICATION message error handling . . . . . . . . . . . . . 35 6.5 Hold Timer Expired error handling . . . . . . . . . . . . . . 35 6.6 Finite State Machine error handling . . . . . . . . . . . . . 35 6.7 Cease . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.8 BGP connection collision detection . . . . . . . . . . . . . 36 7. BGP Version Negotiation . . . . . . . . . . . . . . . . . . . 37 8. BGP Finite State machine . . . . . . . . . . . . . . . . . . . 38 8.1 Events for the BGP FSM . . . . . . . . . . . . . . . . . . . 39 - 8.1.1 Optional Events linked to Optional Session attributes . . . 39 + 8.1.1 Optional Events linked to Optional Session attributes + . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1.2 Administrative Events . . . . . . . . . . . . . . . . . . 44 8.1.3 Timer Events . . . . . . . . . . . . . . . . . . . . . . . 47 8.1.4 TCP connection based Events . . . . . . . . . . . . . . . . 49 8.1.5 BGP Messages based Events . . . . . . . . . . . . . . . . . 51 8.2 Description of FSM . . . . . . . . . . . . . . . . . . . . . 53 8.2.1 FSM Definition . . . . . . . . . . . . . . . . . . . . . . 53 8.2.1.1 Terms "active" and "passive" . . . . . . . . . . . . . . 54 8.2.1.2 FSM and collision detection . . . . . . . . . . . . . . . 54 8.2.1.3 FSM and Optional Attributes . . . . . . . . . . . . . . 55 8.2.1.4 FSM Event numbers . . . . . . . . . . . . . . . . . . . . 55 @@ -169,22 +169,22 @@ support for advertising a set of destinations as an IP prefix and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths. Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP 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. + only the policies conforming to the destination-based forwarding par- + adigm. 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. @@ -719,22 +719,22 @@ of trailing bits is irrelevant. Total Path Attribute Length: This 2-octet unsigned integer indicates the total length of the Path Attributes field in octets. Its value allows the length of the Network Layer Reachability field to be determined as speci- fied below. A value of 0 indicates that neither the Network Layer Reacha- - bility Information field, nor the Path Attribute field is pre- - sent in this UPDATE message. + bility Information field, nor the Path Attribute field is + present in this UPDATE message. Path Attributes: A variable length sequence of path attributes is present in every UPDATE message, except for an UPDATE message that carries only the withdrawn routes. Each path attribute is a triple of variable length. Attribute Type is a two-octet field that consists of the @@ -3235,22 +3235,22 @@ wise, if the Adj-RIB-In has no route with NLRI identical to the new route, the new route SHALL be placed in the Adj-RIB-In. Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run its Decision Process. 9.1 Decision Process The Decision Process selects routes for subsequent advertisement by applying the policies in the local Policy Information Base (PIB) to - the routes stored in its Adj-RIBs-In. The output of the Decision Pro- - cess is the set of routes that will be advertised to peers; the + the routes stored in its Adj-RIBs-In. The output of the Decision + Process is the set of routes that will be advertised to peers; the selected routes will be stored in the local speaker's Adj-RIBs-Out according to policy. The BGP Decision Process described here is conceptual, and does not have to be implemented precisely as described here, as long as the implementations support the described functionality and their exter- nally visible behavior is the same. The selection process is formalized by defining a function that takes the attribute of a given route as an argument and returns either (a) @@ -3425,22 +3425,22 @@ ing the BGP route's NEXT_HOP. Mutually recursive routes (routes resolving each other or themselves), also fail the resolvability check. It is also important that implementations do not consider feasible routes that would become unresolvable if they were installed in the Routing Table even if their NEXT_HOPs are resolvable using the cur- rent contents of the Routing Table (an example of such routes would be mutually recursive routes). This check ensures that a BGP speaker does not install in the Routing Table routes that will be removed and - not used by the speaker. Therefore, in addition to local Routing - Table stability, this check also improves behavior of the protocol in + not used by the speaker. Therefore, in addition to local Routing Ta- + ble stability, this check also improves behavior of the protocol in the network. Whenever a BGP speaker identifies a route that fails the resolvabil- ity check because of mutual recursion, an error message SHOULD be logged. 9.1.2.2 Breaking Ties (Phase 2) In its Adj-RIBs-In a BGP speaker may have several routes to the same destination that have the same degree of preference. The local @@ -3508,23 +3508,23 @@ 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 route will not have MULTI_EXIT_DISC removed, then the MULTI_EXIT_DISC must be used in the comparison with IBGP learned routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used - in route comparisons which reach this step in the Decision Pro- - cess. Including the MULTI_EXIT_DISC of an EBGP learned route in - the comparison with an IBGP learned route, then removing the + in route comparisons which reach this step in the Decision + Process. Including the MULTI_EXIT_DISC of an EBGP learned route + in the comparison with an IBGP learned route, then removing the MULTI_EXIT_DISC attribute and advertising the route has been proven to cause route loops. d) If at least one of the candidate routes was received via EBGP, remove from consideration all routes which were received via IBGP. e) Remove from consideration any routes with less-preferred inte- rior cost. The interior cost of a route is determined by calcu- lating the metric to the NEXT_HOP for the route using the Routing Table. If the NEXT_HOP hop for a route is reachable, but no cost @@ -4279,67 +4279,74 @@ All the BGP messages contain an 8-bit message type, for which IANA is to create and maintain a registry entitled "BGP Message Types". This document defines the following message types: Name Value Definition ---- ----- ---------- OPEN 1 See Section 4.2 UPDATE 2 See Section 4.3 KEEPALIVE 3 See Section 4.4 NOTIFICATION 4 See Section 4.5 - Future assignment are to be made using the Standards Action process - defined in [RFC2434]. Assignments consist of a name and the value. + Future assignment are to be made using either the Standards Action + process defined in [RFC2434], or the Early IANA Allocation process + defined in [kompella-zinin]. Assignments consist of a name and the + value. The BGP UPDATE messages may carry one or more Path Attributes, where each Attribute contains an 8-bit Attribute Type Code. IANA is already maintaining such a registry, entitled "BGP Path Attributes". [note to IANA, the registry already exists at http://www.iana.org/assign- ments/bgp-parameters, but should be renamed per this document. XXX to be removed upon RFC publication.] This document defines the following Path Attributes Type Codes: Name Value Definition ---- ----- ---------- ORIGIN 1 See Section 5.1.1 AS_PATH 2 See Section 5.1.2 NEXT_HOP 3 See Section 5.1.3 MULTI_EXIT_DISC 4 See Section 5.1.4 LOCAL_PREF 5 See Section 5.1.5 ATOMIC_AGGREGATE 6 See Section 5.1.6 AGGREGATOR 7 See Section 5.1.7 - Future assignment are to be made using the Standards Action process - defined in [RFC2434]. Assignments consist of a name and the value. + Future assignment are to be made using either the Standards Action + process defined in [RFC2434], or the Early IANA Allocation process + defined in [kompella-zinin]. Assignments consist of a name and the + value. The BGP NOTIFICATION message carries an 8-bit Error Code, for which IANA is to create and maintain a registry entitled "BGP Error Codes". This document defines the following Error Codes: Name Value Definition ------------ ----- ---------- Message Header Error 1 Section 6.1 OPEN Message Error 2 Section 6.2 UPDATE Message Error 3 Section 6.3 Hold Timer Expired 4 Section 6.5 Finite State Machine Error 5 Section 6.6 Cease 6 Section 6.7 - Future assignment are to be made using the Standards Action process - defined in [RFC2434]. Assignments consist of a name and the value. + Future assignment are to be made using either the Standards Action process + defined in [RFC2434], or the Early IANA Allocation process defined + in [kompella-zinin]. Assignments consist of a name and the value. The BGP NOTIFICATION message carries an 8-bit Error Subcode, where each Subcode has to be defined within the context of a particular Error Code, and thus has to be unique only within that context. + IANA is to create and maintain a set of registries, "Error Subcodes", - with a separate registry for each BGP Error Code. Future assignments - are to be made using the Standards Action process defined in - [RFC2434]. Assignments consist of a name and the value. + with a separate registry for each BGP Error Code. Future assignment are + to be made using either the Standards Action process defined in [RFC2434], + or the Early IANA Allocation process defined in [kompella-zinin]. + Assignments consist of a name and the value. This document defines the following Message Header Error subcodes: Name Value Definition -------------------- ----- ---------- Connection Not Synchronized 1 See Section 6.1 Bad Message Length 2 See Section 6.1 Bad Message Type 3 See Section 6.1 This document defines the following OPEN Message Error subcodes: @@ -4409,23 +4416,23 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC2385, August 1998. [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC2434, October 1998 - [RFC2474] Nichols, K., et al.,"Definition of the Differentiated Ser- - vices Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, Decem- - ber 1998 + [RFC2474] Nichols, K., et al.,"Definition of the Differentiated + Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, + December 1998 Non-normative References [RFC904] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC904, April 1984. [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, @@ -4472,20 +4479,23 @@ 3563 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint [IS10747] "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Sup- port Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993 [BGP_VULN] Murphy, S., "BGP Security Vulnerabilities Analysis", draft-ietf-idr-bgp-vuln-00.txt, work in progress + [kompella-zinin] Kompella, K., Zinin, A., "Early IANA Allocation of + Standards Track Codepoints", Work in progress + Editors' Addresses Yakov Rekhter Juniper Networks email: yakov@juniper.net Tony Li email: tony.li@tony.li Susan Hares