Found 1 record.

Status: Rejected (1)

RFC 5492, "Capabilities Advertisement with BGP-4", February 2009

Note: This RFC has been updated by RFC 8810

Errata ID: 3882
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-02-05
Rejected by: Stewart Bryant
Date Rejected: 2014-03-02

Section 3 says:

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

It should say:

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

Report New Errata