Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

[John Scudder <[e-mail]>]

> On Jan 12, 2023, at 12:48 PM, Robert Raszuk <[e-mail]> wrote:
> 
> 
> Hi John,
> 
> But as you see based on real life deployments the very same happens with BGP Capabilities too hence not much of practical difference. 

I disagree. Yes, it’s true that there have, historically, been implementations that have a bug. Some blame falls to me — that Notification code should never have been called “Unsupported Capability” — even though the spec was ‘right’, the naming was wrong. :-( But I think the updated language in RFC 5492 is explicit enough that anyone still shipping this class of bug almost 13 years after publication has a lot of explaining to do. 

> And section 3 of RFC5492 allows so ...
> 
>    If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer and terminate peering (see Section
>    "Extensions to Error Handling" for more details).

No. You’re taking that quote out of context, you left out the example that follows — and that example should already have been enough for you to understand your mistake. The behavior allowed by RFC 5492 is, “if I needed my peer to send me a capability, and it didn’t, then I can close the session”. The problematic behavior with respect to Optional Parameters is “if my peer sent me a parameter I don’t understand, then I must close the session”. These are completely different things. The first is caused by a thing that is not there. The second is caused by a thing that is there. The two examples you sent earlier are a third category, a bug where some implementor decided to do the wrong thing. If it’s a recent version then shame on them, see above.

> The only difference seems to be MUST in RFC4271 in respect to Unsupported Optional Parameters vs MAY in RFC5492 in respect to Unsupported Capability.

No. See above.

The bottom line is, Capabilities are BGP’s main extensibility mechanism. In my opinion (as, to be clear, an individual contributor to the WG) they work OK and are fit for purpose, notwithstanding historical implementation errors. They are suitable for the extension under discussion, just as they are for other extensions.

On the other hand, if the WG thinks Capabilities are *not* fit for purpose, the WG should get to work on a replacement that obsoletes and replaces RFC 5492. But saying “oh we’re too scared to extend the protocol because there were bugs in the past” does not seem like a good way to proceed.

FWIW, as far as I know, the behavior permitted by the paragraph you quote has never been used. If that’s true, it might not be a bad idea to do an update of RFC 5492 that removes the paragraph and deprecates the Unsupported Capability error code entirely, to avoid future generations going through the same confusion. If the WG wants to do this, I’d be willing to participate, although the first step would be to do a survey to make sure nobody actually is making use of the feature and I’d want someone else to lead on that.

—John