draft-ietf-idr-rfc3392bis-01.txt   draft-ietf-idr-rfc3392bis-02.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: May 22, 2009 Sonoa Systems Expires: June 13, 2009 Sonoa Systems
November 18, 2008 December 10, 2008
Capabilities Advertisement with BGP-4 Capabilities Advertisement with BGP-4
draft-ietf-idr-rfc3392bis-01.txt draft-ietf-idr-rfc3392bis-02.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 May 22, 2009. This Internet-Draft will expire on June 13, 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
The base BGP-4 specification [RFC4271] requires that when a BGP The base BGP-4 specification [RFC4271] requires that when a BGP
speaker receives an OPEN message with one or more unrecognized speaker receives an OPEN message with one or more unrecognized
Optional Parameters, the speaker must terminate BGP peering. This Optional Parameters, the speaker must terminate the BGP peering.
complicates introduction of new capabilities in BGP. This complicates the introduction of new capabilities in BGP.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Overview of Operations 3. Overview of Operations
When a BGP speaker [RFC4271] that supports capabilities advertisement When a BGP speaker [RFC4271] that supports capabilities advertisement
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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 to message to the peer and terminate peering (see Section "Extensions to
Error Handling" for more details). The Error Subcode in the message Error Handling" for more details). The Error Subcode in the message
is set to Unsupported Capability. The message SHOULD contain the is set to Unsupported Capability. The message SHOULD contain 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 the peering
local to the speaker. If terminated, such peering SHOULD NOT be re- is local to the speaker. If terminated, such peering SHOULD NOT be
established automatically. An example of when this procedure might re-established automatically. An example of when this procedure
be followed is if a BGP speaker is attempting to establish an IPv6 might be followed is if a BGP speaker is attempting to establish an
peering but determines that its peer does not support Multiprotocol IPv6 peering but determines that its peer does not support
Extensions for BGP-4 [RFC4760]. Multiprotocol 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 or recognize, it SHOULD ignore that capability. not itself support or recognize, it SHOULD ignore that capability.
In particular, the Unsupported Capability NOTIFICATION message MUST In particular, the Unsupported Capability NOTIFICATION message MUST
NOT be generated in response to reception of a capability which is NOT be generated in response to reception of a capability which is
not supported by 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
skipping to change at page 4, line 25 skipping to change at page 4, line 25
the document introducing the new capability. the document introducing the new capability.
The Capabilities Optional Parameter (OPEN Optional Parameter Type 2) The Capabilities Optional Parameter (OPEN Optional Parameter Type 2)
SHOULD only be included in the OPEN message once. If the BGP speaker SHOULD only be included in the OPEN message once. If the BGP speaker
wishes to include multiple capabilities in the OPEN message, it wishes to include multiple capabilities in the OPEN message, it
SHOULD do so as discussed above, by listing all those capabilities as SHOULD do so as discussed above, by listing all those capabilities as
TLVs within a single Capabilities Optional Parameter. However, for TLVs within a single Capabilities Optional Parameter. However, for
backward compatibility a BGP speaker MUST be prepared to receive an backward compatibility a BGP speaker MUST be prepared to receive an
OPEN message which contains multiple Capabilities Optional OPEN message which contains multiple Capabilities Optional
Parameters, each of which contains one or more capabilities TLVs. Parameters, each of which contains one or more capabilities TLVs.
The set of capabilities should be processed the same in either case, The set of capabilities should be processed in the same way in either
whether it is enumerated within a single Capabilities Optional case, whether it is enumerated within a single Capabilities Optional
Parameter of the OPEN message, or split across multiple. Parameter of the OPEN message, or split across multiple.
5. Extensions to Error Handling 5. Extensions to Error Handling
This document defines a 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 in the same way as
would be encoded in the OPEN message. it would be encoded in the OPEN message.
As explained in the Overview of Operations section, 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
skipping to change at page 5, line 44 skipping to change at page 5, line 44
[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, RFC 3392 also
clarifies how to handle multiple instances of the same capability. clarified 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 and updated references, this In addition to minor editorial changes and updated references, this
document also clarifies the use of the Unsupported Optional Parameter document also clarifies the use of the Unsupported Optional Parameter
NOTIFICATION message and clarifies behavior when the Capabilities NOTIFICATION message and clarifies behavior when the Capabilities
parameter is included in the OPEN message multiple times. parameter is included in the OPEN message multiple times.
Authors' Addresses Authors' Addresses
 End of changes. 8 change blocks. 
18 lines changed or deleted 18 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/