Re: [Idr] BGP Auto-Discovery Protocol State Requirements

[Jeffrey Haas <[e-mail]>]

On Fri, Mar 19, 2021 at 10:54:19AM +0100, Robert Raszuk wrote:
> I am not sure if by "discover at OPEN" you mean just convention to be used
> in the draft or some flag/field.

As I tried to make clear in a few formats, there are two things you need to
discover a BGP speaker, or perhaps more precisely an ACCEPTABLE one:
1. You need enough information to bring up your BGP peering session.
2. You need to see enough of the session's parameters to know whether you'll
   keep the session, or drop it.

"Discover at OPEN" means you don't get the BGP session's parameters in the
discovery protocol itself.  You have to get them by connecting to the
discovered peer.

> If this is just the convention it is fine. Discover at OPEN is exactly what
> I had in mind writing
> https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-session-setup-01

See Appendix A.3.2 for the analysis.

> If however you think about signalling it as part of auto-discovery then I
> think we do need to keep in mind that BGP4 MUST continue to operate fine
> without auto discovery. That means that all negotiation and checks still
> MUST happen natively in BGP - so they will happen anyway.

Discovery doesn't change any of that.

> Or maybe you wanted to relax this and say if lots of things have been
> already auto discovered we can send OPEN-lite ?
> 
> Of course down the road we may reach conclusion that configuration of BGP
> session is the thing of the past and bump BGP version to operate in the
> "modern" style but this moment I think still a bit ahead of us.

Discovery doesn't change the BGP state machine.

I think a point lacking in most of the proposals is how they're intending
the feature to be used.  That's setting a number of conflicting expectations
in the heads of the authors.

Examples:
1. Whatever you plug into this port will be fine, just connect me!
2. I'm willing to only connect to peers over ipv6 link local, or some
   specific family.
3. I'm only interested in peers that support specific AFI/SAFI
4. I'll only connect to peers that acceptable ASes in this range.
5. I only want one peering session with a given router.

etc.

To be able to determine if a peer is going to be acceptable, you have to
know something about what it is going to do.  You can get that information
from the auto-discovery protocol and not need to establish a BGP session, or
you can establish a bgp session and get it that way.  

If you continue because the session is acceptable, this is the easy case.

If you decide the session unacceptable, what do you do?
1. If you get the session parameters from discovery protocol, you wait until
   you see an offer that is acceptable.  "Shouting it to the world" is cheap.
2. If you get the session parameters from starting a bgp session, how do you
   decide whether you try again later?  

The "keep hammering on BGP" option is problematic.  Several implementations
start rate limiting incoming session requests.  This is because an incoming
session causes resources to start to be allocated, even if they're just
sockets.  

This is generally not a problem for existing BGP speakers because you don't
configure what you don't want to use.  But once you introduce
auto-configuration, you end up with the same problem as hundreds of sessions
that are misconfigured trying to get into your box every X seconds.

-- Jeff