Network Working Group Enke Chen
Internet Draft John Scudder
Expiration Date: February 2006 Cisco Systems
Extended Optional Parameters for the BGP OPEN Message
draft-chen-bgp-ext-opt-param-00.txt
1. Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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.
2. Abstract
In this document we define a new BGP capability termed "Extended
Optional Parameters Capability" that would allow the optional
parameters for a BGP OPEN message to be carried in a larger size
"Extended Optional Parameters" field.
Chen & Scudder [Page 1]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
3. Introduction
Currently the size of the Optional Parameters field in the BGP OPEN
message [BGP-4] is limited to 255 octets because of the one-octet
Optional Parameters Length field. As BGP Capabilities [BGP-CAP] are
carried in the Optional Parameters field, and new BGP capabilities
continue to be introduced, the limit is becoming a concern for BGP
development.
In this document we define a new BGP capability termed "Extended
Optional Parameters Capability" that would allow the optional
parameters for a BGP OPEN message to be carried in a larger size
"Extended Optional Parameters" field.
4. 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].
5. Extended Optional Parameters in the OPEN Message
Except for the larger size of the Parameter Length field, the
Extended Optional Parameters field has the same semantics as the
Optional Parameters field defined in [BGP-4] for the BGP OPEN
message.
The Extended Optional Parameters Length field and the Extended
Optional Parameters field can be optionally appended to the existing
fields of the BGP OPEN message as follows:
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Chen & Scudder [Page 2]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
| Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Extended Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Optional Parameters Length:
This 2-octet unsigned integer indicates the total length of the
Extended Optional Parameters field in octets. If the value of
this field is zero, no Extended Optional Parameters are
present.
Extended Optional Parameters:
This field contains a list of optional parameters, where each
parameter is encoded as a <Parameter Type, Parameter Length,
Parameter Value> triplet.
0 1 2 3
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
+-+-+-+-+-+-+-+-+
| Parm. Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parm. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Parm. Value (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Parameter Type is an one octet field that unambiguously
identifies individual parameters. The Parameter Length is a
two octet field that contains the length of the Parameter Value
field in octets. The Parameter Value is a variable length
field that is interpreted according to the value of the
Parameter Type field.
Chen & Scudder [Page 3]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
An Optional Parameter Type defined for the Optional Parameters field
is automatically valid for the Extended Optional Parameter field.
One example is the Capabilities Optional Parameters defined in [BGP-
CAP].
Whether the Extended Optional Parameters field is present in an OPEN
message is determined by the Extended Optional Parameters Capability
(defined in the next section) in the OPEN message.
6. Extended Optional Parameters Capability
The Extended Optional Parameters Capability is a new BGP capability
[BGP-CAP]. The Capability Code for this capability is specified in
the "IANA Considerations" section of this document. The length of the
Capability Value field is one octet. The Capability Value field
indicates whether the Extended Optional Parameters Length field, and
thus the Extended Optional Parameters field, are included in the OPEN
message, and whether the BGP speaker intends to send another OPEN
message with the Extended Optional Parameters field. The values and
semantics for the Capability Value field are as follows:
Value Ext. Opt. Parm Len Included Second OPEN Intended
----- --------------------------- --------------------
0 NO NO
1 NO YES
2 YES NO
By advertising the Extended Optional Parameters Capability in an OPEN
message to a peer, a BGP speaker also conveys to the peer that the
speaker is capable of receiving and properly handling an OPEN message
that carries the Extended Optional Parameters field from the peer.
The Extended Optional Parameters Capability carried in the Extended
Optional Parameters field is meaningless, and SHALL be ignored by the
receiver. In this document we are only concerned with the capability
in the Optional Parameters field of an OPEN message.
Chen & Scudder [Page 4]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
7. Operation
A BGP speaker that can receive and properly handle an OPEN message
carrying the Extended Optional Parameters field from its peer SHOULD
use the BGP Capabilities Advertisement [BGP-CAP] to advertise the
Extended Optional Parameters Capability to the peer. The Capability
Value field SHALL be 0 when the BGP speaker does not include the
Extended Optional Parameters field in its OPEN message.
A BGP speaker MUST advertise the Extended Optional Parameters
Capability with the capability value of 2 in an OPEN message when the
Extended Optional Parameters field is carried in the same OPEN
message.
A BGP speaker MAY send an OPEN message carrying the Extended Optional
Parameters field to a peer ONLY after the speaker has received the
Extended Optional Parameters Capability from the peer, or has the
knowledge (via administrative means) that the capability is supported
by the peer.
Before receiving an OPEN message from a peer and without knowing (via
administrative means) whether the peer supports the capability, a BGP
speaker SHALL perform the "double open" procedure if the speaker
wishes to carry the Extended Optional Parameters field in an OPEN
message. That is, the speaker SHALL first advertise the Extended
Optional Parameters Capability with the capability value of 1 in an
OPEN message, and then wait for the OPEN message from the peer to
determine its next action. If the OPEN message from the peer carries
the Extended Optional Parameters Capability, then the speaker MUST
send another OPEN message carrying the Extended Optional Parameters
Capability (with a capability value of 2) and the Extended Optional
Parameters field. Otherwise the speaker MUST NOT send the second
OPEN message, and should either proceed with the session
establishment based on the first OPEN message sent, or terminate the
session until the "capability incompatibility" issue is resolved via
administrative means.
In processing an OPEN message from a peer, a BGP speaker SHALL
consider the Extended Optional Parameters Length field and the
Extended Optional Parameters field to be present in the OPEN message
ONLY if the Optional Parameters field of the OPEN message carries the
Extended Optional Parameters Capability, and the capability value is
2.
After advertising the Extended Optional Parameters Capability to a
peer, and receiving the capability with a capability value of 1 from
the peer, the speaker SHALL use the information in the initial OPEN
message received from the peer for the purpose of BGP connection
Chen & Scudder [Page 5]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
collision resolution. However, the speaker MUST wait for the second
OPEN message from the peer before transitioning the session to the
"Established State" [BGP-4], and the properties of the session SHALL
be solely determined by the information in the second OPEN message.
8. IANA Considerations
This document uses a BGP capability code to indicate that a BGP
speaker supports the Extended Optional Parameters Capability. The
capability code needs to be assigned by IANA per RFC 2842.
9. Security Considerations
This extension to BGP does not change the underlying security issues.
10. Acknowledgments
The authors would like to thank Yakov Rekhter and Srihari Sangli for
discussing various options to enlarge the Optional Parameters field.
11. Normative References
[BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol
4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
[BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with
BGP-4", RFC 3392, November 2002.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Author Information
Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: enkechen@cisco.com
John Scudder
Cisco Systems, Inc.
170 W. Tasman Dr.
Chen & Scudder [Page 6]
Internet Draft draft-chen-bgp-ext-opt-param-00.txt August 2005
San Jose, CA 95134
Email: jgs@cisco.com
13. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
14. Full Copyright Notice
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Chen & Scudder [Page 7]