[91891] in North American Network Operators' Group
Re: BGP unsupported capability code
daemon@ATHENA.MIT.EDU (Danny McPherson)
Fri Aug 18 03:47:32 2006
In-Reply-To: <44E548A1.3020202@ttec.com>
From: Danny McPherson <danny@tcb.net>
Date: Fri, 18 Aug 2006 01:48:18 -0600
To: NANOG <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
On Aug 17, 2006, at 10:57 PM, Joe Maimon wrote:
>
> If A tries to peer with B, and B sends a BGP capability 64 to A, if
> A does not support that capability what would proper and/or
> reasonable behavior for A be?
Speaker A MAY send a NOTIFICATION message with Open
Message Error/Error Subcode "Unsupported Capability" and
a data field listing capability 64 as the trigger for the
NOTIFICATION to speaker B (thereby terminating the session).
However, RFC 3392 does NOT require that the local BGP
speaker terminate the connection, which has particular utility
when considering the implications such a hard requirement
may otherwise impose on functions such as dynamic BGP
capabilities.
> (a "published" source for it, if you could possibly do so.)
>
> a) send
>
> unsupported capability code 64 lengh 6
> ## 2006-08-17 19:17:05 : [bgp/stack]: send NOTIFICATION msg
> code (Open-Error)
> subcode(Open Message Error: Unsupported Capability) to peer
> w9.x4.y7.z9 via socket 415
>
> b) ignore it
>
> c) admin defined
>
> rfc3392.txt only appears to address the case where if A tries to
> peer with B, and B sends a BGP capability 64 to A, if A does not
> support that capability, B MAY terminate the connection with the
> above notification.
>
> (section 3 paragraph 5)
If the peer doesn't support the capability and this is conveyed
from A to B via a NOTIFICATION message (as illustrated in the
log message above), then given the scenario you provide B
SHOULD NOT include the capability (64) in any subsequent
OPEN message sent to A when attempting to reestablish a
BGP connection -- IF B so chooses to attempt to automatically
reestablish a connection. Note that the above says SHOULD
NOT, not MUST NOT.
I'm not quite sure what your point above is, as I think the
document sufficiently outlines the required behavior.
Although BGP is perhaps (?) still of interest to the NANOG
community, I suspect such protocol intricacies are not and
would submit that queries of nature are best directed to
idr@ietf.org.
-danny
