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