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

[Jeffrey Haas <[e-mail]>]

Further off-list conversation with Tony Przygienda offer a related
observation on the BGP Session State: They serve as the "offer", and the
management of its lifetime is to a large extent the critical detail covered
by the "retry" behavior.

This potentially creates an option between 1 and 2 below.  A BGP
Auto-Discovery listener that is implementing "discover at OPEN" mostly needs
the hint that "something has changed" for the parameters that may be
discovered at OPEN.

A version/generation or similar field in the auto-discovery protocol would
suit this purpose and permit a "discover at OPEN" BGP Speaker to minimize
the load upon the auto-discovered device.  

This would permit the entire set of BGP Session Protocol State to be omitted
from the protocol, as long as "discover at OPEN" was acceptable.  It also
addresses the consistency issue noted in section 3.6 of the
autconf-considerations draft.

---

Note that the majority of proposals analyzed for BGP auto-configuration in
Appendix A published some subset of the state in the BGP Session Protocol
State requirements.  Authors of those proposals may wish to comment on their
reasoning for that state in their protocol.

-- Jeff


On Tue, Mar 16, 2021 at 05:02:03PM -0400, Jeffrey Haas wrote:
> Once you have the capability of bringing up a BGP session, you have to
> decide if you even want to.  There are at least two design choices, each
> with specific consequences:
> 
> 1. The implementation is willing to determine if a peer is acceptable or not
>    based on the information exchanged in the BGP OPEN message.  Call this
>    "discover at OPEN".  A further implication of this mode is the
>    implementation must be willing to service incoming sessions that may drop
>    just so they can figure out if they find each other mutually agreeable.
>    This becomes a scaling discussion.
> 
> 2. The implementation wants to know the properties of its potential peer to
>    decide if it wants even try to bring up a session.  This enables "peer
>    selection".
> 
>    The good property is that the peer sending such messages doesn't have to
>    service sessions only to immediately drop them.
> 
>    The bad property is that this increases disclosure of some BGP
>    information to parties that may not eventually be permitted to peer.
>    (Security consideration.)