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? (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) Thanks, Joe
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
Danny McPherson wrote:
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.
Unless there is actual utility gained by B learning the hard way that A doesnt support this capability, rather than by not receiving the same capability in A's OPEN, I would not consider this behavior reasonable. And rfc3392 specificaly says A BGP speaker determines the capabilities supported by its peer by examining the list of capabilities present in the Capabilities Optional Parameter carried by the OPEN message that the speaker receives from the peer. Not by hit or miss with NOTIFICATION messages. And as I read it, rfc3392 makes absolutely no mention of my case.
(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.
Which document is this? Are you quoting? In any event the above is not observed behavior either, as the 500 log messages on the peer's (the one sending capability 64) support desk attest to. Does your paragraph also suggest that B SHOULD NOT send the capability when A automaticaly tries to reconnect? Should A (the peer that sent the notification upon receipt of capability 64) NOT try to automatically reconnect?
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.
This isnt an intellectual excercise, its something that operationaly affects me. Perhaps it has, is, or will affect any of the operators who subscribe to this list. Since I may have to go to bat against the vendor on this one, I thought I would obtain some operator opinion beforehand. I hope that satsifies the on-topic police.
-danny
Thanks for your reply.
On Aug 18, 8:31am jmaimon@ttec.com wrote:
This isnt an intellectual excercise, its something that operationaly affects me. Perhaps it has, is, or will affect any of the operators who subscribe to this list.
Since I may have to go to bat against the vendor on this one, I thought I would obtain some operator opinion beforehand.
I can't see the on-topic police having any problems with this, unless "network operations" have degraded to a point marginally above machine-level automation. If it has, what is NANOG's purpose? As one who has both created a BGP implementation from scratch and have operated many, I think I can help you. It's easy to confuse the announcement of a particular capability with announcement of capabilities altogether. RFC3392 is clear enough, but doesn't underline the point, and also doesn't mention any administrative aspects. The idea is that if a speaker supports capabilities negotiation, it will include a BGP optional parameter in its OPEN message, listing the capabilities it supports [Sec 3 Para 1]. The receiving speaker may or may not support capability negotiation; if it doesn't it has no choice except to send an error notification with error code "unsupported optional parameter", and the originator should restart but not send any capabilities parameter [Sec 3 Para 4]. (If that is actually acceptable is partly an administrative issue, but implementations vary.) Assuming both peers support capability announcements, they would each inspect the list of capabilities supported by the other [Sec 3 Para 2], and determine if this satisfies their needs [Sec 3 Para 3,5]. This is a partly administrative issue, and implementations have, well, varied. If one peer strictly requires a particular capability that the other doesn't support, it will send an error notification, terminate the session, and not restart [Sec 3 Para 5]. The idea here is that the problem is beyond protocol level negotiation (ie, it isn't eg just an optimization), and requires human intervention. Otherwise, assuming no strictly required capabilities are missing on either side, the session goes ahead on each side, with each peer respecting the capabilities it understands the other peer supports. The whole capability thing is very much an afterthought to BGP; proper negotiation could well require several transactions, but that would require obvious changes to the BGP protocol itself. Consequently, actual support and behaviour for capabilities has seen some variation between implementations and also between different versions and releases. Things should have been reasonably settled by now, though, so I suspect one of your peers is running old software. As for the capability you mention (code 64), this is Graceful Restart, see http://www.iana.org/assignments/capability-codes Graceful Restart is an optimization, and nothing prevents peering without it. Hence, you should not see repeated terminations and restarts, the session should simply go ahead without using Graceful Restart. Best, -- Per
participants (3)
-
Danny McPherson -
Joe Maimon -
Per Gregers Bilse