[Idr] [Errata Rejected] RFC5492 (3882)

[RFC Errata System <[e-mail]>]

The following errata report has been rejected 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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Ramakrishna DTV <[e-mail]>
Date Reported: 2014-02-05
Rejected by: Stewart Bryant (IESG)

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."
 --VERIFIER NOTES-- 
This is a technical matter that should be discussed in the WG and if the WG decides that clarification is needed it should be addressed in an RFC.

The text referenced above is a SHOULD, and thus an implementation decision. The provision of further guidance to the implementer is outside the scope of the errata process.

--------------------------------------
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