draft-ietf-idr-bgp-multisession-03.txt   draft-ietf-idr-bgp-multisession-04.txt 
Network Working Group John G Scudder Internet Engineering Task Force J. Scudder
Internet Draft Juniper Networks Internet-Draft Juniper Networks
Expiration Date: June 2007 Chandra Appanna Intended status: Standards Track C. Appanna
File name: draft-ietf-idr-bgp-multisession-03.txt Cisco Systems Expires: January 13, 2010 Cisco Systems
January 2007 July 12, 2009
Multisession BGP Multisession BGP
draft-ietf-idr-bgp-multisession-03.txt draft-ietf-idr-bgp-multisession-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Internet-Drafts are draft documents valid for a maximum of six Drafts.
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This specification augments "Multiprotocol Extensions for BGP-4" [MP- This specification augments "Multiprotocol Extensions for BGP-4" (MP-
BGP] by proposing a mechanism to allow multiple sessions to be used BGP) by proposing a mechanism to facilitate the use of multiple
between a given pair of BGP speakers. Each session is used to sessions between a given pair of BGP speakers. Each session is used
transport routes for one or more AFI/SAFI. This provides an to transport routes related by some session-based attribute such as
alternative to the current [MP-BGP] approach of multiplexing routes AFI/SAFI. This provides an alternative to the MP-BGP approach of
for all AFI/SAFI onto a single connection. multiplexing all routes onto a single connection.
Use of this approach is expected to increase the robustness of the Use of this approach is expected to provide finer-grained fault
BGP protocol as it is used to support more and more diverse AFI/SAFI. management and isolation as the BGP protocol is used to support more
and more diverse services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use of BGP Capability Advertisement . . . . . . . . . . . . . 6
4. New NOTIFICATION Subcodes . . . . . . . . . . . . . . . . . . 7
5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8
5.1. Using Multisession . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Initiating Connections . . . . . . . . . . . . . . . . 9
5.1.1.1. Continuing a Redirected Connection . . . . . . . . 11
5.1.2. Accepting Connections . . . . . . . . . . . . . . . . 11
5.1.3. Collision Detection, Graceful Restart . . . . . . . . 12
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
7. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Modifications to Connect State and Active State . . . . . 13
7.2. Addition of WaitForOpen State, Deletion of OpenSent
State . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Most BGP [BGP, BGP-DRAFT] implementations only permit a single Most BGP [RFC4271] implementations only permit a single ESTABLISHED
ESTABLISHED connection to exist with each peer. More precisely, they connection to exist with each peer. More precisely, they only permit
only permit a single ESTABLISHED connection for any given pair of IP a single ESTABLISHED connection for any given pair of IP endpoints.
endpoints.
Multiprotocol BGP [MP-BGP] extends BGP to allow information for BGP Capabilities [RFC5492] extend BGP to allow diverse information
(encoded as "capabilities") to be associated with a session. In some
cases, a capability may relate to the operation of the protocol
machinery; an example is Route Refresh [RFC2918]. However, in other
cases a capability may relate specifically to some common
distinguishing characteristic of the routes carried over the session;
an example is Multiprotocol BGP [RFC4760].
Multiprotocol BGP [RFC4760] extends BGP to allow information for
multiple NLRI families and sub-families to be transported in BGP. multiple NLRI families and sub-families to be transported in BGP.
Routes for different families are distinguished by AFI and SAFI. Routes for different families are distinguished by AFI and SAFI.
Routes for different families are commonly multiplexed onto a single Routes for different families are commonly multiplexed onto a single
BGP session. BGP session.
A common criticism of BGP is the fact that most malformed messages A common criticism of BGP is the fact that most malformed messages
cause the session to be terminated. While this behavior is necessary cause the session to be terminated. While this behavior is necessary
for protocol correctness, one may observe that the protocol machinery for protocol correctness, one may observe that the protocol machinery
of a given implementation may only be defective with respect to a of a given implementation may only be defective with respect to a
given AFI/SAFI. Thus, it would be desirable to allow the session given AFI/SAFI. Thus, it would be desirable to allow the session
related to that family to be terminated while leaving other AFI/SAFI related to that family to be terminated while leaving other AFI/SAFI
unaffected. As BGP is commonly deployed, this is not possible. unaffected. As BGP is commonly deployed, this is not possible.
In this specification, we propose a mechanism by which multiple A second criticism of BGP is that it is difficult or in some cases
transport sessions may be established between a pair of peers. impossible to manage control plane resource contention when BGP is
used to support diverse services over a single session. In contrast,
Each transport session can be used for one or more AFI/SAFI. if a single BGP session carries only information for a single service
(or related set of services) it may be easier to manage such
contention.
While AFI/SAFI based sessions is one way to group data being exchanged In this specification, we propose a mechanism by which multiple
between BGP peers it is also possible to concieve of sessions being transport sessions may be established between a pair of peers. Each
based on other characteristics of the BGP data. In this draft we also transport session is identified by a distinct set of BGP
propose a scheme for creating multiple BGP sessions between BGP peers capabilities, notably the MP-BGP capability.
based on criteria other than AFI/SAFI. However, the definition of specific
criteria for grouping exchanged data into sessions is beyond the scope of
this proposal. The goal of this proposal is to provide a mechanism for
doing that if such criteria is available. For ease of understandability
and readability, AFI/SAFI will be used as an illustrative grouping
criteria through out the document.
Each session is distinct from a BGP protocol point of view; an error Each session is distinct from a BGP protocol point of view; an error
or other event on one session has no implications for any other session. or other event on one session has no implications for any other
All protocol modifications proposed by this specification take place session. All protocol modifications proposed by this specification
during the OPEN exchange phase of the session, there are no take place during the OPEN exchange phase of the session, there are
modifications to the operation of the protocol once a session reaches no modifications to the operation of the protocol once a session
ESTABLISHED state. reaches ESTABLISHED state.
Although AFI/SAFI is perhaps the most obvious way to group sets of
routes being exchanged between BGP peers, sessions can also be
distinguished by other BGP capabilities. In general, any capability
used in this fashion would be expected to have semantics of
identifying some common distinguishing characteristic of a set of
routes, just as AFI/SAFI does; however, specifics are beyond the
scope of this document. For the sake of clarity, we generally use
the MP-BGP capability (or interchangeably, AFI/SAFI) in this
document. Such use is illustrative and is not intended to be
limiting.
Routers implementing this specification MUST also implement the base Routers implementing this specification MUST also implement the base
criteria that is used to define sessions. For example if AFI/SAFI based criteria that is used to define sessions. For example if AFI/SAFI
sessions are desired then peers implementing this specification MUST based sessions are desired then routers implementing this
also implement [MP-BGP]. specification MUST also implement MP-BGP [RFC4760].
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Definitions 2. Definitions
"MP-BGP capability" refers to the capability [BGP-CAP] with code 1, "MP-BGP capability" refers to the capability [RFC5492] with code 1,
specified in [MP-BGP] section 10. specified in MP-BGP [RFC4760] section 8.
A BGP speaker is said to "support" some feature or functionality (for A BGP speaker is said to "support" some feature or functionality (for
example, to support this specification, or to support a particular example, to support this specification, or to support a particular
AFI/SAFI) when the BGP implementation supports the feature AND the AFI/SAFI) when the BGP implementation supports the feature AND the
feature has not been disabled by configuration. feature has not been disabled by configuration.
The Session Identifier is a capability or group of capabilities that The Session Identifier is a capability or group of capabilities that
will be used to differentiate individual BGP sessions between two IP will be used to differentiate individual BGP sessions between two IP
endpoints. When the AFI/SAFI is used to distinguish sessions, the MP-BGP endpoints. When the AFI/SAFI is used to distinguish sessions, the
capability is the session identifier. MP-BGP capability is the session identifier.
In this document the MP-BGP capability is used as a Session Identifier A pair of session identifiers are said to conflict when considering
for illustrative and explanatory purpose, i.e as the capability whose them as two sets, there is an intersection between them either in the
values differentiates the multiple session between two IP endpoints. capabilities or the values contained within the capabilities, but
MP-BGP and AFI/SAFI can be replaced by any other capability and the neither is a subset of the other. For example, a pair of MP-BGP
values of that capability to setup multiple sessions, without any capabilities is said to "conflict" when considering them as two sets
modifications to the procedures described. (of AFI/SAFI values), there is an intersection between the sets but
neither set is a subset of the other.
A pair of session indentifiers are said to conflict when considering the A BGP speaker is said to be the "active" speaker for a given
two groups as two sets, there is an intersection between the groups either connection if it was the party that initiated the transport open.
in the capabilities or the values in the capabilities, but neither session The active speaker's transport endpoint will typically use an
group is a subset of the other. For example, a pair of AFI/SAFI is said ephemeral port number.
to "conflict" when considering the two groups as two sets, there is an
intersection between the groups but neither group is a subset of the other. A BGP speaker is said to be the "passive" speaker for a given
connection if it was the party that received the transport open. The
passive speaker's transport endpoint typically uses the well-known
BGP port number, 179, but this document introduces an exception
detailed in Section 5.1.1.1.
3. Use of BGP Capability Advertisement 3. Use of BGP Capability Advertisement
This specification defines the Multisession capability [BGP-CAP]: This specification defines the Multisession capability [RFC5492]:
Capability code (1 octet): TBD Capability code (1 octet): 68
Capability length (1 octet): variable Capability length (1 octet): variable
Capability value (1 octet): Flags followed by the list of capabilities Capability value (1 octet): Flags followed by the list of
that define a session. capabilities that define a session.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|G| Reserved | |G|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number (if R is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more list of Capability codes (1 octet each) | | One or more Capability codes (1 octet each) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The most significant bit is defined as the Grouping Support (G) bit. The most significant bit is defined as the Grouping Support (G) bit.
It can be used to indicate support for the ability to group multiple It can be used to indicate support for the ability to group multiple
capabilty values into one session. When set (value 1) this bit indicates capability values into one session. When set (value 1) this bit
that the BGP speaker supports grouping. indicates that the BGP speaker supports grouping. An example of
grouping is if a BGP speaker wishes to use one session for AFI/SAFI
values 1/1, 1/2 and 1/4, and another for AFI/SAFI values 2/1, 2/2 and
2/4.
The next bit is defined as the Redirect (R) bit. When set, it
indicates that the sender wishes to continue the current BGP session
using a different transport endpoint. This entails the active
speaker dropping the current session and starting a fresh one using
the proposed endpoint; this is detailed in Section 5.1.1.1 below.
When set, the transport endpoint information is encoded in the port
number field of the capability as detailed below.
The remaining bits are reserved, and should be set to zero by the The remaining bits are reserved, and should be set to zero by the
sender and ignored by the receiver. sender and ignored by the receiver.
Following the reserved bits is a list of one or more Capability codes If the R bit is set, following the reserved bits is the two-octet TCP
defined in BGP. The capabilities listed here represent the session port number to which the passive speaker wishes to redirect the
identifier for sessions between the BGP speakers. session.
For example peers wishing to establish sessions based on AFI/SAFI would Following the reserved bits and the transport endpoint information if
exchange the Multiprotocol Extensions capability code (1) only in the present is a list of one or more Capability codes defined in BGP.
list. In this case the Multisession capability would have a length of The size of the list is inferred from the length of the overall
2 octets. capability; it is the capability length minus one if the R bit is not
set, or minus three if the R bit is set. The capabilities listed
specify which capabilities in the OPEN message comprise the session
identifier. The Multisession capability code itself MUST NOT be
listed; if listed it MUST be ignored upon receipt.
For example, peers wishing to establish sessions based on AFI/SAFI
would exchange the Multiprotocol Extensions capability code (1) only
in the list. In this case the Multisession capability would have a
length of two octets, or four octets if redirect is being requested.
4. New NOTIFICATION Subcodes 4. New NOTIFICATION Subcodes
[BGP, BGP-DRAFT] Section 4.5 provides a number of subcodes to the BGP [RFC4271] Section 4.5 provides a number of subcodes to the
NOTIFICATION message, and Section 6.2 elaborates on the use of those NOTIFICATION message, and Section 6.2 elaborates on the use of those
subcodes. subcodes.
This specification introduces two new subcodes: This specification introduces five new subcodes:
OPEN Message Error subcodes: OPEN Message Error subcodes:
7 - No Supported Capability Value. 7 - Capability Value Mismatch
8 - Grouping Conflict 8 - Grouping Conflict
9 - Grouping Required 9 - Grouping Required
The No Supported Capability Value code MAY be used when an OPEN message 10 - Redirecting Now
contains one or more capabilities, none of which list an
capability supported by the local BGP speaker. It is observed that 11 - Redirect Required
this subcode may be useful for BGP speakers in general, even if
they do not (otherwise) implement this specification. The Capability Value Mismatch code MAY be used when an OPEN message
received contains one or more capabilities whose values are
inconsistent with the corresponding capabilities of the local BGP
speaker. The Data field MUST list the offending capability code(s).
The Grouping Conflict code MAY be used when an OPEN message contains The Grouping Conflict code MAY be used when an OPEN message contains
several capabilities whose values conflict with one or more one or more capabilities whose values conflict with the values of one
capability groups configured on the local BGP speaker. The Data field or more capability groups configured on the local BGP speaker. The
SHOULD indicate one of the conflicting locally-configured capability Data field MUST indicate one of the conflicting locally-configured
groups, encoded as theh appropriate capabilities. capability group, encoded as the appropriate capabilities.
The Grouping Required code MAY be used when a BGP speaker which is The Grouping Required code MAY be used when a BGP speaker that is
configured to require grouping attempts to establish a connection configured to require grouping attempts to establish a connection
with a BGP speaker which does not support grouping. (While it is with a BGP speaker that does not support grouping. (While it is true
true that it might be possible to communicate much the same that it might be possible to communicate much the same information
information using the Unsupported Capability NOTIFICATION message, using the Unsupported Capability NOTIFICATION message, this more
this more explicit method is felt to be more transparent.) explicit method is felt to be more transparent.)
If MP-BGP capability is used as the session identifier, the notification If the MP-BGP capability is used as the session identifier, the
codes could be used as follows: notifications could be used as follows:
The No Supported Capability Value code MAY be used when an OPEN message Capability Value Mismatch MAY be used when an OPEN message contains
contains one or more MP-BGP capabilities, none of which list an one or more MP-BGP capabilities, none of which lists an AFI/SAFI
AFI/SAFI supported by the local BGP speaker. It is observed that supported by the local BGP speaker. It is observed that this subcode
this subcode may be useful for MP-BGP speakers in general, even if may be useful for MP-BGP speakers in general, even if they do not
they do not (otherwise) implement this specification. (otherwise) implement this specification.
The Grouping Conflict code MAY be used when an OPEN message contains The Grouping Conflict code MAY be used when an OPEN message contains
several MP-BGP capabilities whose AFI/SAFI conflict with one or more several MP-BGP capabilities whose AFI/SAFI conflict with one or more
AFI/SAFI groups configured on the local BGP speaker. The Data field AFI/SAFI groups configured on the local BGP speaker. The Data field
SHOULD indicate one of the conflicting locally-configured AFI/SAFI MUST indicate one of the conflicting locally-configured AFI/SAFI
groups, encoded as MP-BGP capabilities. groups, encoded as MP-BGP capabilities. (One might think of this as
indicating "I'm not willing to combine AFI/SAFI foo and bar as you've
tried to do.")
The Grouping Required code MAY be used when a BGP speaker which is Use of the Redirecting Now and Redirect Required codes is detailed in
configured to require grouping attempts to establish a connection Section 5.1.1.1.
with a BGP speaker which does not support grouping. (While it is
true that it might be possible to communicate much the same
information using the Unsupported Capability NOTIFICATION message,
this more explicit method is felt to be more transparent.)
The use of these subcodes is further elaborated below. The use of these subcodes is further elaborated below.
5. Overview of Operation 5. Overview of Operation
The operation section is divided into two main subsections. The operation section is divided into two main subsections.
The "Using Multisession" sections below discuss the BGP speaker's The "Using Multisession" sections below discuss the BGP speaker's
behavior when the peer does support this specification or is assumed behavior when the peer does support this specification or is assumed
to. The "Backward Compatibility" section discusses the BGP speaker's to. The "Backward Compatibility" section discusses the BGP speaker's
behavior when the peer does not support this specification, or is behavior when the peer does not support this specification, or is
assumed not to. Both sections also discuss how to switch to the other assumed not to. Both sections also discuss how to switch to the
mode. other mode.
A BGP speaker which supports this specification SHOULD always A BGP speaker that supports this specification MUST always advertise
advertise the Multisession capability, regardless of its peer's known the Multisession capability, regardless of its peer's known or
or presumed capability set. presumed capability set.
In all cases until a BGP speaker has initiated or accepted one connection In all cases until a BGP speaker has initiated or accepted one
from a given peer, it is unknown whether the peer supports this connection from a given peer, it is unknown whether the peer supports
specification or not. Two strategies can be considered for making this specification or not. Two strategies can be considered for
this initial determination -- either the BGP speaker can initially making this initial determination -- either the BGP speaker can
assume that the peer does not support this specification, and switch initially assume that the peer does not support this specification,
modes if it is discovered that it does, or vice-versa. Either and switch modes if it is discovered that it does, or vice-versa.
approach is acceptable. Either approach is acceptable.
Again for illustration, section 5.0 describes the operation from the As discussed previously, this section describes the operation from
point of view of the MP-BGP capability and the associated AFI/SAFI the point of view of the MP-BGP capability and the associated AFI/
values as the session identifier. It can be replaced with any other SAFI values as the session identifier. It can be replaced with any
capability or groups of capabilties without any changes to the behaviour other capability or groups of capabilities without any changes to the
described below. behavior described below.
Note that if a BGP speaker only wishes to support a single AFI/SAFI Note that if a BGP speaker only wishes to support a single AFI/SAFI
in its communications with a given peer only one session is needed in in its communications with a given peer only one session is needed in
any case, and so the "multisession" feature is moot. In such a case any case, and so the "multisession" feature is moot. In such a case
the behavior required would be indistinguishable from that given in the behavior required would be indistinguishable from that given in
the "backward compatibility" section below. In the illustrative examples the "backward compatibility" section below. In the illustrative
in the following sections, it is generally assumed that a BGP speaker examples in the following sections, it is generally assumed that a
does wish to support multiple AFI/SAFI in its communications with a BGP speaker does wish to support multiple AFI/SAFI in its
given peer. communications with a given peer.
5.1. Using Multisession: 5.1. Using Multisession
The following subsections discuss a BGP speaker's behavior towards a The following subsections discuss a BGP speaker's behavior towards a
peer which is known or assumed to support this specification. peer that is known or assumed to support this specification.
5.1.1. Initiating Connections: 5.1.1. Initiating Connections
When a BGP speaker attempts BGP communication with its peer, it When a BGP speaker (the "active" speaker) attempts BGP communication
initiates one connection per group of AFI/SAFI it wishes to support. with its peer (the "passive" speaker), it initiates one connection
(This implies that a new local TCP port will be allocated for each per group of AFI/SAFI it wishes to support. (This implies that a new
new connection.) The OPEN sent on each connection MUST include the local TCP port will be allocated for each new connection.) The OPEN
Multisession capability and one or more MP-BGP capabilities sent on each connection MUST include the Multisession capability and
indicating the AFI/SAFI to be supported on that session. If a non- one or more MP-BGP capabilities indicating the AFI/SAFI to be
trivial group of AFI/SAFI (i.e., a group of two or more) is proposed, supported on that session. If a non-trivial group of AFI/SAFI (i.e.,
the BGP speaker MUST also set the G bit of the Multisession a group of two or more) is proposed, the BGP speaker MUST also set
capability. Even if a trivial group of AFI/SAFI is proposed, the G the G bit of the Multisession capability. Even if a trivial group of
bit SHOULD be set if grouping is supported. AFI/SAFI is proposed, the G bit SHOULD be set if grouping is
supported. The active speaker MUST NOT set the R bit nor include an
associated TCP port number.
Note that any "group of AFI/SAFI" may be a singleton group, i.e. the Note that any "group of AFI/SAFI" may be a singleton group, i.e. the
speaker may wish to use a separate BGP connection for each AFI/SAFI. speaker may wish to use a separate BGP connection for each AFI/SAFI.
If the peer also supports this specification and also wishes to If the peer also supports this specification and also wishes to
support the AFI/SAFI in question, it will respond with an OPEN which support the AFI/SAFI in question, it will respond with an OPEN that
includes the Multisession capability and the AFI/SAFI included in the includes the Multisession capability and the AFI/SAFI included in the
active speaker's OPEN. If the active speaker's OPEN included a non- active speaker's OPEN. If the active speaker's OPEN included a non-
trivial group of AFI/SAFI which the peer supports, then the peer's trivial group of AFI/SAFI that the peer supports, then the peer's
Multisession capability will have the G bit set. Multisession capability will have the G bit set.
If the peer also supports this specification and wishes to support If the peer also supports this specification and wishes to support
some but not all of the AFI/SAFI in question, it will respond with an some but not all of the AFI/SAFI in question, it will respond with an
OPEN which includes the Multisession capability and a subset of OPEN that includes the Multisession capability and a subset of AFI/
AFI/SAFI included in the active speaker's OPEN. The reason for SAFI included in the active speaker's OPEN. The reason for listing
listing only a subset may be because some of the AFI/SAFI are simply only a subset may be because some of the AFI/SAFI are simply not
not supported, or because the peer does not wish to support the supported, or because the peer does not wish to support the AFI/SAFI
AFI/SAFI as a group (i.e. it may be configured to use a smaller as a group (i.e. it may be configured to use a smaller group). In
group). In this case, the BGP speaker MAY consider the set of this case, the BGP speaker MAY consider the set of AFI/SAFI that were
AFI/SAFI which were not included in the peer's OPEN to form a new not included in the peer's OPEN to form a new group, and MAY try to
group, and MAY try to initiate a new session using that group. initiate a new session using that group.
If the peer also supports this specification but does not support If the peer also supports this specification but does not support
grouping, and a non-trivial group of AFI/SAFI has been proposed, then grouping, and a non-trivial group of AFI/SAFI has been proposed, then
it will respond as given in the previous paragraph but with the it will respond as given in the previous paragraph but with the
additional proviso that the G bit will be clear. In this case, the additional proviso that the G bit will be clear. In this case, the
BGP speaker MAY accept the connection as given in the previous BGP speaker MAY accept the connection as given in the previous
paragraph, or it MAY reply with a NOTIFICATION message with ERROR paragraph, or it MAY reply with a NOTIFICATION message with ERROR
Code OPEN Message Error and Error Subcode Grouping Required, and the Code OPEN Message Error and Error Subcode Grouping Required, and the
connection will be closed. connection will be closed.
If the peer wishes to continue the BGP connection on a different
transport endpoint, in addition to responding as detailed above, it
will set the R bit and will include the TCP port number that should
be used to continue the connection. See Section 5.1.1.1 for details
regarding how this is handled.
If the peer does not wish to support the AFI/SAFI in question, it If the peer does not wish to support the AFI/SAFI in question, it
will reply with a NOTIFICATION message with Error Code OPEN Message will reply with a NOTIFICATION message with Error Code OPEN Message
Error, and Error Subcode No Supported Capability value, and the connection Error, and Error Subcode Capability Value Mismatch, and the
will be closed. connection will be closed.
A BGP speaker SHOULD NOT attempt to initiate connections for any A BGP speaker MUST NOT attempt to initiate connections for any AFI/
AFI/SAFI for which a connection already exists. SAFI for which a connection already exists.
If the peer does not support this specification, it will respond with If the peer does not support this specification, it will respond with
an OPEN which does not include the Multisession capability. In this an OPEN that does not include the Multisession capability. In this
case the connection SHOULD be terminated, and future connections to case the connection SHOULD be terminated, and future connections to
the peer should be attempted in the "backward compatibility" mode the peer should be attempted in the "backward compatibility" mode
discussed below. discussed in Section 6.
5.1.2. Accepting Connections: 5.1.1.1. Continuing a Redirected Connection
When the active speaker receives an OPEN from the passive speaker
that includes transport redirect information, it MUST reply with an
Open Message Error NOTIFICATION with its subcode set to Redirecting
Now and close the session. Subsequently, it MUST attempt to initiate
a new session using the transport endpoint that the passive speaker
has proposed in lieu of the original one (which typically would have
been the well-known BGP port, 179). The new session should proceed
exactly as the original one did; that is, the active speaker SHOULD
send an OPEN with the same content, and can expect to receive from
the passive speaker an OPEN with the same content as previously with
the exception that the R bit should be clear and no associated port
number should be present. If the R bit is not clear it (and the
accompanying port number) SHOULD be disregarded.
Note that although the OPEN messages exchanged on the reinitiated
session can be expected to be the same as or similar to those from
the previous session as discussed above, an implementation MUST NOT
rely on or enforce this assumption when handling the received OPEN.
The new session MUST be handled as any other new session would be in
this respect.
As discussed above, when the passive speaker requests a redirect, the
active speaker is expected to drop the current session and initiate a
new one. If it does not do so, the passive speaker MAY elect to
continue the session, or it MAY elect to terminate the session by
sending a Redirect Required NOTIFICATION.
5.1.2. Accepting Connections
When processing a connection attempt, the BGP speaker MUST wait until When processing a connection attempt, the BGP speaker MUST wait until
the peer's OPEN message has been received before proceeding. This is the peer's OPEN message has been received before proceeding. This is
at variance with the behavior specified in the finite state machine at variance with the behavior specified in the finite state machine
(FSM) of [BGP-DRAFT], but is interoperable with that FSM. The FSM (FSM) of [RFC4271], but is interoperable with that FSM. The FSM
changes are specified in a later section. changes are specified in Section 7.
Once the peer's OPEN message has been received, if it includes the Once the peer's OPEN message has been received, if it includes the
Multisession capability and one or more MP-BGP capabilities Multisession capability and one or more MP-BGP capabilities
indicating a group of AFI/SAFI which the BGP speaker wishes to indicating a group of AFI/SAFI that the BGP speaker wishes to
support, then the BGP speaker responds with an OPEN message which support, then the BGP speaker responds with an OPEN message that
includes the Multisession capability and one or more MP-BGP includes the Multisession capability and one or more MP-BGP
capabilities indicating the same AFI/SAFI. capabilities indicating the same AFI/SAFI.
If the OPEN includes the Multisession capability and one or more MP- If the OPEN includes the Multisession capability and one or more MP-
BGP capabilities indicating a group of AFI/SAFI which conflicts with BGP capabilities indicating a group of AFI/SAFI that conflicts with
an AFI/SAFI grouping that has been configured on the BGP speaker then an AFI/SAFI grouping that has been configured on the BGP speaker then
the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI the BGP speaker MAY reply with an OPEN listing a set of AFI/SAFI that
which intersect with those proposed by the peer (in effect overriding intersect with those proposed by the peer (in effect overriding the
the locally configured set) or it MAY close the connection with a locally configured set) or it MAY close the connection with a
NOTIFICATION message with Error Code OPEN Message Error and Error NOTIFICATION message with Error Code OPEN Message Error and Error
Subcode Grouping Conflict. The former behavior is suggested as the Subcode Grouping Conflict. The former behavior is suggested as the
default if grouping is supported. default if grouping is supported.
If the BGP speaker does not support AFI/SAFI grouping it MAY reply If the BGP speaker does not support AFI/SAFI grouping it MAY reply
with an OPEN listing one of the AFI/SAFI out of those proposed by the with an OPEN listing one of the AFI/SAFI out of those proposed by the
peer. It SHOULD also set the G bit in the Multisession capability to peer. It MUST also set the G bit in the Multisession capability to
zero. zero.
If the passive speaker wishes to continue the session for this
particular grouping on a different port number, it sets the R bit in
its OPEN and includes the TCP port number on which it will continue
the session. The passive speaker MUST be prepared to accept a
connection on the given port immediately following transmission of
its OPEN.
If the received OPEN message does not include any MP-BGP capability If the received OPEN message does not include any MP-BGP capability
indicating an AFI/SAFI the BGP speaker wishes to support, it should indicating an AFI/SAFI the BGP speaker wishes to support, it SHOULD
close the connection with a NOTIFICATION message with Error Code OPEN close the connection with a NOTIFICATION message with Error Code OPEN
Message Error and Error Subcode No Supported Capability Value. Message Error and Error Subcode Capability Value Mismatch.
If the received OPEN message does not include the Multisession If the received OPEN message does not include the Multisession
capability, then the peer does not support this specification. The capability, then the peer does not support this specification. The
connection MAY be continued in the "backward compatibility" mode connection MAY be continued in the "backward compatibility" mode
discussed below, or it MAY be terminated and future connections to discussed in Section 6, or it MAY be terminated and future
the peer attempted in the "backward compatibility" mode. connections to the peer attempted in the "backward compatibility"
mode.
5.1.3. Collision Detection, Graceful Restart: 5.1.3. Collision Detection, Graceful Restart
[BGP, BGP-DRAFT] Section 6.8 (BGP connection collision detection) [RFC4271] Section 6.8 (BGP connection collision detection) considers
considers a pair of connections to have collided if the source and a pair of connections to have collided if the source and destination
destination IP addresses of both connections match. With respect to IP addresses of both connections match. With respect to peers that
peers which support this specification, the AFI/SAFI groups support this specification, the AFI/SAFI groups associated with the
associated with the connections must also intersect for them to be connections must also intersect for them to be considered to have
considered to have collided. collided.
This consideration also applies to Section 6.2 of [BGP-GR], when This consideration also applies to Section 4.2 of BGP Graceful
determining whether a new connection should be considered equivalent Restart [RFC4724], when determining whether a new connection should
to a reset of a previous TCP session. be considered equivalent to a reset of a previous TCP session.
5.2. Backward Compatibility: 6. Backward Compatibility
This subsection discusses a BGP speaker's behavior towards a peer This subsection discusses a BGP speaker's behavior towards a peer
which is known or assumed not to support this specification. In that is known or assumed not to support this specification. In
short, the BGP speaker's behavior towards such a peer should be as short, the BGP speaker's behavior towards such a peer should be as
otherwise defined for the BGP protocol, according to [BGP, BGP-DRAFT] otherwise defined for the BGP protocol, according to [RFC4271] and
and any other extension supported by the BGP speaker. any other extension supported by the BGP speaker.
As previously mentioned, the BGP speaker SHOULD always advertise the As previously mentioned, the BGP speaker SHOULD always advertise the
Multisession capability in its OPEN message, even towards "backward Multisession capability in its OPEN message, even towards "backward
compatibility" peers. compatibility" peers.
If, in opening a BGP connection with such a peer, an OPEN which If, in opening a BGP connection with such a peer, an OPEN that
includes the Multisession capability is received from the peer, then includes the Multisession capability is received from the peer, then
the peer SHOULD be changed to "multisession" mode. How this is done the peer SHOULD be changed to "multisession" mode. How this is done
depends on whether the BGP speaker has already sent an OPEN or not -- depends on whether the BGP speaker has already sent an OPEN or not --
If the BGP speaker has not yet sent an OPEN to the peer, then the If the BGP speaker has not yet sent an OPEN to the peer, then the
connection MAY be continued in the "multisession" mode discussed connection MAY be continued in the "multisession" mode discussed
above, or it MAY be terminated and future connections to the peer above, or it MAY be terminated and future connections to the peer
attempted in "multisession" mode. attempted in "multisession" mode.
If the BGP speaker has sent an OPEN to the peer, then the current If the BGP speaker has sent an OPEN to the peer, then the current
session SHOULD be terminated and future connections to the peer session SHOULD be terminated and future connections to the peer
attempted in "multisession" mode. attempted in "multisession" mode.
Use of techniques such as [BGP-DYN-CAP] for on-the-fly switching of Use of techniques such as dynamic capabilities
session modes are beyond the scope of this document. [I-D.ietf-idr-dynamic-cap] for on-the-fly switching of session modes
is beyond the scope of this document.
6. State Machine 7. State Machine
As mentioned under "accepting connections" above, this specification As mentioned under "accepting connections" above, this specification
modifies the BGP finite state machine, albeit in a backward- modifies the BGP finite state machine, albeit in a backward-
compatible fashion. compatible fashion.
In addition, note that one state machine is considered to exist for In addition, note that one state machine is considered to exist for
each of the connections which may exist to a given peer. This each of the connections that may exist to a given peer. This implies
implies that, for example, any session flap dampening that may exist that, for example, any session flap dampening that may exist is
is performed per session indetifier. performed per session identifier.
The specific state machine modifications to [BGP-DRAFT] Section 8.2.2 The specific state machine modifications to [RFC4271] Section 8.2.2
are as follows. are as follows.
6.1. Modifications to Connect State and Active State 7.1. Modifications to Connect State and Active State
In the actions in response to the events Open Delay timer expires In the actions in response to the events Open Delay timer expires
[Event 12] and TCP connection succeeds [Event 16 or Event 17], an [Event 12] and TCP connection succeeds [Event 16 or Event 17], an
OPEN is not sent and the state changes to WaitForOpen and not to OPEN is not sent and the state changes to WaitForOpen and not to
OpenSent. OpenSent.
6.2. Addition of WaitForOpen State, Deletion of OpenSent State 7.2. Addition of WaitForOpen State, Deletion of OpenSent State
The WaitForOpen state is the same in all respects to OpenSent, except The WaitForOpen state is the same in all respects to OpenSent, except
for the action in response to reception of a valid OPEN message for the action in response to reception of a valid OPEN message
[Event 19]. In that event, the local system sends an OPEN message [Event 19]. In that event, the local system sends an OPEN message
prior to sending a KEEPALIVE message. prior to sending a KEEPALIVE message.
The OpenSent state is deleted. All references to OpenSent are The OpenSent state is deleted. All references to OpenSent are
replaced by references to WaitForOpen. replaced by references to WaitForOpen.
7. Discussion 8. Discussion
Note that many BGP implementations already permit multiple sessions Note that many BGP implementations already permit multiple sessions
to be used between a given pair of routers, typically by configuring to be used between a given pair of routers, typically by configuring
multiple IP addresses on each router and configuring each session to multiple IP addresses on each router and configuring each session to
be bound to a different IP address. The principal contribution of be bound to a different IP address. The principal contribution of
this specification is to allow multiple sessions to be created this specification is to allow multiple sessions to be created
automatically, without additional configuration overhead or address automatically, without additional configuration overhead or address
consumption. consumption.
The specification supports the simple case of one capability being used The specification supports the simple case of one capability being
as the session identifier and one connection per session identifier value. used as the session identifier and one connection per session
It also permits connections be established based on the multiple identifier value. It also permits connections be established based
capabilties as a sessio identifier with multiple values per capability on multiple capabilities as a session identifier with multiple values
grouped together per connection. per capability grouped together per connection.
In the context of MP-BGP based connections, which we believe may be the In the context of MP-BGP based connections, which we believe may be
most prevalent use of this specification it permits supporting one the most prevalent use of this specification, it permits supporting
AFI/SAFI per connection, and also permits arbitrary grouping of AFI/SAFI one AFI/SAFI per connection, and also permits arbitrary grouping of
onto BGP connections. For such grouping to function pleasingly, both AFI/SAFI onto BGP connections. For such grouping to function
peers participating in a connection need to agree on what AFI/SAFI pleasingly, both peers participating in a connection need to agree on
groupings will be used. If conflicting groupings are configured, the what AFI/SAFI groupings will be used. If conflicting groupings are
connections may not establish, or more connections may be established configured, the connections may not establish, or more connections
than were expected (in the degenerate case, one connection per AFI/SAFI may be established than were expected (in the degenerate case, one
could be established despite configured groupings). We observe that connection per AFI/SAFI could be established despite configured
the potential for misbehavior in the presence of conflicting configuration groupings). We observe that the potential for misbehavior in the
is not unusual in BGP, and that support for, and configuration of grouping presence of conflicting configuration is not unusual in BGP, and that
is purely optional. support for, and configuration of grouping is purely optional.
8. Acknowledgements 9. Security Considerations
To be supplied. The ability to redirect to a port other than the well-known BGP port
implies that a legitimate BGP session may exist for which neither
port is equal to 179. This may have implications for firewall
filters used to protect the control processor.
9. References In other respects, this document does not change the BGP security
model.
[BGP4] 10. Acknowledgements
Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)," RFC
1771, March 1995.
[BGP-DRAFT] The authors would like to thank Pedro Marques, Keyur Patel, Robert
Rekhter, Y., T. Li and S. Hares, "A Border Gateway Protocol 4 Raszuk, Yakov Rekhter and David Ward for their valuable comments.
(BGP-4)," Work in Progress (draft-ietf-idr-bgp4-20), April 2003.
[MP-BGP] 11. IANA Considerations
Bates, T., R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten-
sions for BGP-4," Work in Progress (draft-ietf-idr-rfc2858bis-03),
July 2003.
[BGP-GR] IANA has allocated BGP Capability Code 68 as the Multisession BGP
Sangli, S., Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Capability.
Restart Mechanism for BGP," Work in Progress (draft-ietf-idr-
restart-06), January 2003.
[BGP-CAP] This document requests IANA to allocate five new OPEN Message Error
Chandra, R., J. Scudder, "Capabilities Advertisement with BGP-4," subcodes:
RFC 2842, May 2000.
[BGP-DYN-CAP] 7 - Capability Value Mismatch
Chen, E. and S. Sangli, "Dynamic Capability for BGP-4," Work in
Progress (draft-ietf-idr-dynamic-cap-03), December 2002.
10. Security Considerations 8 - Grouping Conflict
This document introduces no new security vulnerabilities to BGP or 9 - Grouping Required
other specifications referenced in this document.
11. IANA Considerations 10 - Redirecting Now
TBD 11 - Redirect Required
12. Authors' Addresses 12. References
John G. Scudder 12.1. Normative References
Juniper Networks
Email: jgs@juniper.net
Chandrashekhar (Chandra) Appanna [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Cisco Systems, Inc. Requirement Levels", BCP 14, RFC 2119, March 1997.
170 West Tasman Drive
San Jose, CA 95134
e-mail: achandra@cisco.com
13. Intellectual Property Statement [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
The IETF takes no position regarding the validity or scope of any [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Intellectual Property Rights or other rights that might be claimed to Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
pertain to the implementation or use of the technology described in January 2007.
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
assurances of licenses to be made available, or the result of an "Multiprotocol Extensions for BGP-4", RFC 4760,
attempt made to obtain a general license or permission for the use of January 2007.
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
copyrights, patents or patent applications, or other proprietary with BGP-4", RFC 5492, February 2009.
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
14. Disclaimer of Validity 12.2. Informative References
This document and the information contained herein [I-D.ietf-idr-dynamic-cap]
are provided on an "AS IS" basis and THE CONTRIBUTOR, THE Chen, E. and S. Sangli, "Dynamic Capability for BGP-4",
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE draft-ietf-idr-dynamic-cap-09 (work in progress),
INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM November 2006.
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
15. Copyright Statement [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
Copyright (C) The Internet Society (2007). This document is subject Authors' Addresses
to the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights. John G. Scudder
Juniper Networks
Email: jgs@juniper.net
Chandra Appanna
Cisco Systems
Email: achandra@cisco.com
 End of changes. 104 change blocks. 
288 lines changed or deleted 408 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/