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

[Tony Przygienda <[e-mail]>]

I don't see how the "discovery protocol" chosen matters except the
transport things I mentioned (and fragmentation if you kitchen sink it and
choosing how simple it is to implement vs. how close to hardware, UDP is
one point in spectrum, the other taking LLC SNAP type AFAIS ;-).

the key distinction I see here is whether you go along the philosophy of
"only minimum to reliably bring session(s) up" (which is already enough,
BFD, AF mixes, faith sharing and all the stuff IGP does today for BGP are
non trivial to get right) or "kitchen sink incl. replicating capabilities".

after that you still have to deal with semantics of an "offer". In RIFT
after pondering that for quite a while and despite Jeffrey pushing for
independent protocol the whole negotiation of ZTP stuff including levels
etc has been put onto LIEs (hellos) for the reason that LIEs have timeouts
on them so it's pretty clear how long something is of importance.
Obviously, IGPs are much simpler because the lifetime of offer is @ same
time lifetime of the "session" whereas here the TCP session is kind of
"floating" around the offers. Thinking of which, the 3-way stuff in IGPs
has saved our bacon more than once and this discovery protocol should
probably put that in also deal with stuff like MTU size given that
mismatching those makes for a bad hair day and there is no IGP now to do
all the heavy lifting for the mighty BGP to demean itself to run the
allmighty TCP protocol over it ;-)

-- tony

On Fri, Mar 19, 2021 at 1:14 PM Acee Lindem (acee) <acee=
[e-mail]> wrote:

> The avoidance of the these complexities is one advantage of an independent
> discovery protocol. Another advantage is that it could serve use cases
> beyond BGP.
>
> Thanks,
> Acee
>
> On 3/18/21, 3:00 PM, "Idr on behalf of Jeffrey Haas" <
> [e-mail] on behalf of [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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>