draft-ietf-idr-rfc3392bis-00.txt   draft-ietf-idr-rfc3392bis-01.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 R. Chandra Intended status: Standards Track R. Chandra
Expires: November 23, 2008 Sonoa Systems Expires: May 22, 2009 Sonoa Systems
May 22, 2008 November 18, 2008
Capabilities Advertisement with BGP-4 Capabilities Advertisement with BGP-4
draft-ietf-idr-rfc3392bis-00.txt draft-ietf-idr-rfc3392bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 23, 2008. This Internet-Draft will expire on May 22, 2009.
Abstract Abstract
This document defines an Optional Parameter, called Capabilities, This document defines an Optional Parameter, called Capabilities,
that is expected to facilitate the introduction of new capabilities that is expected to facilitate the introduction of new capabilities
in the Border Gateway Protocol (BGP) by providing graceful capability in the Border Gateway Protocol (BGP) by providing graceful capability
advertisement without requiring that BGP peering be terminated. This advertisement without requiring that BGP peering be terminated. This
document obsoletes RFC 3392. document obsoletes RFC 3392.
1. Introduction 1. Introduction
skipping to change at page 2, line 44 skipping to change at page 2, line 44
Capabilities Optional Parameter, the speaker receives a NOTIFICATION Capabilities Optional Parameter, the speaker receives a NOTIFICATION
message with the Error Subcode set to Unsupported Optional Parameter. message with the Error Subcode set to Unsupported Optional Parameter.
(This is a consequence of the base BGP-4 specification [RFC4271] and (This is a consequence of the base BGP-4 specification [RFC4271] and
not a new requirement.) In this case the speaker SHOULD attempt to not a new requirement.) In this case the speaker SHOULD attempt to
re-establish a BGP connection with the peer without sending to the re-establish a BGP connection with the peer without sending to the
peer the Capabilities Optional Parameter. peer the Capabilities Optional Parameter.
If a BGP speaker that supports a certain capability requires that If a BGP speaker that supports a certain capability requires that
this capability be used on a peering but determines that its peer this capability be used on a peering but determines that its peer
doesn't support this capability, the speaker MAY send a NOTIFICATION doesn't support this capability, the speaker MAY send a NOTIFICATION
message to the peer, and terminate peering (see Section "Extensions message to the peer and terminate peering (see Section "Extensions to
to Error Handling" for more details). The Error Subcode in the Error Handling" for more details). The Error Subcode in the message
message is set to Unsupported Capability. The message SHOULD contain is set to Unsupported Capability. The message SHOULD contain the
the capability (capabilities) that causes the speaker to send the capability (capabilities) that causes the speaker to send the
message. The decision to send the message and terminate peering is message. The decision to send the message and terminate peering is
local to the speaker. If terminated, such peering SHOULD NOT be re- local to the speaker. If terminated, such peering SHOULD NOT be re-
established automatically. An example of when this procedure might established automatically. An example of when this procedure might
be followed is if a BGP speaker is attempting to establish an IPv6 be followed is if a BGP speaker is attempting to establish an IPv6
peering but determines that its peer does not support Multiprotocol peering but determines that its peer does not support Multiprotocol
Extensions for BGP-4 [RFC4760]. Extensions for BGP-4 [RFC4760].
If a BGP speaker receives from its peer a capability which it does If a BGP speaker receives from its peer a capability which it does
not itself support, it SHOULD ignore that capability. In particular, not itself support or recognize, it SHOULD ignore that capability.
the Unsupported Capability NOTIFICATION message MUST NOT be generated In particular, the Unsupported Capability NOTIFICATION message MUST
in response to reception of a capability which is not supported by NOT be generated in response to reception of a capability which is
the local speaker. not supported by the local speaker.
4. Capabilities Optional Parameter (Parameter Type 2): 4. Capabilities Optional Parameter (Parameter Type 2):
This is an Optional Parameter that is used by a BGP speaker to convey This is an Optional Parameter that is used by a BGP speaker to convey
to its BGP peer the list of capabilities supported by the speaker. to its BGP peer the list of capabilities supported by the speaker.
The parameter contains one or more triples <Capability Code, The parameter contains one or more triples <Capability Code,
Capability Length, Capability Value>, where each triple is encoded as Capability Length, Capability Value>, where each triple is encoded as
shown below: shown below:
+------------------------------+ +------------------------------+
| Capability Code (1 octet) | | Capability Code (1 octet) |
+------------------------------+ +------------------------------+
| Capability Length (1 octet) | | Capability Length (1 octet) |
+------------------------------+ +------------------------------+
| Capability Value (variable) | | Capability Value (variable) |
~ ~
+------------------------------+ +------------------------------+
Figure 1
The use and meaning of these fields are as follows: The use and meaning of these fields are as follows:
Capability Code: Capability Code:
Capability Code is a one octet field that unambiguously Capability Code is a one octet field that unambiguously
identifies individual capabilities. identifies individual capabilities.
Capability Length: Capability Length:
Capability Length is a one octet field that contains the length Capability Length is a one octet field that contains the length
skipping to change at page 4, line 19 skipping to change at page 4, line 17
additional instances do not change the meaning of the announced additional instances do not change the meaning of the announced
capability. capability.
BGP speakers MAY include more than one instance of a capability (as BGP speakers MAY include more than one instance of a capability (as
identified by the Capability Code) with non-zero Capability Length identified by the Capability Code) with non-zero Capability Length
field, but with different Capability Value, and either the same or field, but with different Capability Value, and either the same or
different Capability Length. Processing of these capability different Capability Length. Processing of these capability
instances is specific to the Capability Code and MUST be described in instances is specific to the Capability Code and MUST be described in
the document introducing the new capability. the document introducing the new capability.
The Capabilities Optional Parameter (OPEN Optional Parameter Type 2)
SHOULD only be included in the OPEN message once. If the BGP speaker
wishes to include multiple capabilities in the OPEN message, it
SHOULD do so as discussed above, by listing all those capabilities as
TLVs within a single Capabilities Optional Parameter. However, for
backward compatibility a BGP speaker MUST be prepared to receive an
OPEN message which contains multiple Capabilities Optional
Parameters, each of which contains one or more capabilities TLVs.
The set of capabilities should be processed the same in either case,
whether it is enumerated within a single Capabilities Optional
Parameter of the OPEN message, or split across multiple.
5. Extensions to Error Handling 5. Extensions to Error Handling
This document defines new Error Subcode - Unsupported Capability. This document defines a new Error Subcode, Unsupported Capability.
The value of this Subcode is 7. The Data field in the NOTIFICATION The value of this Subcode is 7. The Data field in the NOTIFICATION
message SHOULD list the set of capabilities that cause the speaker to message SHOULD list the set of capabilities that cause the speaker to
send the message. Each such capability is encoded the same way as it send the message. Each such capability is encoded the same way as it
would be encoded in the OPEN message. would be encoded in the OPEN message.
As the Overview of Operations section notes, the Unsupported As explained in the Overview of Operations section, the Unsupported
Capability NOTIFICATION is a way for a BGP speaker to complain that Capability NOTIFICATION is a way for a BGP speaker to complain that
its peer does not support a required capability, without which the its peer does not support a required capability, without which the
peering cannot proceed. It MUST NOT be used when a BGP speaker peering cannot proceed. It MUST NOT be used when a BGP speaker
receives a capability which it does not understand; such capabilities receives a capability which it does not understand; such capabilities
SHOULD be ignored. SHOULD be ignored.
6. IANA Considerations 6. IANA Considerations
This document defines a Capability Optional Parameter along with a This document defines a Capability Optional Parameter along with a
Capability Code field. IANA maintains the registry for Capability Capability Code field. IANA maintains the registry for Capability
Code values. Capability Code value 0 is reserved. Capability Code Code values. Capability Code value 0 is reserved. Capability Code
values 1 through 63 are to be assigned by IANA using the "IETF values 1 through 63 are to be assigned by IANA using the "IETF
Consensus" policy defined in [RFC2434]. Capability Code values 64 Consensus" policy defined in [RFC5226]. Capability Code values 64
through 127 are to be assigned by IANA, using the "First Come First through 127 are to be assigned by IANA, using the "First Come First
Served" policy defined in [RFC2434]. Capability Code values 128 Served" policy defined in [RFC5226]. Capability Code values 128
through 255 are for "Private Use" as defined in [RFC2434]. through 255 are for "Private Use" as defined in [RFC5226].
7. Security Considerations 7. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing BGP [RFC4272]. inherent in the existing BGP [RFC4272].
8. Acknowledgements 8. Acknowledgements
The authors would like to thank members of the IDR Working Group for The authors would like to thank members of the IDR Working Group for
their review and comments. their review and comments.
9. References 9. References
9.1. Normative References 9.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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
9.2. Informative References 9.2. Informative References
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006. RFC 4272, January 2006.
[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.
Appendix A. Comparison with RFC 2842 Appendix A. Comparison with RFC 2842
In addition to several minor editorial changes, this document also In addition to several minor editorial changes, this document also
clarifies how to handle multiple instances of the same capability. clarifies how to handle multiple instances of the same capability.
Appendix B. Comparison with RFC 3392 Appendix B. Comparison with RFC 3392
In addition to minor editorial changes, this document also clarifies In addition to minor editorial changes and updated references, this
the use of the Unsupported Optional Parameter NOTIFICATION message, document also clarifies the use of the Unsupported Optional Parameter
and updates references to the base BGP-4 specification [RFC4271] and NOTIFICATION message and clarifies behavior when the Capabilities
security analysis [RFC4272]. parameter is included in the OPEN message multiple times.
Authors' Addresses Authors' Addresses
John G. Scudder John G. Scudder
Juniper Networks Juniper Networks
Email: jgs@juniper.net Email: jgs@juniper.net
Ravi Chandra Ravi Chandra
Sonoa Systems Sonoa Systems
 End of changes. 15 change blocks. 
27 lines changed or deleted 38 lines changed or added

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