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

[Jeffrey Haas <[e-mail]>]

On Fri, Mar 19, 2021 at 02:36:08PM +0100, Tony Przygienda wrote:
> agreed roughly. I don't have any particular likes or dislikes but observe
> that until you get an agreement on whether you use the Occam's razor of
> "only and only what gets TCP connected" or not amongst yourself you will
> not have an easy time to reach agreement on a specific design

Hence the dt document.  We have 2 (now 2.5) possible solutions to the state
problem.  The proposals analyzed use both of them in different flavors.  The
authors of a proposal should be able to justify why they put the state they
did into them.

The dt document says "this is a problem to be solved".  The WG gets to pick
what solution it likes.

> the mtu observation about packets going over different transport than TCP
> session is pretty good. On IGPs the padding is bit of a kludge (but in a
> sense a good kludge since it checks the "reality" of packets passing), I
> would venture that including MTU & other parameters description in the
> packet to make sure both sides have acceptable things and with 3-way also
> see each other and don't shout two-way only is a better design.

BFD for large packets[1] leverages similar tricks and is intended to be used
as a service.  But much like the observations karp made about crypto,
running even a generic service is problematic based on your bootstrapping
considerations.

An IGP with MTU detection can protect BGP... if BGP uses an IGP.
BFD can protect multiple services... if BFD gets to come up first - but that
may depend on routing.
Etc.

-- Jeff

[1] https://tools.ietf.org/html/draft-ietf-bfd-large-packets