[Idr] [Technical Errata Reported] RFC5492 (3882)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 05 February 2014 11:27 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46791A00E5 for <idr@ietfa.amsl.com>; Wed, 5 Feb 2014 03:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.953
X-Spam-Level:
X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jEY8fE-vjEd for <idr@ietfa.amsl.com>; Wed, 5 Feb 2014 03:27:42 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 58A621A00DE for <idr@ietf.org>; Wed, 5 Feb 2014 03:27:42 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id A39EE7FC393; Wed, 5 Feb 2014 03:27:40 -0800 (PST)
To: jgs@juniper.net, rchandra@sonoasystems.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20140205112740.A39EE7FC393@rfc-editor.org>
Date: Wed, 05 Feb 2014 03:27:40 -0800
Cc: idr@ietf.org, rfc-editor@rfc-editor.org
Subject: [Idr] [Technical Errata Reported] RFC5492 (3882)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 11:27:44 -0000
The following errata report has been submitted for RFC5492, "Capabilities Advertisement with BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5492&eid=3882 -------------------------------------- Type: Technical Reported by: Ramakrishna DTV <ramakrishnadtv@infosys.com> Section: 3 Original Text ------------- " A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter." Corrected Text -------------- " A BGP speaker determines that its peer doesn't support capabilities advertisement if, in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. (This is a consequence of the base BGP-4 specification [RFC4271] and not a new requirement.) The next actions depends on the BGP speaker that received the NOTIFICATION. The speaker may intend to re-establish a BGP connection with the peer. In this case, the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. On the other hand, the speaker may not intend to re-establish peering. For example, a BGP speaker may not intend to re-establish peering if it established peering to exchange IPv6 routes and determines that its peer does not support capabilities advertisement. The decision to re-establish the peering is local to the speaker." Notes ----- Notes: As explained above, it does not always make sense to re-establish peering when the peer does not support capabilities advertisement. Indeed, in a very similar scenario, this RFC itself suggests the proposed behavior. Consider the following text in Section 3: " If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, the speaker MAY send a NOTIFICATION message to the peer and terminate peering (see Section "Extensions to Error Handling" for more details). For example, a BGP speaker may need to terminate peering if it established peering to exchange IPv6 routes and determines that its peer does not support Multiprotocol Extensions for BGP-4 [RFC4760]. The Error Subcode in the NOTIFICATION message is then set to Unsupported Capability. The message MUST contain the capability or capabilities that cause the speaker to send the message. The decision to send the message and terminate the peering is local to the speaker. If terminated, such peering SHOULD NOT be re-established automatically." Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5492 (draft-ietf-idr-rfc3392bis-05) -------------------------------------- Title : Capabilities Advertisement with BGP-4 Publication Date : February 2009 Author(s) : J. Scudder, R. Chandra Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG
- [Idr] [Technical Errata Reported] RFC5492 (3882) RFC Errata System
- [Idr] [Errata Rejected] RFC5492 (3882) RFC Errata System