nanog mailing list archives
Re: BGP unsupported capability code
From: Danny McPherson <danny () tcb net>
Date: Fri, 18 Aug 2006 01:48:18 -0600
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 415b) ignore it c) admin definedrfc3392.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
Current thread:
- BGP unsupported capability code Joe Maimon (Aug 17)
- Re: BGP unsupported capability code Danny McPherson (Aug 18)
- Re: BGP unsupported capability code Joe Maimon (Aug 18)
- Re: BGP unsupported capability code Per Gregers Bilse (Aug 18)
- Re: BGP unsupported capability code Joe Maimon (Aug 18)
- <Possible follow-ups>
- Re: BGP unsupported capability code Mike White (Aug 21)
- Re: BGP unsupported capability code Danny McPherson (Aug 18)