--- 1/draft-ietf-idr-bgp4-06.txt 2006-02-04 23:30:02.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-07.txt 2006-02-04 23:30:02.000000000 +0100 @@ -1,17 +1,17 @@ Network Working Group Y. Rekhter INTERNET DRAFT cisco Systems T. Li Juniper Networks Editors - June 1997 + Februrary 1998 A Border Gateway Protocol 4 (BGP-4) Status of this Memo This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter- autonomous system routing protocol for the Internet. This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please @@ -822,21 +822,20 @@ 6 - Unacceptable Hold Time. UPDATE Message Error subcodes: 1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute - 7 - AS Routing Loop. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH. Data: This variable-length field is used to diagnose the reason for the NOTIFICATION. The contents of the Data field depend upon the Error Code and Error Subcode. See Section 6 below for more @@ -1240,21 +1239,21 @@ discarded, and the Error Subcode is set to Optional Attribute Error. The Data field contains the attribute (type, length and value). If any attribute appears more than once in the UPDATE message, then the Error Subcode is set to Malformed Attribute List. The NLRI field in the UPDATE message is checked for syntactic validity. If the field is syntactically incorrect, then the Error Subcode is set to Invalid Network Field. - An UPDATE message that contains correct path attributes, but no NLRI + An UPDATE message that contains correct path attributes, but no NLRI, shall be treated as a valid UPDATE message. 6.4 NOTIFICATION message error handling. If a peer sends a NOTIFICATION message, and there is an error in that message, there is unfortunately no means of reporting this error via a subsequent NOTIFICATION message. Any such error, such as an unrecognized Error Code or Error Subcode, should be noticed, logged locally, and brought to the attention of the administration of the peer. The means to do this, however, lies outside the scope of this @@ -1397,21 +1396,21 @@ timeout), the local system restarts the ConnectRetry timer, continues to listen for a connection that may be initiated by the remote BGP peer, and changes its state to Active state. In response to the ConnectRetry timer expired event, the local system restarts the ConnectRetry timer, initiates a transport connection to other BGP peer, continues to listen for a connection that may be initiated by the remote BGP peer, and stays in the Connect state. - Start event is ignored in the Active state. + Start event is ignored in the Connect state. In response to any other event (initiated by either system or operator), the local system releases all BGP resources associated with this connection and changes its state to Idle. Active state: In this state BGP is trying to acquire a peer by initiating a transport protocol connection. @@ -1892,23 +1891,21 @@ If both a less and a more specific route are accepted, then the Decision Process MUST either install both the less and the more specific routes or it MUST aggregate the two routes and install the aggregated route. If a BGP speaker chooses to aggregate, then it MUST add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually - traverse only ASs listed in the AS_PATH attribute of the route. If a - BGP speaker chooses a), it must not advertise the more general route - without the more specific route. + traverse only ASs listed in the AS_PATH attribute of the route. 9.2 Update-Send Process The Update-Send process is responsible for advertising UPDATE messages to all peers. For example, it distributes the routes chosen by the Decision Process to other BGP speakers which may be located in either the same autonomous system or a neighboring autonomous system. Rules for information exchange between BGP speakers located in different autonomous systems are given in 9.2.2; rules for information exchange between BGP speakers located in the same @@ -2017,21 +2014,21 @@ MinRouteAdvertisementInterval. 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 single BGP speaker that advertise feasible routes to some common set of destinations received from external peers will be at least MinRouteAdvertisementInterval, and will also ensure a constant upper bound on the interval is acceptable. Since fast convergence is needed within an autonomous system, this - procedure does not apply for routes receives from other internal + procedure does not apply for routes received from other internal peers. To avoid long-lived black holes, the procedure does not apply to the explicit withdrawal of unfeasible routes (that is, routes whose destinations (expressed as IP prefixes) are listed in the WITHDRAWN ROUTES field of an UPDATE message). 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, the last route selected shall be advertised at the end of MinRouteAdvertisementInterval. @@ -2577,51 +2574,49 @@ path segment; this segment is then placed in between the two consecutive ASs identified in (a) of the aggregated attribute. If as a result of the above procedure a given AS number appears 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. References - [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC - 904, BBN, April 1984. + [1] Mills, D., "Exterior Gateway Protocol Formal Specification", + RFC904, April 1984. [2] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET - Backbone", RFC 1092, T.J. Watson Research Center, February 1989. + Backbone", RFC1092, February 1989. - [3] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093, - MERIT/NSFNET Project, February 1989. + [3] Braun, H-W., "The NSFNET Routing Architecture", RFC1093, February + 1989. [4] Postel, J., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, DARPA, September 1981. + Program Protocol Specification", RFC793, September 1981. [5] Rekhter, Y., and P. Gross, "Application of the Border Gateway - Protocol in the Internet", T.J. Watson Research Center, IBM Corp., - MCI, Internet Draft. + Protocol in the Internet", RFC1772, March 1995. [6] Postel, J., "Internet Protocol - DARPA Internet Program Protocol - Specification", RFC 791, DARPA, September 1981. + Specification", RFC791, September 1981. [7] "Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO/IEC IS10747, 1993 [8] Fuller, V., Li, T., Yu, J., and Varadhan, K., ""Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation - Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993 + Strategy", RFC1519, September 1993. [9] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation - with CIDR", RFC 1518, T.J. Watson Research Center, cisco, September - 1993 + with CIDR", RFC 1518, September 1993. Security Considerations Security issues are not discussed in this document. Editors' Addresses Yakov Rekhter cisco Systems, Inc. 170 W. Tasman Dr.