Re: [Idr] Questions regarding BGP capabilities (RFC5492)

[Jeffrey Haas <[e-mail]>]

Claudio,


> On Apr 18, 2024, at 10:22 AM, Claudio Jeker <[e-mail]> wrote:
> 
> On Thu, Apr 18, 2024 at 09:02:10AM -0400, Jeffrey Haas wrote:
>> 
>> 
>>> On Apr 18, 2024, at 6:32 AM, Claudio Jeker <[e-mail] <mailto:[e-mail]>> wrote:
>>> Are there still BGP implementations out there that do not support
>>> capabilities (RFC5492)?
>> 
>> "Implementations", yes.  From current vendors or major open source packages, probably not.
>> 
>> BGP-4 is simple enough for basic ipv4 applications that people continually make their own stuff even in spite of available tooling.
> 
> Guess people need to slowly update their own stuff :)

A strong lesson of BGP, and partially covered in the IETF 119 technical deep dive talk I gave with John Scudder, is reminding everyone about incremental deployment.  Part of that lesson is old software lingers for a very long time.


> While we can configure session to have no capabilities (you need to turn
> of 4-byte ASN, open policy and rrefresh) it is not our default. So people
> with their own stuff need to fumble extra config knobs. Also I wonder how
> many of those "implementations" do proper error handling :)

My implementation advice would be that most general purpose BGP stacks should have the ability to fall back "vanilla" RFC 4271.

Special purpose stacks can do whatever they wish, although I'd similarly remind implementors that Bad Things done in a local stack can leak into the Internet and cause damage if you're not careful.  Based on some of our outages over the years, "not careful" is too common.

>> Generally, the desired behavior is you list the state you don't like.  
>> 
>> State you want but isn't present shouldn't be sent back in the notification.
> 
> Isn't that the inverse of the text in the RFC?
>    ... the Unsupported Capability NOTIFICATION is a way for a BGP speaker
>    to complain that its peer does not support a required capability 

It's a regular point of contention, yes.  I suspect John Scudder even has some specific stuff in his archive covering the point.

The use cases are mixed:
- A router requires you to have a specific capability supported to let the session come up.  Pick, for example, 4-byte ASes.  That's something you could signal in your notification.
- For features like multiprotocol that send a vector of things, what do you send back?  Your own set, which the peer has already seen?  Their set, which you didn't like? (Juniper's behavior).

A thing that has complicated this over the years is if you don't like a capability, you're welcome to ignore it.  Most features signaled by capability require both sides to assent to its use.


> 
> At least my understanding is that 'Unsupported Capability NOTIFICATION' is
> used to inform the peer that a required capability is missing. Stuff you
> don't like falls under:
>    It MUST NOT be used when a BGP speaker receives a capability that it
>    does not understand; such capabilities MUST be ignored.
> 
> In fact my interpretation of that sentence is that even badly encoded
> capabilities need to be ignored and no NOTIFICATION should be sent back in
> that case.

Syntactically invalid capabilities are good reason to not permit the session to come up.

If the high level enveloping of the capabilities are good, you only know that it's syntactically invalid if you understand the capability in question.

Juniper's choice for reporting such malformations is a bit peculiar, but picking the most appropriate code/subcode for notifications is a favorite discussion point for implementors.  Fundamentally, if the code/subcode doesn't trigger a FSM behavior, the notification is good enough to terminate the session, and if you're lucky the code/subcode provides opportunity for encoding some hint to the peer about what you didn't like.

If the peer didn't encode the right thing... too bad.  Reacting to bad notifications when the session is down is largely impossible.  

> 
> Guess our handling is good enough.

Which is often how such conversations go.

-- Jeff (still filing the bug on the error data in his own implementation)