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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/