draft-ietf-idr-rfc3392bis-03.txt   draft-ietf-idr-rfc3392bis-04.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 Obsoletes: 3392 (if approved) R. Chandra
Expires: June 19, 2009 Sonoa Systems Intended status: Standards Track Sonoa Systems
December 16, 2008 Expires: July 10, 2009 January 6, 2009
Capabilities Advertisement with BGP-4 Capabilities Advertisement with BGP-4
draft-ietf-idr-rfc3392bis-03.txt draft-ietf-idr-rfc3392bis-04.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 June 19, 2009. This Internet-Draft will expire on July 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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 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. An example of when this procedure
might be followed is if a BGP speaker is attempting to establish an might be followed is if a BGP speaker is attempting to establish an
IPv6 peering but determines that its peer does not support IPv6 peering but determines that its peer does not support
Multiprotocol 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 MUST ignore that capability. In
In particular, the Unsupported Capability NOTIFICATION message MUST particular, the Unsupported Capability NOTIFICATION message MUST NOT
NOT be generated in response to reception of a capability which is be generated in response to reception of a capability which is not
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
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 encoding of BGP Optional Parameters is specified in Section 4.2 The encoding of BGP Optional Parameters is specified in Section 4.2
of [RFC4271]. The parameter type of the Capabilities Optional of [RFC4271]. The parameter type of the Capabilities Optional
Parameter is 2. Parameter is 2.
The parameter contains one or more triples <Capability Code, The parameter contains one or more triples <Capability Code,
 End of changes. 5 change blocks. 
10 lines changed or deleted 10 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/