Browse Prior Art Database

Capabilities Advertisement with BGP-4 (RFC3392)

IP.com Disclosure Number: IPCOM000010244D
Original Publication Date: 2002-Nov-01
Included in the Prior Art Database: 2002-Nov-12
Document File: 7 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Chandra: AUTHOR [+2]

Abstract

This document defines a new Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 29% of the total text.

Network Working Group                                         R. Chandra

Request for Comments: 3392                              Redback Networks

Obsoletes: 2842                                               J. Scudder

Category: Standards Track                                  Cisco Systems

                                                           November 2002

                 Capabilities Advertisement with BGP-4

Status of this Memo

   This document specifies an Internet standards track protocol for the

   Internet community, and requests discussion and suggestions for

   improvements.  Please refer to the current edition of the "Internet

   Official Protocol Standards" (STD 1) for the standardization state

   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document defines a new Optional Parameter, called Capabilities,

   that is expected to facilitate the introduction of new capabilities

   in the Border Gateway Protocol (BGP) by providing graceful capability

   advertisement without requiring that BGP peering be terminated.

   This document obsoletes RFC 2842.

1. Introduction

   Currently BGP-4 requires that when a BGP speaker receives an OPEN

   message with one or more unrecognized Optional Parameters, the

   speaker must terminate BGP peering.  This complicates introduction of

   new capabilities in BGP.

2. Specification of Requirements

   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].

Chandra, et. al.            Standards Track                     [Page 1]

RFC 3392         Capabilities Advertisement with BGP-4     November 2002

3. Overview of Operations

   When a BGP speaker [BGP-4] that supports capabilities advertisement

   sends an OPEN message to its BGP peer, the message MAY include an

   Optional Parameter, called Capabilities.  The parameter lists the

   capabilities supported by the speaker.

   A BGP speaker determines the capabilities supported by its peer by

   examining the list of capabilities present in the Capabilities

   Optional Parameter carried by the OPEN message that the speaker

   receives from the peer.

   A BGP speaker that supports a particular capability may use this

   capability with its peer after the speaker determines (as described

   above) that the peer supports this capability.

   A BGP speaker determines that its peer doesn't support capabilities

   advertisement, if in response to an OPEN message that carries the

   Capabilities Option...