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

[Claudio Jeker <[e-mail]>]

On Thu, Apr 18, 2024 at 10:45:26AM -0400, Jeffrey Haas wrote:
> 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 I agree that incremental deployment is important it is also
important to do incremental deprecation.  RFC 3392 is from 2002, lets hope
that before its 30st anniversary we're able to count on the availability
of it.
 
> > 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.

At some point "vanilla" RFC 4271 needs an update. We are collecting more
and more technical dept because of backwards compat. One day that will
blow up.
 
> >> 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.

Now what do you put in the payload of the 4-byte ASes capability? Your
ASnum, the ASnum you expect, something else since it does not matter
anyway?

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

We send back the first missing AFI/SAFI pair. Isn't it great that we all
can come up come up with something different :)
 
> 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.

Yes, capabilities are very much opt-in. While I think it is good that both
sides need to agree, it should also be possible to enforce certain
features (4-byte ASes is a good example).
 
> > 
> > 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.
 
Right now we just warn and ignore them as long as the length encoding
works out. I would prefer to throw a notification for capabilities with
bad lengths so I will probably change our code. In general being strict
is better in the long run.
 
> 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.  

I guess one can select from various OPEN NOTIFICATION subcodes. In the end
issues like this will be handled out of band.
 
> > 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)
> 

Thanks for your input and time.
-- 
:wq Claudio