draft-ietf-idr-rfc3392bis-04.txt   draft-ietf-idr-rfc3392bis-05.txt 
Internet Engineering Task Force J. Scudder Internet Engineering Task Force J. Scudder
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Obsoletes: 3392 (if approved) R. Chandra Obsoletes: 3392 (if approved) R. Chandra
Intended status: Standards Track Sonoa Systems Intended status: Standards Track Sonoa Systems
Expires: July 10, 2009 January 6, 2009 Expires: July 11, 2009 January 7, 2009
Capabilities Advertisement with BGP-4 Capabilities Advertisement with BGP-4
draft-ietf-idr-rfc3392bis-04.txt draft-ietf-idr-rfc3392bis-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 July 10, 2009. This Internet-Draft will expire on July 11, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 the BGP peering. Optional Parameters, the speaker must terminate the BGP peering.
This complicates the introduction of new capabilities in BGP. This complicates the introduction of new capabilities in BGP.
This specification defines an Optional Parameter and processing rules
that allow BGP speakers to communicate capabilities in an OPEN
message. A pair of BGP speakers that support this specification can
establish the peering even when presented with unrecognized
capabilities, so long as all capabilities required to support the
peering are supported.
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
sends an OPEN message to its BGP peer, the message MAY include an sends an OPEN message to its BGP peer, the message MAY include an
skipping to change at page 3, line 5 skipping to change at page 3, line 12
A BGP speaker determines that its peer doesn't support capabilities A BGP speaker determines that its peer doesn't support capabilities
advertisement, if in response to an OPEN message that carries the advertisement, if in response to an OPEN message that carries the
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 determines that
this capability be used on a peering but determines that its peer its peer doesn't support this capability, the speaker MAY send a
doesn't support this capability, the speaker MAY send a NOTIFICATION NOTIFICATION message to the peer and terminate peering (see Section
message to the peer and terminate peering (see Section "Extensions to "Extensions to Error Handling" for more details). An example of when
Error Handling" for more details). The Error Subcode in the message this would be done is if the BGP speaker requires that the capability
is set to Unsupported Capability. The message SHOULD contain the in question be used on a peering, for instance if a BGP speaker is
attempting to establish a peering to exchange IPv6 routes but
determines that its peer does not support Multiprotocol Extensions
for BGP-4 [RFC4760]. The Error Subcode in the NOTIFICATION message
is set to Unsupported Capability. The message MUST 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 the peering message. The decision to send the message and terminate the peering
is local to the speaker. If terminated, such peering SHOULD NOT be is local to the speaker. If terminated, such peering SHOULD NOT be
re-established automatically. An example of when this procedure re-established automatically.
might be followed is if a BGP speaker is attempting to establish an
IPv6 peering but determines that its peer does not support
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 MUST ignore that capability. In not itself support or recognize, it MUST ignore that capability. In
particular, the Unsupported Capability NOTIFICATION message MUST NOT 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. 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 23 skipping to change at page 4, line 36
Capability Value: Capability Value:
Capability Value is a variable length field that is interpreted Capability Value is a variable length field that is interpreted
according to the value of the Capability Code field. according to the value of the Capability Code field.
BGP speakers SHOULD NOT include more than one instance of a BGP speakers SHOULD NOT include more than one instance of a
capability with the same Capability Code, Capability Length, and capability with the same Capability Code, Capability Length, and
Capability Value. Note however, that processing of multiple Capability Value. Note however, that processing of multiple
instances of such capability does not require special handling, as instances of such capability does not require special handling, as
additional instances do not change the meaning of the announced additional instances do not change the meaning of the announced
capability. capability, thus a BGP speaker MUST be prepared to accept such
multiple instances.
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) 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
skipping to change at page 4, line 48 skipping to change at page 5, line 13
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 in the same way in either The set of capabilities should be processed in the same way in either
case, 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 MUST list the set of capabilities that cause the speaker to
send the message. Each such capability is encoded in the same way as send the message. Each such capability is encoded in the same way as
it 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. MUST 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 [RFC5226]. 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 [RFC5226]. Capability Code values 128 Served" policy defined in [RFC5226]. Capability Code values 128
through 255 are for "Private Use" as defined in [RFC5226]. 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 and
their review and comments. the IESG and its Directorates for 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.
[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.
skipping to change at page 6, line 21 skipping to change at page 6, line 33
"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, RFC 3392 also In addition to several minor editorial changes, RFC 3392 also
clarified 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 This document makes minor editorial changes and updated references,
document also clarifies the use of the Unsupported Optional Parameter clarifies the use of the Unsupported Optional Parameter NOTIFICATION
NOTIFICATION message and clarifies behavior when the Capabilities message, clarifies behavior when the Capabilities parameter is
parameter is included in the OPEN message multiple times. included in the OPEN message multiple times, and clarifies
requirements by changing a number of SHOULDs to MUSTs.
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
Email: rchandra@sonoasystems.com Email: rchandra@sonoasystems.com
 End of changes. 12 change blocks. 
23 lines changed or deleted 32 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/