Internet Engineering Task Force                               J. Scudder
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                              C. Appanna
Expires: September 24, 2010 29, 2011                                Cisco Systems
                                                           I. Varlashkin
                                                 Easynet Global Services
                                                          March 23, 2010 28, 2011

                            Multisession BGP
                   draft-ietf-idr-bgp-multisession-05
                   draft-ietf-idr-bgp-multisession-06

Abstract

   This specification augments "Multiprotocol Extensions for BGP-4" (MP-
   BGP) by proposing a mechanism to facilitate the use of multiple
   sessions between a given pair of BGP speakers.  Each session is used
   to transport routes related by some session-based attribute such as
   AFI/SAFI.  This provides an alternative to the MP-BGP approach of
   multiplexing all routes onto a single connection.

   Use of this approach is expected to provide finer-grained fault
   management and isolation as the BGP protocol is used to support more
   and more diverse services.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   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
   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."

   The list of current Internet-Drafts can be accessed at
   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. 29, 2011.

Copyright Notice

   Copyright (c) 2010 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4  5
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Use  Overview of BGP Capability Advertisement operations . . . . . . . . . . . . . . . . . . . .  5
   4.  Multisession BGP Capability Code . . . . . . . . . . . . . . .  6
   5.  New NOTIFICATION Subcodes  . . . . . . . . . . . . . . . . . .  6
   5.  Overview of Operation  7
   6.  Modified Connection Collision Handling . . . . . . . . . . . .  7
   7.  Connection establishment . . . . . . . . . .  7
     5.1.  Using Multisession . . . . . . . . .  8
   8.  Graceful restart . . . . . . . . . . .  8
       5.1.1.  Initiating Connections . . . . . . . . . . . . 10
   9.  Error handling . . . .  8
         5.1.1.1.  Continuing a Redirected Connection . . . . . . . . 10
       5.1.2.  Accepting Connections . . . . . . . . . . . . 10
   10. Operational considerations . . . . 10
       5.1.3.  Collision Detection, Graceful Restart . . . . . . . . 11
   6. . . . . . . 10
   11. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11
   7.
   12. State Machine  . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Modifications to Connect State and Active State 11
   13. Discussion . . . . . . . 12
     7.2.  Addition of WaitForOpen State, Deletion of OpenSent
           State . . . . . . . . . . . . . . . . . . . 11
   14. Security Considerations  . . . . . . . . . 13
   8.  Discussion . . . . . . . . . . 12
   15. Acknowledgements . . . . . . . . . . . . . . . . 13
   9.  Security . . . . . . . 12
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . 12
   17. References . . . . . . . . . . . . . . . . . . . . . . 14
   11. IANA Considerations . . . . 13
     17.1. Normative References . . . . . . . . . . . . . . . . . 14
   12. . . 13
     17.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Multisession usage scenarios  . . . . . . . . . . 14
     12.1. Normative References . . 13
     A.1.  Single session on both sides . . . . . . . . . . . . . . . 13
     A.2.  Single session on one side, multiple sessions on the
           other  . . 14
     12.2. Informative References . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 18

1.  Introduction

   Most BGP [RFC4271] implementations only permit a single ESTABLISHED
   connection to exist with each peer.  More precisely, they only permit
   a single ESTABLISHED connection for any given pair of IP endpoints.

   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.
   Routes for different families are distinguished by AFI and SAFI.
   Routes for different families are commonly multiplexed onto a single
   BGP session.

   A common criticism of BGP is the fact that most malformed messages
   cause the session to be terminated.  While this behavior is necessary
   for protocol correctness, one may observe that the protocol machinery
   of a given implementation may only be defective with respect to a
   given AFI/SAFI.  Thus, it would be desirable to allow the session
   related to that family to be terminated while leaving other AFI/SAFI
   unaffected.  As BGP is commonly deployed, this is not possible.

   A second criticism of BGP is that it is difficult or in some cases
   impossible to manage control plane resource contention when BGP is
   used to support diverse services over a single session.  In contrast,
   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.

   In this specification, we propose a mechanism by which multiple
   transport sessions may be established between a pair of peers.  Each
   transport session is identified by a distinct set of BGP
   capabilities, notably the MP-BGP capability.

   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.  All protocol modifications proposed by this specification
   take place during the OPEN exchange phase of the session, there are
   no modifications to the operation of the protocol once a session
   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  Most examples in this document are focusing
   on MP-BGP capability (or interchangeably, AFI/SAFI) in this
   document. based grouping
   for simplicity reason.  However actual application of multisessions
   extension .  Such use is illustrative and is not intended to be
   limiting.

   Routers implementing this specification MUST also implement the base
   criteria that is used to define sessions.  For example if AFI/SAFI
   based sessions are desired then routers implementing this
   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

   "MP-BGP capability" refers to the capability [RFC5492] with code 1,
   specified in MP-BGP [RFC4760] section 8.

   A BGP speaker is said to "support" some feature or functionality (for
   example, to support this specification, or to support a particular
   AFI/SAFI) when the BGP implementation supports the feature AND the
   feature has not been disabled by configuration.

   The Session Identifier is a capability or group of capabilities that
   will be used to differentiate individual BGP sessions between two IP
   endpoints.  When the AFI/SAFI is used to distinguish sessions, the
   MP-BGP capability is the session identifier.

   A

3.  Overview of operations

   To allow multiple sessions between same pair of session identifiers are said BGP speakers to conflict when considering
   them as two sets, there is an intersection between them either in the
   capabilities or the values contained within co-
   exist BGP Multisession extension modifies Connection Collision
   Detection procedure of the capabilities, but
   neither is a subset base BGP specification (RFC4271).  Rather
   than considering only IP addresses of the other.  For example, a pair peers new procedure also
   takes into account list of MP-BGP
   capabilities is said to "conflict" when considering them certain session attributes, such as two sets
   (of AFI/SAFI values), there is an intersection between the sets but
   neither set is a subset AFI/
   SAFI, to determine uniqueness of the other.

   A BGP speaker is said sessions.  When sessions are
   deemed to be the "active" speaker for a given
   connection if it was the party that initiated the transport open.
   The active speaker's transport endpoint will typically use an
   ephemeral port number.

   A BGP speaker unique each of them is said then handled independently,
   therefore critical conditions (such as malformed UPDATEs) in one
   session won't affect others.

   BGP Multisession extension introduces new BGP capability code to be the "passive" speaker for a given
   connection if it was the party
   indicate that received the transport open.  The
   passive speaker's transport endpoint typically uses the well-known a BGP port number, 179, but speaker supports protocol modification described
   in this document introduces an exception
   detailed in Section 5.1.1.1.

3.  Use and new error message sub-codes that facilitate
   handling of incompatible configurations between two speakers.

   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 Advertisement Code

   This specification defines the Multisession capability [RFC5492]:

      Capability code (1 octet): 68

      Capability length (1 octet): variable

      Capability value (1 octet): Flags followed by the list of
      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
     +-+-+-+-+-+-+-+-+
     |G|R| Reserved  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |G|  Reserved   | Port number (if R is set)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         One or more Capability codes (1 octet each)             |
     ~  Session Id   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   G - the most significant bit is defined as the Grouping Support (G) bit.
   It can be used was originally intended by earlier draft
   version of Multisession specification to indicate support for the ability denote capability of a BGP
   speaker to group multiple capability values into one session.  When set (value 1)  As
   this bit
   indicates that information can be deduced from Session Id, 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 of G bit is defined as the Redirect (R) bit.  When set, it
   indicates that the sender wishes
   deprecated - implementations conforming 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 final version of
   Multisession specification SHOULD NOT rely on value of the capability as detailed below.

   The remaining bits are reserved, and should G bit.

   Reserved - MUST be set to zero by the
   sender and sender, MUST be ignored by the receiver.

   If the R bit is set, following the reserved bits is the two-octet TCP
   port number to which the passive speaker wishes to redirect the
   session.

   Following the reserved bits and the transport endpoint information if
   present is a receiver

   Session Id(entifier) - list of one zero or more Capability capability codes (1 octet
   each) defined in BGP. BGP, whose values will be used to distinguish one
   group from another.  The size of the list is inferred from the length
   of the overall 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. one.
   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

   Empty Session Id list and Session Id containing 1 (one, Multiprotocol Extensions capability code (1)
   Extensions) as the only value are considered equal and indicate that
   AFI/SAFI list in the list.  In this case OPEN message is used to distinguish the Multisession capability would have a
   length groups.
   However, if BGP speaker wishes to use compound Session Id that
   includes AFI/SAFI list as one of the components, then Capability Code
   1 MUST be explicitly included in the Session Id.  For example, if BGP
   speaker Session Id to 'X' (denoting Capability Foo) then only Foo
   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 octets, sessions as well as session where Foo is
   2 and AFI/SAFI is 2/4 will be considered unique.

   For given pair of BGP peers Multisession capability MUST be used
   either on all or four octets if redirect none sessions.  This is being requested.

4. required due to different
   connection collision handling procedure used by multisession.

5.  New NOTIFICATION Subcodes

   BGP [RFC4271] Section 4.5 provides a number of subcodes to the
   NOTIFICATION message, and Section 6.2 elaborates on the use of those
   subcodes.
   subcodes specific to OPEN message.

   This specification introduces five three new subcodes: subcodes for OPEN Message
   Error subcodes: code:

         7 - Capability Value Mismatch - Session Id mismatch, i.e.
         remote speaker whishes to use different capability codes in
         Session Id compare to local speaker

         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 codes 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 in
         Session Id of the conflicting locally-configured
   capability group, encoded as the appropriate capabilities.

   The received message cannot be unambiguously
         mapped to a locally configured group

         9 - Grouping Required code MAY (from earlier drafts, perhaps should be used when a
         removed if not used)

   BGP speaker that is
   configured to require grouping attempts implementations conforming to establish a connection
   with a this specification SHOULD use new
   sub-codes as described further down in section "Connection
   establishment" of this document.

6.  Modified Connection Collision Handling

   BGP speaker that does not support grouping.  (While it is true
   that it might be possible conforming to communicate much the same information and actively using the Unsupported Capability NOTIFICATION message, this more
   explicit method is felt specification MUST
   use modified connection collision handling procedure as described in
   this section.

   Two sessions are said to be more transparent.)

   If collide if and only if both of following
   conditions are true:

   1:  the MP-BGP IP addresses on of peers are the same on both sessions

   2:  values of capability is codes used as the in session identifier, identifier are either
       the
   notifications could be used as follows:

   Capability Value Mismatch MAY be used when an OPEN message contains
   one same or more MP-BGP capabilities, none of which lists an AFI/SAFI
   supported by overlapping (regardless fully or partially) within
       given capability code

   Otherwise two sessions are considered unique and both MAY transition
   to the local ESTABLISHED state (subject to rest of BGP speaker.  It specification).

   Before attempting to create new session local system SHOULD evaluate
   existing sessions with the same peer.  If there is observed that this subcode
   may be useful for MP-BGP speakers already a session
   with the same peer 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 ESTABLISHED state and new session would collide
   with one or more
   AFI/SAFI groups configured on it, BGP speaker SHOULD NOT attempt creating new session; it's a
   good idea to notify operator of the local system about such potential
   collision.

   Upon receipt of an OPEN messages BGP speaker.  The Data field speaker MUST indicate one evaluate existing
   sessions with the same peer.  If there is already a session in
   ESTABLISHED state and multisession distinguisher values 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 old
   and bar as you've
   tried to do.")

   Use of the Redirecting Now new OPEN messages fully match, the old session remains and Redirect Required codes
   the new MUST be closed.

   If there is detailed a session 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 OpenConfirm or OpenSent state and two main subsections.

   The "Using Multisession" sections below discuss the BGP speaker's
   behavior when
   sessions do not collide according to this document, then both
   sessions proceed as normally and section 6.8 of RFC4271 MUST NOT be
   applied.  If on the peer does support other hand two sessions collide according to
   definition of this specification or is assumed
   to.  The "Backward Compatibility" document, then original procedure from section discusses 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's
   behavior when the peer does not support speaker SHOULD send NOTIFICATION message as
   described in this specification, or document.

7.  Connection establishment

   When BGP Multisession is
   assumed not to.  Both sections also discuss how to switch to the
   other mode.

   A enabled by configuration for given peer and
   configuration dictates that multiple sessions can potentially be
   established with given peer, BGP speaker that supports this specification MUST always advertise
   the Multisession capability, regardless of its peer's known or
   presumed capability set.
   Capability code in the OPEN message on every session with given peer.
   In all other cases until a BGP speaker has initiated or accepted one
   connection from a given peer, it is unknown whether the peer supports
   this specification or not.  Two strategies can Multisession capability SHOULD NOT be advertised.
   The value of Session Id MUST be considered for
   making this initial determination -- either the same on every session.

   When Multisession-enabled BGP speaker can
   initially receives an OPEN message
   without BGP Multisession Capability code it MUST assume that the peer does is
   not support this specification, capable of multiple sessions and switch modes if it is discovered that it does, or vice-versa.
   Either approach is acceptable.

   As discussed previously, this MUST use original Connection
   Collision Detection procedure as described in section describes the operation from
   the point of view 6.8 of the MP-BGP capability RFC4271.

   When Multisession-enabled BGP speaker receives an OPEN message
   containing BGP Multisession Capability Code but with Session Id not
   matching its own Session Id, local BGP speaker MUST send NOTIFICATION
   message with Error Code set to 2 ("OPEN Message Error") and Error
   Sub-code set to 8 ("Grouping Conflict") and drop the associated AFI/
   SAFI values as the session.  If
   received Session Id matches locally configured Session Id then BGP
   speaker MUST verify whether this session identifier.  It can be replaced would collide with any
   other capability or groups of capabilities without any changes to
   the
   behavior existing as described below.

   Note that if a BGP speaker only wishes to support a single AFI/SAFI in its communications with a given peer only one section "Modified Connection Collision
   Handling".

   If session is needed in
   any case, and so allowed to continue by connection collision detection
   procedure, the "multisession" feature next step for local speaker is moot.  In such a case
   the behavior required would be indistinguishable from that given to find matching group
   as follow:

   1.  If BGP capability code values used in Session Id of the "backward compatibility" section below.  In the illustrative
   examples received
       message match exactly (i.e. for every value in the following sections, it received OPEN
       message there is generally assumed that a
   BGP speaker does wish to support multiple AFI/SAFI corresponding value in its
   communications with a given peer.

5.1.  Using Multisession

   The following subsections discuss a BGP speaker's behavior towards a
   peer that is known or assumed to support this specification.

5.1.1.  Initiating Connections

   When a locally configured
       group) then local BGP speaker (the "active" speaker) attempts BGP communication proceeds with its peer (the "passive" speaker), it initiates this session

   2.  If values in the received message do not match any of the locally
       configured groups exactly, but there is one connection
   per and only one locally
       configured group of AFI/SAFI it wishes to support.  (This implies such that a new
   local TCP port will be allocated for each new connection.)  The OPEN
   sent on each connection MUST include the Multisession every capability and
   one or more MP-BGP capabilities indicating code the AFI/SAFI to be
   supported on that session.  If a non-trivial group of AFI/SAFI (i.e.,
   a
       intersection between received and local values is non-empty set,
       then this group of two or more) is proposed, selected for continuing the session.  Note,
       such partial match results in behaviour similar to non-
       multisession BGP speaker MUST also set
   the G bit of the Multisession capability.  Even if a trivial when capability codes overlap partially.
       Rationale behind allowing only one group of
   AFI/SAFI for partial matching is proposed, the G bit SHOULD
       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 set if grouping is
   supported.  The active required in real-life networks.

   3.  In all other cases local BGP speaker MUST NOT send NOTIFICATION
       message with Error Code 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
   speaker may wish to use a separate BGP connection for each AFI/SAFI.

   If the peer also supports this specification 2 (OPEN Message Error) and also wishes Error
       Sub-code set to
   support the AFI/SAFI in question, 8 (Grouping conflict).

   Once local BGP speaker has identified which locally configured group
   corresponds to received OPEN message it will respond proceeds with an OPEN that
   includes the Multisession capability and session
   like it would have been regular non-multisession one, particularly -
   the AFI/SAFI included original Finite State Machine applies.  BGP speaker is free to
   handle such session either in the
   active speaker's OPEN.  If same process/thread as the active speaker's OPEN included a non-
   trivial group of AFI/SAFI one that the peer supports, then the peer's
   Multisession capability will have the G bit set.
   received OPEN message, or it can hand over connection to another
   process/thread.  If uses, the peer also supports this specification and wishes to support
   some but not all connection handover is local-matter of the AFI/SAFI in question, it will respond with an
   OPEN that includes the Multisession capability
   BGP implementation 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 part of this specification.  Appendix
   contains an example how such handover could be configured done.

8.  Graceful restart

   With respect to use Section 4.2 of BGP Graceful Restart [RFC4724], when
   determining whether a smaller group).  In
   this case, the new connection BGP speaker MAY consider the set evaluate values of AFI/SAFI that were
   not included
   all capability codes used in the peer's OPEN to form a new group, and MAY try to
   initiate a new Session Identifier.

9.  Error handling

   If multisession-enabled BGP speaker detects an error condition that
   warrants session reset, it SHOULD reset only session using that group.

   If was
   affected by the error.  Resetting other sessions with the same peer also
   would significantly diminish value of multisession extensions.

10.  Operational considerations

   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 this specification but does not support
   grouping, and a non-trivial group of AFI/SAFI has been proposed, 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 respond as given be carried in the previous paragraph but with the
   additional proviso that the G bit one session, and
   which address families will be clear.  In this case, the
   BGP speaker MAY accept the connection as given carried in the previous
   paragraph, or it MAY reply with a another session.

   BGP implementation supporting multisession extension SHOULD allow
   operator to view state of each individual group and at least last
   NOTIFICATION message with ERROR
   Code OPEN Message Error and Error Subcode Grouping Required, and the that caused connection will be closed.

   If the peer wishes to continue reset.

   For the sake of interoperability between BGP connection speakers supporting
   multisession, an implementation SHOULD NOT impose hard-coded
   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 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
   attribute.  Let's consider this is handled. on an example.  If the peer does not wish implementation A
   requires AFI/SAFI 1/1 and 1/4 to support the be always carried within same
   session, while implementation B requires AFI/SAFI in question, it
   will reply with a NOTIFICATION message 1/4 to be always
   carried only with Error Code OPEN Message
   Error, and Error Subcode Capability Value Mismatch, 1/128 and the
   connection will be closed.

   A not with any other, then it's not
   possible to establish session between such BGP speaker MUST NOT attempt speakers.  However if
   implementations A and B both allow each AFI/SAFI to initiate connections be carried each
   in its own group, then we can establish three sessions - one for any AFI/
   SAFI 1/1, another one for which AFI/SAFI 1/4 and third one for AFI/SAFI
   1/128.

11.  Backward Compatibility

   This subsection discusses a BGP speaker's behavior towards a connection already exists.

   If the peer does
   that is known or assumed not to support this specification, it will respond with
   an OPEN that does not include the Multisession capability. specification.  In this
   case the connection SHOULD be terminated, and future connections to
   short, the BGP speaker's behavior towards such a peer should be attempted in as
   otherwise defined for the "backward compatibility" mode
   discussed in Section 6.

5.1.1.1.  Continuing a Redirected Connection

   When BGP protocol, according to [RFC4271] and
   any other extension supported by the active speaker BGP speaker.

   If a BGP speaker receives an OPEN from message that doesn't include
   Multisession Capability and local BGP speaker is required to use
   multisession (e.g. through configuration by operator), the passive local BGP
   speaker
   that includes transport redirect information, it MUST reply with an
   Open Message Error drop the session and send appropriate NOTIFICATION
   message as described in Section 5.  If multisession is not required,
   local BGP speaker proceeds with its subcode set to Redirecting
   Now and close the session.  Subsequently, multisession extension disabled, so
   it MUST attempt appears as regular implementation to initiate
   a new session using the transport endpoint that peer.

   As previously mentioned, the passive BGP speaker
   has proposed SHOULD always advertise the
   Multisession capability in lieu its OPEN message, even towards "backward
   compatibility" peers.

   Use of techniques such as dynamic capabilities
   [I-D.ietf-idr-dynamic-cap] for on-the-fly switching of session modes
   is beyond the original one (which typically would have
   been the well-known scope of this document.

12.  State Machine

   This specification does not modify BGP port, 179).  The new session should proceed
   exactly FSM as the such, but all
   references to execution of collision handling procedure of original one did; that is, the active speaker SHOULD
   send an OPEN
   BGP specification are replaced with the same content, and can expect call to receive from
   the passive speaker an OPEN with the same content collision handling
   procedure described in this document.

   The specific state machine modifications to [RFC4271] Section 8.2.2
   are 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. follows.

13.  Discussion

   Note that although the OPEN messages exchanged many BGP implementations already permit multiple sessions
   to be used between a given pair of routers, typically by configuring
   multiple IP addresses on the reinitiated each router and configuring each session can be expected to
   be the same as or similar bound to those from
   the previous session as discussed above, an implementation MUST NOT
   rely on or enforce this assumption when handling the received OPEN. a different IP address.  The new session MUST be handled as any other new session would be in principal contribution of
   this respect.

   As discussed above, when the passive speaker requests a redirect, the
   active speaker specification is expected to drop the current session and initiate a
   new one.  If it does not do so, the passive speaker MAY elect allow multiple sessions to
   continue the session, be created
   automatically, without additional configuration overhead or it MAY elect to terminate address
   consumption.

   The specification supports the simple case of one capability being
   used as the session by
   sending a Redirect Required NOTIFICATION.

5.1.2.  Accepting Connections

   When processing a identifier and one connection attempt, the BGP speaker MUST wait until
   the peer's OPEN message has been received before proceeding.  This is
   at variance per session
   identifier value.  It also permits connections be established based
   on multiple capabilities as a session identifier with multiple values
   per capability grouped together per connection.

   In the behavior specified in the finite state machine
   (FSM) context of [RFC4271], but is interoperable with that FSM.  The FSM
   changes are specified in Section 7.

   Once MP-BGP based connections, which we believe may be
   the peer's OPEN message has been received, if most prevalent use of this specification, it includes the
   Multisession capability and permits supporting
   one or more MP-BGP capabilities
   indicating a group AFI/SAFI per connection, and also permits arbitrary grouping of
   AFI/SAFI that the onto BGP speaker wishes connections.  For such grouping to
   support, then the BGP speaker responds with an OPEN message that
   includes function
   pleasingly, both peers participating in a connection need to agree on
   what AFI/SAFI groupings will be used.  If conflicting groupings are
   configured, the Multisession capability and one connections may not establish, or more MP-BGP
   capabilities indicating connections
   may be established than were expected (in the same AFI/SAFI. degenerate case, one
   connection per AFI/SAFI could be established despite configured
   groupings).  We observe that the potential for misbehavior in the
   presence of conflicting configuration is not unusual in BGP, and that
   support for, and configuration of grouping is purely optional.

14.  Security Considerations

   This document does not change the BGP security model.

15.  Acknowledgements

   The authors would like to thank Martin Djernaes, Pedro Marques, Keyur
   Patel, Robert Raszuk, Yakov Rekhter, David Ward and Anton Elita for
   their valuable comments.

16.  IANA Considerations

   IANA has allocated BGP Capability Code 68 as the Multisession BGP
   Capability.

   This document requests IANA to allocate three new OPEN Message Error
   subcodes:

      7 - Capability Value Mismatch

      8 - Grouping Conflict

      9 - Grouping Required

17.  References
17.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              January 2007.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, February 2009.

17.2.  Informative References

   [I-D.ietf-idr-dynamic-cap]
              Chen, E. and S. Ramachandra, "Dynamic Capability for
              BGP-4", draft-ietf-idr-dynamic-cap-12 (work in progress),
              October 2010.

   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              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 includes the Multisession capability and one or more MP-
   BGP capabilities indicating a group of message lists both AFI/SAFI and it
   knows that conflicts with
   an AFI/SAFI grouping it wants to split them into different sessions, therefore
   it's obvious that has been configured on setup cannot function as intended.  Since
   separation of two address families into two groups is performed by
   operator (as per Multisession Extension specification), the BGP speaker then 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 MAY reply 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 listing a set of
   message for either AFI/SAFI that
   intersect with those proposed by the peer (in effect overriding the
   locally configured set) or first.  Assuming Speaker A is not
   multisession-enabled, it MAY close the connection 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 OPEN Message 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 Grouping Conflict.  The former behavior 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 suggested 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 the
   default if grouping described in previous subsection.  Now suppose
   Speaker B is supported.

   If the BGP speaker configured with additional session to carry IPv4 L3VPN
   prefixes.  Since Speaker A does not support AFI/SAFI grouping have multiple sessions
   configured, it MAY reply
   with an won't send another OPEN listing one 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 the 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 out

   This is most common use of those proposed multisession extension is to separate
   prefixes based on AFI/SAFI.  Note that use of AFI/SAFI based groups
   is denoted by the
   peer.  It MUST also set the G bit empty Optional Data field in the Multisession capability to
   zero.

   If the passive speaker wishes to continue the session for this
   particular grouping on a different port number, it sets Capability,
   which is the R bit same as in
   its OPEN and includes previous two sections.  Grouping
   configuration is devised from the TCP port number on which it list of actually advertised AFI/
   SAFI lists (MP-BGP Capability).  This will continue
   the session.  The passive speaker MUST be prepared to accept a
   connection on the given port immediately demonstrated in
   following transmission of 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 OPEN.

   If the received own session.  We start with no existing sessions between
   these speakers.  Speaker A (though roles can reverse) sends OPEN
   message does not include any MP-BGP capability
   indicating an AFI/SAFI the BGP speaker wishes to support, in which among other capabilities it SHOULD
   close the connection announces MP-BGP
   Capability for AFI=1 SAFI=1 and Multisession Capability with a NOTIFICATION empty
   optional data field.  Speaker B upon receipt of such message finds
   that it expects to exchange IPv4 unicast with Error Code OPEN
   Message Error Speaker B in a
   dedicated session.  It accepts connection and Error Subcode Capability Value Mismatch.

   If the received sends similar OPEN
   message does not include the Multisession
   capability, then the peer does to Speaker A. As there were no existing sessions, collision
   handling procedure is not support invoked at this specification.  The
   connection MAY be continued in the "backward compatibility" mode
   discussed in Section 6, or time.  Next Speaker A (but
   again it MAY could be terminated Speaker B) starts new TCP connection to Speaker B
   and future
   connections 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 peer attempted in the "backward compatibility"
   mode.

5.1.3.  Collision Detection, Graceful Restart

   [RFC4271] Section 6.8 (BGP connection proposal it executes collision detection) considers
   a pair detection procedure.  Since AFI/
   SAFI lists of connections to have collided if the source old (ESTABLISHED) and destination
   IP addresses of both connections match.  With respect 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 peers ESTABLISHED
   state.  In the same way third session, for AFI=1 SAFI=128, is brought
   up.

   Note that
   support this 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 groups associated with the
   connections must also intersect lists).  If Speaker A opens TCP connection and
   sends an OPEN message for them to be considered 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 have
   collided. coexist without affecting each
   other.  This consideration also behaviour applies also to Section 4.2 of BGP Graceful
   Restart [RFC4724], when determining whether a new connection should
   be considered equivalent to a reset of a previous TCP session.

6.  Backward Compatibility

   This subsection discusses a BGP speaker's behavior towards a peer
   that more complex cases where
   groups include more AFI/SAFI or based on different Capability Codes
   all together.  For this reason collision handling is known or assumed not discussed in
   remaining scenarios.

   Now suppose Speaker A configuration is as above, but Speaker B is
   configured to support this specification.  In
   short, combine labelled-unicast and L3VPN prefixes into the BGP speaker's behavior towards such a peer should be
   same session.  IPv4 session is brought up as
   otherwise defined above.  Next there are
   two possible alternatives.  Either Speaker A sends OPEN message for
   one of the BGP protocol, according remaining sessions, to [RFC4271] which Speaker B responds with
   NOTIFICATION message Error Code 2 and
   any other extension supported by Error Subcode 8.  Or Speaker B
   sends OPEN message for combined session including both of the BGP speaker.

   As previously mentioned,
   remaining address families, to which Speaker A responds either with
   exactly the BGP speaker SHOULD always advertise same NOTIFICATION message.  At the
   Multisession capability in its OPEN message, even towards "backward
   compatibility" peers.

   If, end only IPv4 session
   remains in opening a BGP connection ESTABLISHED state, while two other address families
   require operator's intervention for configuring either Speaker A with such a peer,
   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 OPEN
   implementation that
   includes the Multisession capability is received from the peer, requires that labelled-unicast and L3VPN address-
   families are combined into single session, then
   the peer SHOULD behaviour of each
   side would be changed exactly as above.

   If Speaker A wouldn't have L3VPN configuration for Speaker B at all,
   then whether second session would progress to "multisession" mode.  How this is done ESTABLISHED or not
   depends on whether the configuration of either side requires exact match
   between groups (by default implementations expected to mimim original
   BGP speaker has 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 sent an OPEN or not --

   If the BGP speaker has not yet sent an OPEN to the peer, then the
   connection MAY be continued described in the "multisession" mode discussed
   above, or it MAY be terminated and future connections previous
   case.  Next let Speaker A to be the peer
   attempted in "multisession" mode.

   If the BGP speaker has sent an OPEN first to the peer, then the current setup second TCP session SHOULD be terminated
   and future connections to the peer
   attempted in "multisession" mode.

   Use of techniques such as dynamic capabilities
   [I-D.ietf-idr-dynamic-cap] send OPEN message for on-the-fly switching group 2.  Applying collision handling
   procedure as defined in Multisession specification Speaker B
   continues processing of session modes received OPEN message.  If Speaker B is beyond
   configured for strict match between the scope groups, then it will detect
   incompatibility of this document.

7.  State Machine

   As mentioned under "accepting connections" above, this specification
   modifies 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 finite state machine, albeit implementation would in a backward-
   compatible fashion.

   In addition, note that one state machine is considered to exist for
   each absence of the connections that may exist to a given peer.  This implies
   that, for example, any session flap dampening multisession), it will
   reply with OPEN message that may exist is
   performed per lists AFI=1 SAFI=4 and session identifier.

   The specific state machine modifications
   potentially progresses to [RFC4271] Section 8.2.2
   are as follows.

7.1.  Modifications ESTABLISHED state provided that Speaker A
   doesn't require exact match on AFI/SAFI list.  Similar applies to Connect State and Active State

   In the actions in response to
   session 3 for the events Open Delay timer expires
   [Event 12] and TCP connection succeeds [Event 16 remaining AFI/SAFI.  Note that configuration for
   exact or Event 17], an
   OPEN 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 not sent and the state changes to WaitForOpen and not to
   OpenSent.

7.2.  Addition of WaitForOpen State, Deletion most
   comprehensive scenario, the behaviour of OpenSent State

   The WaitForOpen state the BGP speakers is
   essentially the same as in all respects to OpenSent, except
   for the action in response to reception case 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 AFI/SAFI based groups.  However
   arbitrary groups do add extra complexity because BGP speakers need to OpenSent are
   replaced by references
   consider not only values of single capability, but need to WaitForOpen.

8.  Discussion

   Note agree upon
   Capability Codes that many BGP implementations already permit multiple sessions
   to be used between a given pair constitute Session Id.  Following example
   demonstrates behaviour of routers, typically by configuring
   multiple IP addresses multisession-enabled BGP speakers in
   situation where Session Id on each router and configuring each session to
   be bound to a side is based on different IP address.  The principal contribution of
   this specification
   capabilities.

   Let's suppose there is imaginery Capability Code X that denotes
   Experiment Id, and two speakers would like to allow multiple sessions to be created
   automatically, without additional configuration overhead or address
   consumption.

   The specification supports the simple case of one capability being
   used as the session identifier exchange IPv4 unicast
   and one connection per session
   identifier value.  It also permits connections be established L3VPN prefixes for two experiments.  Speaker A would like to
   group prefixes into separate sessions based solely on multiple capabilities as a session identifier Experiment Id
   (so two sessions with multiple values
   per capability grouped together per connection.

   In the context of MP-BGP based connections, which we believe may be
   the most prevalent use of this specification, it permits supporting
   one AFI/SAFI per connection, and also permits arbitrary grouping of
   AFI/SAFI onto BGP connections.  For such grouping to function
   pleasingly, both peers participating in a connection need two AFI/SAFI in each), while Speaker B would
   like to agree on
   what have separate session per experiment per AFI/SAFI groupings (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 used.  If conflicting groupings are
   configured, non-empty.  Multisession Capability
   sent by Speaker A will contain only 'Experiment Id Capability Code'
   in the connections may not establish, or more connections
   may be established than were expected (in 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 degenerate case, one
   connection per AFI/SAFI could peer, it will notice mismatch
   between content of the Optional Data field and, since sessions cannot
   be established despite configured
   groupings).  We observe that the potential for misbehavior in as intended, the
   presence of conflicting configuration is not unusual in BGP, speaker will send NOTIFICATION
   message with Error Code 2 and that
   support for, 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 grouping is purely optional.

9.  Security Considerations

   The ability to redirect to a port other than the well-known BGP port
   implies either
   side changes.

   Note that despite Multisession Capability does not containing a legitimate BGP session may exist for which neither
   port is equal field
   to 179.  This may have implications denote support for firewall
   filters used to protect the control processor.

   In other respects, this document non-AFI/SAFI based groups, even an
   implementation that does not change the BGP security
   model.

10.  Acknowledgements

   The authors would like support groups based on arbitrary
   capability codes will be able to thank Pedro Marques, Keyur Patel, Robert
   Raszuk, Yakov Rekhter recognise configuration mismatch and David Ward for their valuable comments.

11.  IANA Considerations

   IANA has allocated BGP Capability Code 68
   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
   Capability.

   This document requests IANA
   implementations can leverege IPC facilities provided by host
   operating systems to allocate five new OPEN Message Error
   subcodes:

      7 - Capability Value Mismatch

      8 - Grouping Conflict

      9 - Grouping Required

      10 - Redirecting Now

      11 - Redirect Required

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs handover arbitrary session to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              January 2007.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions appropriate
   process.  For example, many systems can pass connection from the
   process that accepted TCP connection to a process dedicated for BGP-4", RFC 4760,
              January 2007.

   [RFC5492]  Scudder, J.
   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 R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, February 2009.

12.2.  Informative References

   [I-D.ietf-idr-dynamic-cap]
              Chen, E. 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 S. Ramachandra, "Dynamic Capability for
              BGP-4", draft-ietf-idr-dynamic-cap-10 (work in progress),
              January 2010.

   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              September 2000. does not require specific aid from
   BGP at protocol specification level.  Therefore process level
   separation is not part of multisession specification.

Authors' Addresses

   John G. Scudder
   Juniper Networks

   Email: jgs@juniper.net

   Chandra Appanna
   Cisco Systems

   Email: achandra@cisco.com

   Ilya Varlashkin
   Easynet Global Services

   Email: ilya.varlashkin@easynet.net