draft-ietf-idr-bgp-multisession-05.txt   draft-ietf-idr-bgp-multisession-06.txt 
Internet Engineering Task Force J. Scudder Internet Engineering Task Force J. Scudder
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track C. Appanna Intended status: Standards Track C. Appanna
Expires: September 24, 2010 Cisco Systems Expires: September 29, 2011 Cisco Systems
March 23, 2010 I. Varlashkin
Easynet Global Services
March 28, 2011
Multisession BGP Multisession BGP
draft-ietf-idr-bgp-multisession-05 draft-ietf-idr-bgp-multisession-06
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 facilitate the use of multiple BGP) by proposing a mechanism to facilitate the use of multiple
sessions between a given pair of BGP speakers. Each session is used sessions between a given pair of BGP speakers. Each session is used
to transport routes related by some session-based attribute such as to transport routes related by some session-based attribute such as
AFI/SAFI. This provides an alternative to the MP-BGP approach of AFI/SAFI. This provides an alternative to the MP-BGP approach of
multiplexing all routes onto a single connection. multiplexing all routes onto a single connection.
Use of this approach is expected to provide finer-grained fault Use of this approach is expected to provide finer-grained fault
management and isolation as the BGP protocol is used to support more management and isolation as the BGP protocol is used to support more
and more diverse services. and more diverse services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 This Internet-Draft will expire on September 29, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use of BGP Capability Advertisement . . . . . . . . . . . . . 5 3. Overview of operations . . . . . . . . . . . . . . . . . . . . 5
4. New NOTIFICATION Subcodes . . . . . . . . . . . . . . . . . . 6 4. Multisession BGP Capability Code . . . . . . . . . . . . . . . 6
5. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 5. New NOTIFICATION Subcodes . . . . . . . . . . . . . . . . . . 7
5.1. Using Multisession . . . . . . . . . . . . . . . . . . . . 8 6. Modified Connection Collision Handling . . . . . . . . . . . . 7
5.1.1. Initiating Connections . . . . . . . . . . . . . . . . 8 7. Connection establishment . . . . . . . . . . . . . . . . . . . 8
5.1.1.1. Continuing a Redirected Connection . . . . . . . . 10 8. Graceful restart . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Accepting Connections . . . . . . . . . . . . . . . . 10 9. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Collision Detection, Graceful Restart . . . . . . . . 11 10. Operational considerations . . . . . . . . . . . . . . . . . . 10
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 11. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
7. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 12 12. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Modifications to Connect State and Active State . . . . . 12 13. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Addition of WaitForOpen State, Deletion of OpenSent 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
State . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 17.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 17.2. Informative References . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Multisession usage scenarios . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 A.1. Single session on both sides . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 A.2. Single session on one side, multiple sessions on the
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 other . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. Multiple sessions based on AFI/SAFI . . . . . . . . . . . 15
A.4. Multiple sessions based on arbitrary BGP Capabilities . . 17
A.5. Process level separation of multiple sessions . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Most BGP [RFC4271] implementations only permit a single ESTABLISHED Most BGP [RFC4271] implementations only permit a single ESTABLISHED
connection to exist with each peer. More precisely, they only permit connection to exist with each peer. More precisely, they only permit
a single ESTABLISHED connection for any given pair of IP endpoints. a single ESTABLISHED connection for any given pair of IP endpoints.
BGP Capabilities [RFC5492] extend BGP to allow diverse information BGP Capabilities [RFC5492] extend BGP to allow diverse information
(encoded as "capabilities") to be associated with a session. In some (encoded as "capabilities") to be associated with a session. In some
cases, a capability may relate to the operation of the protocol cases, a capability may relate to the operation of the protocol
skipping to change at page 5, line 9 skipping to change at page 5, line 9
take place during the OPEN exchange phase of the session, there are take place during the OPEN exchange phase of the session, there are
no modifications to the operation of the protocol once a session no modifications to the operation of the protocol once a session
reaches ESTABLISHED state. reaches ESTABLISHED state.
Although AFI/SAFI is perhaps the most obvious way to group sets of Although AFI/SAFI is perhaps the most obvious way to group sets of
routes being exchanged between BGP peers, sessions can also be routes being exchanged between BGP peers, sessions can also be
distinguished by other BGP capabilities. In general, any capability distinguished by other BGP capabilities. In general, any capability
used in this fashion would be expected to have semantics of used in this fashion would be expected to have semantics of
identifying some common distinguishing characteristic of a set of identifying some common distinguishing characteristic of a set of
routes, just as AFI/SAFI does; however, specifics are beyond the routes, just as AFI/SAFI does; however, specifics are beyond the
scope of this document. For the sake of clarity, we generally use scope of this document. Most examples in this document are focusing
the MP-BGP capability (or interchangeably, AFI/SAFI) in this on MP-BGP capability (or interchangeably, AFI/SAFI) based grouping
document. Such use is illustrative and is not intended to be for simplicity reason. However actual application of multisessions
extension . Such use is illustrative and is not intended to be
limiting. 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 criteria that is used to define sessions. For example if AFI/SAFI
based sessions are desired then routers implementing this based sessions are desired then routers implementing this
specification MUST also implement MP-BGP [RFC4760]. specification MUST also implement MP-BGP [RFC4760].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 40 skipping to change at page 5, line 41
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 endpoints. When the AFI/SAFI is used to distinguish sessions, the
MP-BGP capability is the session identifier. MP-BGP capability is the session identifier.
A pair of session identifiers are said to conflict when considering 3. Overview of operations
them as two sets, there is an intersection between them either in the
capabilities or the values contained within the capabilities, but
neither is a subset of the other. For example, a pair of MP-BGP
capabilities is said to "conflict" when considering them as two sets
(of AFI/SAFI values), there is an intersection between the sets but
neither set is a subset of the other.
A BGP speaker is said to be the "active" speaker for a given To allow multiple sessions between same pair of BGP speakers to co-
connection if it was the party that initiated the transport open. exist BGP Multisession extension modifies Connection Collision
The active speaker's transport endpoint will typically use an Detection procedure of the base BGP specification (RFC4271). Rather
ephemeral port number. than considering only IP addresses of the peers new procedure also
takes into account list of certain session attributes, such as AFI/
SAFI, to determine uniqueness of the sessions. When sessions are
deemed to be unique each of them is then handled independently,
therefore critical conditions (such as malformed UPDATEs) in one
session won't affect others.
A BGP speaker is said to be the "passive" speaker for a given BGP Multisession extension introduces new BGP capability code to
connection if it was the party that received the transport open. The indicate that a BGP speaker supports protocol modification described
passive speaker's transport endpoint typically uses the well-known in this document and new error message sub-codes that facilitate
BGP port number, 179, but this document introduces an exception handling of incompatible configurations between two speakers.
detailed in Section 5.1.1.1.
3. Use of BGP Capability Advertisement Following sections provide formal description of the protocol
enhancement. Additionally, Appendix contains non-normative examples
of desired behaviour for Multisession-enabled BGP speakers, which is
intended only for illustrative purpose.
4. Multisession BGP Capability Code
This specification defines the Multisession capability [RFC5492]: This specification defines the Multisession capability [RFC5492]:
Capability code (1 octet): 68 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 Capability value (1 octet): Flags followed by the list of
capabilities 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|R| Reserved | |G| Reserved | Session Id ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number (if R is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One or more Capability codes (1 octet each) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
capability values into one session. When set (value 1) this bit
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 G - the most significant bit was originally intended by earlier draft
indicates that the sender wishes to continue the current BGP session version of Multisession specification to denote capability of a BGP
using a different transport endpoint. This entails the active speaker to group multiple capability values into one session. As
speaker dropping the current session and starting a fresh one using this information can be deduced from Session Id, the use of G bit is
the proposed endpoint; this is detailed in Section 5.1.1.1 below. deprecated - implementations conforming to final version of
When set, the transport endpoint information is encoded in the port Multisession specification SHOULD NOT rely on value of the G bit.
number field of the capability as detailed below.
The remaining bits are reserved, and should be set to zero by the Reserved - MUST be set to zero by sender, MUST be ignored by receiver
sender and ignored by the receiver.
If the R bit is set, following the reserved bits is the two-octet TCP Session Id(entifier) - list of zero or more capability codes (1 octet
port number to which the passive speaker wishes to redirect the each) defined in BGP, whose values will be used to distinguish one
session. group from another. The size of the list is inferred from the length
of the overall capability; it is the capability length minus one.
The Multisession capability code itself MUST NOT be listed; if listed
it MUST be ignored upon receipt.
Following the reserved bits and the transport endpoint information if Empty Session Id list and Session Id containing 1 (one, Multiprotocol
present is a list of one or more Capability codes defined in BGP. Extensions) as the only value are considered equal and indicate that
The size of the list is inferred from the length of the overall AFI/SAFI list in the OPEN message is used to distinguish the groups.
capability; it is the capability length minus one if the R bit is not However, if BGP speaker wishes to use compound Session Id that
set, or minus three if the R bit is set. The capabilities listed includes AFI/SAFI list as one of the components, then Capability Code
specify which capabilities in the OPEN message comprise the session 1 MUST be explicitly included in the Session Id. For example, if BGP
identifier. The Multisession capability code itself MUST NOT be speaker Session Id to 'X' (denoting Capability Foo) then only Foo
listed; if listed it MUST be ignored upon receipt. will be used as Session Id, i.e. session where Foo is 1 and AFI/SAFI
is 1/1 and session where Foo is 1 and AFI/SAFI is 1/2 will be
considered as conflicting. On the other hand Session Id set to '1 X'
or 'X 1' indicates that groups are identified by combination of Foo
and AFI/SAFI, i.e. above two sessions as well as session where Foo is
2 and AFI/SAFI is 2/4 will be considered unique.
For example, peers wishing to establish sessions based on AFI/SAFI For given pair of BGP peers Multisession capability MUST be used
would exchange the Multiprotocol Extensions capability code (1) only either on all or none sessions. This is required due to different
in the list. In this case the Multisession capability would have a connection collision handling procedure used by multisession.
length of two octets, or four octets if redirect is being requested.
4. New NOTIFICATION Subcodes 5. New NOTIFICATION Subcodes
BGP [RFC4271] 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 specific to OPEN message.
This specification introduces five new subcodes:
OPEN Message Error subcodes:
7 - Capability Value Mismatch
8 - Grouping Conflict
9 - Grouping Required
10 - Redirecting Now
11 - Redirect Required
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
one or more capabilities whose values conflict with the values of one
or more capability groups configured on the local BGP speaker. The
Data field MUST indicate one of the conflicting locally-configured
capability group, encoded as the appropriate capabilities.
The Grouping Required code MAY be used when a BGP speaker that is
configured to require grouping attempts to establish a connection
with a BGP speaker that 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.)
If the MP-BGP capability is used as the session identifier, the
notifications could be used as follows:
Capability Value Mismatch MAY be used when an OPEN message contains
one or more MP-BGP capabilities, none of which lists an AFI/SAFI
supported by the local BGP speaker. It is observed that this subcode
may be useful for MP-BGP speakers in general, even if they do not
(otherwise) implement this specification.
The Grouping Conflict code MAY be used when an OPEN message contains
several MP-BGP capabilities whose AFI/SAFI conflict with one or more
AFI/SAFI groups configured on the local BGP speaker. The Data field
MUST indicate one of the conflicting locally-configured AFI/SAFI
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.")
Use of the Redirecting Now and Redirect Required codes is detailed in
Section 5.1.1.1.
The use of these subcodes is further elaborated below.
5. Overview of Operation
The operation section is divided into two main subsections.
The "Using Multisession" sections below discuss the BGP speaker's
behavior when the peer does support this specification or is assumed
to. The "Backward Compatibility" section discusses the BGP speaker's
behavior when the peer does not support this specification, or is
assumed not to. Both sections also discuss how to switch to the
other mode.
A BGP speaker that supports this specification MUST always advertise This specification introduces three new subcodes for OPEN Message
the Multisession capability, regardless of its peer's known or Error code:
presumed capability set.
In all cases until a BGP speaker has initiated or accepted one 7 - Capability Value Mismatch - Session Id mismatch, i.e.
connection from a given peer, it is unknown whether the peer supports remote speaker whishes to use different capability codes in
this specification or not. Two strategies can be considered for Session Id compare to local speaker
making this initial determination -- either the BGP speaker can
initially assume that the peer does not support this specification,
and switch modes if it is discovered that it does, or vice-versa.
Either approach is acceptable.
As discussed previously, this section describes the operation from 8 - Grouping Conflict - values of capability codes used in
the point of view of the MP-BGP capability and the associated AFI/ Session Id of the received message cannot be unambiguously
SAFI values as the session identifier. It can be replaced with any mapped to a locally configured group
other capability or groups of capabilities without any changes to the
behavior described below.
Note that if a BGP speaker only wishes to support a single AFI/SAFI 9 - Grouping Required (from earlier drafts, perhaps should be
in its communications with a given peer only one session is needed in removed if not used)
any case, and so the "multisession" feature is moot. In such a case
the behavior required would be indistinguishable from that given in
the "backward compatibility" section below. In the illustrative
examples in the following sections, it is generally assumed that a
BGP speaker does wish to support multiple AFI/SAFI in its
communications with a given peer.
5.1. Using Multisession BGP implementations conforming to this specification SHOULD use new
sub-codes as described further down in section "Connection
establishment" of this document.
The following subsections discuss a BGP speaker's behavior towards a 6. Modified Connection Collision Handling
peer that is known or assumed to support this specification.
5.1.1. Initiating Connections BGP speaker conforming to and actively using this specification MUST
use modified connection collision handling procedure as described in
this section.
When a BGP speaker (the "active" speaker) attempts BGP communication Two sessions are said to collide if and only if both of following
with its peer (the "passive" speaker), it initiates one connection conditions are true:
per group of AFI/SAFI it wishes to support. (This implies that a new
local TCP port will be allocated for each new connection.) The OPEN
sent on each connection MUST include the Multisession capability and
one or more MP-BGP capabilities indicating the AFI/SAFI to be
supported on that session. If a non-trivial group of AFI/SAFI (i.e.,
a group of two or more) is proposed, the BGP speaker MUST also set
the G bit of the Multisession capability. Even if a trivial group of
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 1: the IP addresses on of peers are the same on both sessions
speaker may wish to use a separate BGP connection for each AFI/SAFI.
If the peer also supports this specification and also wishes to 2: values of capability codes used in session identifier are either
support the AFI/SAFI in question, it will respond with an OPEN that the same or overlapping (regardless fully or partially) within
includes the Multisession capability and the AFI/SAFI included in the given capability code
active speaker's OPEN. If the active speaker's OPEN included a non-
trivial group of AFI/SAFI that the peer supports, then the peer's
Multisession capability will have the G bit set.
If the peer also supports this specification and wishes to support Otherwise two sessions are considered unique and both MAY transition
some but not all of the AFI/SAFI in question, it will respond with an to the ESTABLISHED state (subject to rest of BGP specification).
OPEN that includes the Multisession capability and a subset of AFI/
SAFI included in the active speaker's OPEN. The reason for listing
only a subset may be because some of the AFI/SAFI are simply not
supported, or because the peer does not wish to support the AFI/SAFI
as a group (i.e. it may be configured to use a smaller group). In
this case, the BGP speaker MAY consider the set of AFI/SAFI that were
not included in the peer's OPEN to form a new group, and MAY try to
initiate a new session using that group.
If the peer also supports this specification but does not support Before attempting to create new session local system SHOULD evaluate
grouping, and a non-trivial group of AFI/SAFI has been proposed, then existing sessions with the same peer. If there is already a session
it will respond as given in the previous paragraph but with the with the same peer in ESTABLISHED state and new session would collide
additional proviso that the G bit will be clear. In this case, the with it, BGP speaker SHOULD NOT attempt creating new session; it's a
BGP speaker MAY accept the connection as given in the previous good idea to notify operator of the local system about such potential
paragraph, or it MAY reply with a NOTIFICATION message with ERROR collision.
Code OPEN Message Error and Error Subcode Grouping Required, and the
connection will be closed.
If the peer wishes to continue the BGP connection on a different Upon receipt of an OPEN messages BGP speaker MUST evaluate existing
transport endpoint, in addition to responding as detailed above, it sessions with the same peer. If there is already a session in
will set the R bit and will include the TCP port number that should ESTABLISHED state and multisession distinguisher values of the old
be used to continue the connection. See Section 5.1.1.1 for details and the new OPEN messages fully match, the old session remains and
regarding how this is handled. the new MUST be closed.
If the peer does not wish to support the AFI/SAFI in question, it If there is a session in OpenConfirm or OpenSent state and two
will reply with a NOTIFICATION message with Error Code OPEN Message sessions do not collide according to this document, then both
Error, and Error Subcode Capability Value Mismatch, and the sessions proceed as normally and section 6.8 of RFC4271 MUST NOT be
connection will be closed. applied. If on the other hand two sessions collide according to
definition of this document, then original procedure from section 6.8
of RFC4271 MUST be applied, except for the NOTIFICATION type.
Whereas original specification prescribes to use 'Cease' error code,
multisession enabled BGP speaker SHOULD send NOTIFICATION message as
described in this document.
A BGP speaker MUST NOT attempt to initiate connections for any AFI/ 7. Connection establishment
SAFI for which a connection already exists.
If the peer does not support this specification, it will respond with When BGP Multisession is enabled by configuration for given peer and
an OPEN that does not include the Multisession capability. In this configuration dictates that multiple sessions can potentially be
case the connection SHOULD be terminated, and future connections to established with given peer, BGP speaker MUST advertise Multisession
the peer should be attempted in the "backward compatibility" mode Capability code in the OPEN message on every session with given peer.
discussed in Section 6. In all other cases Multisession capability SHOULD NOT be advertised.
The value of Session Id MUST be the same on every session.
5.1.1.1. Continuing a Redirected Connection When Multisession-enabled BGP speaker receives an OPEN message
without BGP Multisession Capability code it MUST assume that peer is
not capable of multiple sessions and MUST use original Connection
Collision Detection procedure as described in section 6.8 of RFC4271.
When the active speaker receives an OPEN from the passive speaker When Multisession-enabled BGP speaker receives an OPEN message
that includes transport redirect information, it MUST reply with an containing BGP Multisession Capability Code but with Session Id not
Open Message Error NOTIFICATION with its subcode set to Redirecting matching its own Session Id, local BGP speaker MUST send NOTIFICATION
Now and close the session. Subsequently, it MUST attempt to initiate message with Error Code set to 2 ("OPEN Message Error") and Error
a new session using the transport endpoint that the passive speaker Sub-code set to 8 ("Grouping Conflict") and drop the session. If
has proposed in lieu of the original one (which typically would have received Session Id matches locally configured Session Id then BGP
been the well-known BGP port, 179). The new session should proceed speaker MUST verify whether this session would collide with any of
exactly as the original one did; that is, the active speaker SHOULD the existing as described in section "Modified Connection Collision
send an OPEN with the same content, and can expect to receive from Handling".
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 If session is allowed to continue by connection collision detection
session can be expected to be the same as or similar to those from procedure, the next step for local speaker is to find matching group
the previous session as discussed above, an implementation MUST NOT as follow:
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 1. If BGP capability code values used in Session Id of the received
active speaker is expected to drop the current session and initiate a message match exactly (i.e. for every value in the received OPEN
new one. If it does not do so, the passive speaker MAY elect to message there is corresponding value in a locally configured
continue the session, or it MAY elect to terminate the session by group) then local BGP speaker proceeds with this session
sending a Redirect Required NOTIFICATION.
5.1.2. Accepting Connections 2. If values in the received message do not match any of the locally
configured groups exactly, but there is one and only one locally
configured group such that for every capability code the
intersection between received and local values is non-empty set,
then this group is selected for continuing the session. Note,
such partial match results in behaviour similar to non-
multisession BGP when capability codes overlap partially.
Rationale behind allowing only one group for partial matching is
that it simplifies specification and implementation; from
operational perspective multiple partially matching groups
suggest significant descrepancy in configuration between peers
and therefore unlikely to be required in real-life networks.
When processing a connection attempt, the BGP speaker MUST wait until 3. In all other cases local BGP speaker MUST send NOTIFICATION
the peer's OPEN message has been received before proceeding. This is message with Error Code set to 2 (OPEN Message Error) and Error
at variance with the behavior specified in the finite state machine Sub-code set to 8 (Grouping conflict).
(FSM) of [RFC4271], but is interoperable with that FSM. The FSM
changes are specified in Section 7.
Once the peer's OPEN message has been received, if it includes the Once local BGP speaker has identified which locally configured group
Multisession capability and one or more MP-BGP capabilities corresponds to received OPEN message it proceeds with the session
indicating a group of AFI/SAFI that the BGP speaker wishes to like it would have been regular non-multisession one, particularly -
support, then the BGP speaker responds with an OPEN message that the original Finite State Machine applies. BGP speaker is free to
includes the Multisession capability and one or more MP-BGP handle such session either in the same process/thread as the one that
capabilities indicating the same AFI/SAFI. received OPEN message, or it can hand over connection to another
process/thread. If uses, the connection handover is local-matter of
BGP implementation and not part of this specification. Appendix
contains an example how such handover could be done.
If the OPEN includes the Multisession capability and one or more MP- 8. Graceful restart
BGP capabilities indicating a group of AFI/SAFI that conflicts with
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 that
intersect with those proposed by the peer (in effect overriding the
locally configured set) or it MAY close the connection with a
NOTIFICATION message with Error Code OPEN Message Error and Error
Subcode Grouping Conflict. The former behavior is suggested as the
default if grouping is supported.
If the BGP speaker does not support AFI/SAFI grouping it MAY reply With respect to Section 4.2 of BGP Graceful Restart [RFC4724], when
with an OPEN listing one of the AFI/SAFI out of those proposed by the determining whether a new connection BGP speaker evaluate values of
peer. It MUST also set the G bit in the Multisession capability to all capability codes used in Session Identifier.
zero.
If the passive speaker wishes to continue the session for this 9. Error handling
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 multisession-enabled BGP speaker detects an error condition that
indicating an AFI/SAFI the BGP speaker wishes to support, it SHOULD warrants session reset, it SHOULD reset only session that was
close the connection with a NOTIFICATION message with Error Code OPEN affected by the error. Resetting other sessions with the same peer
Message Error and Error Subcode Capability Value Mismatch. would significantly diminish value of multisession extensions.
If the received OPEN message does not include the Multisession 10. Operational considerations
capability, then the peer does not support this specification. The
connection MAY be continued in the "backward compatibility" mode
discussed in Section 6, or it MAY be terminated and future
connections to the peer attempted in the "backward compatibility"
mode.
5.1.3. Collision Detection, Graceful Restart Multisession feature SHOULD be disabled by default. BGP
implementation SHOULD provide configuration-time option to enable
multisession extension on per-peer basis. If BGP implementation
supports non-trivial groups, then it SHOULD provide configuration-
time option for operator to control how sessions are grouped. An
example of such option would be possibility for an operator to
specify which address families will be carried in one session, and
which address families will be carried in another session.
[RFC4271] Section 6.8 (BGP connection collision detection) considers BGP implementation supporting multisession extension SHOULD allow
a pair of connections to have collided if the source and destination operator to view state of each individual group and at least last
IP addresses of both connections match. With respect to peers that NOTIFICATION message that caused connection reset.
support this specification, the AFI/SAFI groups associated with the
connections must also intersect for them to be considered to have
collided.
This consideration also applies to Section 4.2 of BGP Graceful For the sake of interoperability between BGP speakers supporting
Restart [RFC4724], when determining whether a new connection should multisession, an implementation SHOULD NOT impose hard-coded
be considered equivalent to a reset of a previous TCP session. restrictions on groups based on particular Session Id are put
together. If such restrictions are unavoidable, then BGP
implementation MUST support at least trivial groups based on that
attribute. Let's consider this on an example. If implementation A
requires AFI/SAFI 1/1 and 1/4 to be always carried within same
session, while implementation B requires AFI/SAFI 1/4 to be always
carried only with 1/128 and not with any other, then it's not
possible to establish session between such BGP speakers. However if
implementations A and B both allow each AFI/SAFI to be carried each
in its own group, then we can establish three sessions - one for AFI/
SAFI 1/1, another one for AFI/SAFI 1/4 and third one for AFI/SAFI
1/128.
6. Backward Compatibility 11. Backward Compatibility
This subsection discusses a BGP speaker's behavior towards a peer This subsection discusses a BGP speaker's behavior towards a peer
that 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 [RFC4271] and otherwise defined for the BGP protocol, according to [RFC4271] and
any other extension supported by the BGP speaker. any other extension supported by the BGP speaker.
If a BGP speaker receives OPEN message that doesn't include
Multisession Capability and local BGP speaker is required to use
multisession (e.g. through configuration by operator), the local BGP
speaker MUST drop the session and send appropriate NOTIFICATION
message as described in Section 5. If multisession is not required,
local BGP speaker proceeds with multisession extension disabled, so
it appears as regular implementation to the peer.
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 that
includes the Multisession capability is received from the peer, then
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 --
If the BGP speaker has not yet sent an OPEN to the peer, then the
connection MAY be continued in the "multisession" mode discussed
above, or it MAY be terminated and future connections to the peer
attempted in "multisession" mode.
If the BGP speaker has sent an OPEN to the peer, then the current
session SHOULD be terminated and future connections to the peer
attempted in "multisession" mode.
Use of techniques such as dynamic capabilities Use of techniques such as dynamic capabilities
[I-D.ietf-idr-dynamic-cap] for on-the-fly switching of session modes [I-D.ietf-idr-dynamic-cap] for on-the-fly switching of session modes
is beyond the scope of this document. is beyond the scope of this document.
7. State Machine 12. State Machine
As mentioned under "accepting connections" above, this specification
modifies the BGP finite state machine, albeit in a backward-
compatible fashion.
In addition, note that one state machine is considered to exist for This specification does not modify BGP FSM as such, but all
each of the connections that may exist to a given peer. This implies references to execution of collision handling procedure of original
that, for example, any session flap dampening that may exist is BGP specification are replaced with call to collision handling
performed per session identifier. procedure described in this document.
The specific state machine modifications to [RFC4271] Section 8.2.2 The specific state machine modifications to [RFC4271] Section 8.2.2
are as follows. are as follows.
7.1. Modifications to Connect State and Active State 13. Discussion
In the actions in response to the events Open Delay timer expires
[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
OpenSent.
7.2. Addition of WaitForOpen State, Deletion of OpenSent State
The WaitForOpen state is the same in all respects to OpenSent, except
for the action in response to reception of a valid OPEN message
[Event 19]. In that event, the local system sends an OPEN message
prior to sending a KEEPALIVE message.
The OpenSent state is deleted. All references to OpenSent are
replaced by references to WaitForOpen.
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 The specification supports the simple case of one capability being
skipping to change at page 14, line 44 skipping to change at page 12, line 21
AFI/SAFI onto BGP connections. For such grouping to function AFI/SAFI onto BGP connections. For such grouping to function
pleasingly, both peers participating in a connection need to agree on pleasingly, both peers participating in a connection need to agree on
what AFI/SAFI groupings will be used. If conflicting groupings are what AFI/SAFI groupings will be used. If conflicting groupings are
configured, the connections may not establish, or more connections configured, the connections may not establish, or more connections
may be established than were expected (in the degenerate case, one may be established than were expected (in the degenerate case, one
connection per AFI/SAFI could be established despite configured connection per AFI/SAFI could be established despite configured
groupings). We observe that the potential for misbehavior in the groupings). We observe that the potential for misbehavior in the
presence of conflicting configuration is not unusual in BGP, and that presence of conflicting configuration is not unusual in BGP, and that
support for, and configuration of grouping is purely optional. support for, and configuration of grouping is purely optional.
9. Security Considerations 14. Security Considerations
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.
In other respects, this document does not change the BGP security This document does not change the BGP security model.
model.
10. Acknowledgements 15. Acknowledgements
The authors would like to thank Pedro Marques, Keyur Patel, Robert The authors would like to thank Martin Djernaes, Pedro Marques, Keyur
Raszuk, Yakov Rekhter and David Ward for their valuable comments. Patel, Robert Raszuk, Yakov Rekhter, David Ward and Anton Elita for
their valuable comments.
11. IANA Considerations 16. IANA Considerations
IANA has allocated BGP Capability Code 68 as the Multisession BGP IANA has allocated BGP Capability Code 68 as the Multisession BGP
Capability. Capability.
This document requests IANA to allocate five new OPEN Message Error This document requests IANA to allocate three new OPEN Message Error
subcodes: subcodes:
7 - Capability Value Mismatch 7 - Capability Value Mismatch
8 - Grouping Conflict 8 - Grouping Conflict
9 - Grouping Required 9 - Grouping Required
10 - Redirecting Now 17. References
17.1. Normative References
11 - Redirect Required
12. References
12.1. Normative References
[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.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007. January 2007.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, February 2009.
12.2. Informative References 17.2. Informative References
[I-D.ietf-idr-dynamic-cap] [I-D.ietf-idr-dynamic-cap]
Chen, E. and S. Ramachandra, "Dynamic Capability for Chen, E. and S. Ramachandra, "Dynamic Capability for
BGP-4", draft-ietf-idr-dynamic-cap-10 (work in progress), BGP-4", draft-ietf-idr-dynamic-cap-12 (work in progress),
January 2010. October 2010.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. September 2000.
Appendix A. Multisession usage scenarios
This section demonstrates usage of Multisession Extension in several
common scenarios. All examples presented here for illustrative
purpose only, they're not part of Multisession specification.
A.1. Single session on both sides
BGP Speaker A and BGP Speaker B are both configured to exchange IPv4
unicast (AFI=1, SAFI=1) and IPv4 L3VPN (AFI=1, SAFI=128) prefixes
over single session. If Multisession extension is disabled by
configuration on both sides, then the session is, from every
perspective, indistinguishable from ordinary (non-multisession) BGP
peering. If only one of the speakers is enabled (through
configuration) for multisession and yet only with one session to
multiplex both AFI/SAFI, then again only single session is
established and it looks like normal session. Although multisession-
enabled BGP speaker is capable of processing new NOTIFICATION sub-
codes, the other side (non-multisession) won't take advantage of it.
On the other hand use of new NOTIFICATION sub-codes isn't necessary
in this situation because both sides keep all AFI/SAFI within same
session. Finally, if both speakers are multisession-enabled, they
still setup single session, but now they can use new NOTIFICATION
sub-codes for more sophisticated error handling.
Note that if both speakers configured to use only single session and
their respective AFI/SAFI lists overlap but do not match exactly,
then like with ordinary (non-multisession) BGP speakers the session
will transition to ESTABLISHED state. It's possible that one of the
speakers (or both) require exact match of AFI/SAFI lists in order to
establish session (either by implementation or through
configuration). In this case such speaker will send NOTIFICATION
message with Error Code 2 (OPEN Message Error) and Sub-code 8
(Grouping conflict) and subsequently close the session.
A.2. Single session on one side, multiple sessions on the other
In this setup Speaker A is configured to carry IPv4 unicast (AFI=1,
SAFI=1) and IPv4 L3VPN (AFI=1, SAFI=128) prefixes within single
session, while Speaker B is configured with two sessions - one for
IPv4 unicast and second for IPv4 L3VPN. Several scenarios are
possible depending on which speaker sends OPEN message first and
whether Speaker A is multisession-enabled or not.
Assuming Speaker A is not multisession-enabled, it sends OPEN message
first and there is no existing session between these two peers.
Speaker B determines that OPEN message lists both AFI/SAFI and it
knows that it wants to split them into different sessions, therefore
it's obvious that setup cannot function as intended. Since
separation of two address families into two groups is performed by
operator (as per Multisession Extension specification), the most
appropriate action is to prevent any communication between Speaker A
and B until operator intervenes and resolves the conflict in
configuration. To do this BGP Speaker B sends NOTIFICATION message
with Error Code 6 (because peer is not expected to understand new
notification sub-codes). Would Speaker A be multisession enabled,
then Speaker B would send NOTIFICATION message with Error Code 1 and
Error Subcode 9 (Grouping Required).
Now let's consider reverse situation - the Speaker B sends an OPEN
message for either AFI/SAFI first. Assuming Speaker A is not
multisession-enabled, it will accept OPEN message containing either
AFI/SAFI and will reply with OPEN message containing both AFI/SAFI.
Although session might transitions for a brief period to ESTABLISHED
state, the Speaker B upon receipt of the OPEN message will detect
misconfiguration and send NOTIFICATION message with Error Code 6 as
in previous paragraph. Would Speaker A be multisession-enabled, it
could detect misconfiguration on its own and send NOTIFICATION
message with Error Code 1 and Error Subcode 8 (Grouping conflict).
There is possibility that Speaker A opens one TCP connection and
sends its OPEN message, and simultaneously Speaker B opens one or two
TCP connection(s) and sends OPEN message on each of them. Since
Speaker A is not multisession-enabled, it will invoke original
collision detection procedure and will drop one of the sessions.
Speaker B seeing NOTIFICATION message with Cease error code concludes
that Speaker A is not multisession-capable and that setup prescribed
by Speaker B's configuration cannot be achieved. Depending on
implementation of Speaker B a session for one of the AFI/SAFI may
progress to ESTABLISHED state, but Speaker B will inform operator
about incompatible configuration.
It's also possible that initially Speaker B has been configured with
only one AFI/SAFI, e.g. IPv4 unicast. The session between two peers
would come up as described in previous subsection. Now suppose
Speaker B is configured with additional session to carry IPv4 L3VPN
prefixes. Since Speaker A does not have multiple sessions
configured, it won't send another OPEN message as long as first
session is in ESTABLISHED state. Therefore it's only possible that
Speaker B will attempt establishing second connection and send new
OPEN message containing only IPv4 L3VPN AFI/SAFI. If Speaker A is
non-multisession enabled, it will drop second session sending
NOTIFICATION message. From this Speaker B can conclude that
configuration of two sides is incompatible, will stop attempting to
bring up IPv4 L3VPN session and will notify operator. Already
ESTABLISHED session may remain unaffected (subject to Speaker B
implementation), just like with non-multisession speakers.
A.3. Multiple sessions based on AFI/SAFI
This is most common use of multisession extension is to separate
prefixes based on AFI/SAFI. Note that use of AFI/SAFI based groups
is denoted by empty Optional Data field in Multisession Capability,
which is the same as in previous two sections. Grouping
configuration is devised from the list of actually advertised AFI/
SAFI lists (MP-BGP Capability). This will be demonstrated in
following examples.
Let's consider BGP Speaker A and BGP Speaker B both configured to
exchange IPv4 unicast, IPv4 labelled-unicast and IPv4 L3VPN prefixes
each in its own session. We start with no existing sessions between
these speakers. Speaker A (though roles can reverse) sends OPEN
message in which among other capabilities it announces MP-BGP
Capability for AFI=1 SAFI=1 and Multisession Capability with empty
optional data field. Speaker B upon receipt of such message finds
that it expects to exchange IPv4 unicast with Speaker B in a
dedicated session. It accepts connection and sends similar OPEN
message to Speaker A. As there were no existing sessions, collision
handling procedure is not invoked at this time. Next Speaker A (but
again it could be Speaker B) starts new TCP connection to Speaker B
and sends OPEN message with MP-BGP Capability for AFI=1 SAFI=4 and
Multisession Capability with empty optional data field. Speaker B is
willing to exchange IPv4 labelled-unicast too, but before accepting
the proposal it executes collision detection procedure. Since AFI/
SAFI lists of the old (ESTABLISHED) and of the new sessions are
different, the sessions don't collide and, sending OPEN message with
AFI=1 SAFI=4, the Speaker B brings second session to ESTABLISHED
state. In the same way third session, for AFI=1 SAFI=128, is brought
up.
Note that similar behaviour will be also observed if two speakers
send OPEN messages simultaneously - modified collision handling
procedure, introduced by Multisession Extension specification, will
mark sessions as unique based on the difference in Session Id
(different AFI/SAFI lists). If Speaker A opens TCP connection and
sends an OPEN message for either AFI/SAFI, and simultanously Speaker
B opens TCP connection and send OPEN message for the same AFI/SAFI,
then modified collision handling procedure will resolve the conflict
just like original procedure would do in non-multisession
environment. Yet modified collision handling procedure allows
sessions with distinct Session Id's to coexist without affecting each
other. This behaviour applies also to more complex cases where
groups include more AFI/SAFI or based on different Capability Codes
all together. For this reason collision handling is not discussed in
remaining scenarios.
Now suppose Speaker A configuration is as above, but Speaker B is
configured to combine labelled-unicast and L3VPN prefixes into the
same session. IPv4 session is brought up as above. Next there are
two possible alternatives. Either Speaker A sends OPEN message for
one of the remaining sessions, to which Speaker B responds with
NOTIFICATION message Error Code 2 and Error Subcode 8. Or Speaker B
sends OPEN message for combined session including both of the
remaining address families, to which Speaker A responds either with
exactly the same NOTIFICATION message. At the end only IPv4 session
remains in ESTABLISHED state, while two other address families
require operator's intervention for configuring either Speaker A with
combined session for labelled-unicast and L3VPN, or Speaker B for one
session per AFI/SAFI. Note that if Speaker B would have used an
implementation that requires that labelled-unicast and L3VPN address-
families are combined into single session, then behaviour of each
side would be exactly as above.
If Speaker A wouldn't have L3VPN configuration for Speaker B at all,
then whether second session would progress to ESTABLISHED or not
depends on whether configuration of either side requires exact match
between groups (by default implementations expected to mimim original
BGP behaviour which will bring overlapping AFI/SAFI up, but won't
require exact match, but some implementation may provide
configuration knob to require exact match).
Finally we look at the case where AFI/SAFI lists of different
configured sessions overlap. Suppose Speaker A is configured with
following groups: group 1 AFI=1 SAFI=1, group 2 AFI=1 SAFI=4 and
SAFI=128, group 3 AFI=2 SAFI=4; and Speaker B is configured as: group
1 AFI=1 SAFI=1, group 2 AFI=1 SAFI=4, group 3 AFI=1 SAFI=128 and
AFI=2 SAFI=4. For simplicity sake we assume that group 1 is brought
up first. Both speakers behave as already described in previous
case. Next let Speaker A to be the first to setup second TCP session
and send OPEN message for group 2. Applying collision handling
procedure as defined in Multisession specification Speaker B
continues processing of received OPEN message. If Speaker B is
configured for strict match between the groups, then it will detect
incompatibility of AFI/SAFI list between the received message and its
own configuration, therefore it will send NOTIFICATION message with
Error Code 2 and Error Subcode 8. If on the other hand Speaker B
allows partial overlapping of received and its own AFI lists (as
regular BGP implementation would in absence of multisession), it will
reply with OPEN message that lists AFI=1 SAFI=4 and session
potentially progresses to ESTABLISHED state provided that Speaker A
doesn't require exact match on AFI/SAFI list. Similar applies to the
session 3 for the remaining AFI/SAFI. Note that configuration for
exact or partial match between AFI/SAFI lists is the same for all
sessions between given peers.
A.4. Multiple sessions based on arbitrary BGP Capabilities
Although grouping based on arbitrary attributes is the most
comprehensive scenario, the behaviour of the BGP speakers is
essentially the same as in case of AFI/SAFI based groups. However
arbitrary groups do add extra complexity because BGP speakers need to
consider not only values of single capability, but need to agree upon
Capability Codes that constitute Session Id. Following example
demonstrates behaviour of multisession-enabled BGP speakers in
situation where Session Id on each side is based on different
capabilities.
Let's suppose there is imaginery Capability Code X that denotes
Experiment Id, and two speakers would like to exchange IPv4 unicast
and L3VPN prefixes for two experiments. Speaker A would like to
group prefixes into separate sessions based solely on Experiment Id
(so two sessions with two AFI/SAFI in each), while Speaker B would
like to have separate session per experiment per AFI/SAFI (so four
sessions with one AFI/SAFI in each). Since Session Id involves
attribute other than AFI/SAFI, the Optional Data field in
Multisession Capability will be non-empty. Multisession Capability
sent by Speaker A will contain only 'Experiment Id Capability Code'
in the Optional Data, whereas Speaker B will put there both
"Experiment Id Capability Code" and "MP-BGP (AFI/SAFI)". When either
speaker receives OPEN message from the peer, it will notice mismatch
between content of the Optional Data field and, since sessions cannot
be established as intended, the speaker will send NOTIFICATION
message with Error Code 2 and Subcode 7 after which session will be
dropped. Both speakers will notify operator and will suppress
further attempt to bring session up until configuration of either
side changes.
Note that despite Multisession Capability does not containing a field
to denote support for non-AFI/SAFI based groups, even an
implementation that does not support groups based on arbitrary
capability codes will be able to recognise configuration mismatch and
provide sufficient information to the peer as described above.
A.5. Process level separation of multiple sessions
As fault isolation is the key motivation for the Multisession
Extension it's natural to consider process-level separation between
the sessions. Although Multisession specification itself does not
prescribe any particular way of handling each session, BGP
implementations can leverege IPC facilities provided by host
operating systems to handover arbitrary session to appropriate
process. For example, many systems can pass connection from the
process that accepted TCP connection to a process dedicated for
particular group using specially crafted message on Unix socket.
This is somewhat acking to inetd, but based on content of the OPEN
message (e.g. AFI/SAFI list) rather than on transport protocol
properties (e.g. TCP/UDP port numbers). At one extrimity the
process that initially accepts TCP connection may be very primitive
and can leave even connection collision handling to a specializing
process, on the other hand process could handle collision detection
itself or even handle particular group on its own while passing only
specific group to another process. This process level separation is
local implementation business and does not require specific aid from
BGP at protocol specification level. Therefore process level
separation is not part of multisession specification.
Authors' Addresses Authors' Addresses
John G. Scudder John G. Scudder
Juniper Networks Juniper Networks
Email: jgs@juniper.net Email: jgs@juniper.net
Chandra Appanna Chandra Appanna
Cisco Systems Cisco Systems
Email: achandra@cisco.com Email: achandra@cisco.com
Ilya Varlashkin
Easynet Global Services
Email: ilya.varlashkin@easynet.net
 End of changes. 69 change blocks. 
390 lines changed or deleted 515 lines changed or added

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