North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: BGP unsupported capability code
Danny McPherson wrote:
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)
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?
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.
Thanks for your reply.