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

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