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

[Robert Raszuk <[e-mail]>]

Jeff,

I am not sure if by "discover at OPEN" you mean just convention to be used
in the draft or some flag/field.

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

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.

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.

Cheers,
R.




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
>