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

[Tony Przygienda <[e-mail]>]

Once you go to version number the issue of underlyng transport behavior
starts to come to the fore. UDP & sometimes L2 can misorder, _badly_, from
experience. In most extreme cases in virtualized environment I saw UDP
being buffered & misorderd up to 5 seconds delay. That''s surely extremely
and until seen bits hard to believe but here you are and you start to look
once your adjacencies with 3 sec lifetime start to bounce & do _really_
weird stuff on AF negotiation (since one node talks to the other being 5
sec in the past ;-)  I debugged that one by establishing a baseline clock
using reflected numbers in hellos because otherwise none of the logs made
any sense ;-)

-- tony

On Thu, Mar 18, 2021 at 7:58 PM Jeffrey Haas <[e-mail]> wrote:

> 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.)
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>