BGP unsupported capability code

Fri Aug 18 12:31:24 UTC 2006

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