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

[Tony Przygienda <[e-mail]>]

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

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.

-- tony

On Fri, Mar 19, 2021 at 2:28 PM Jeffrey Haas <[e-mail]> wrote:

> Tony,
>
> On Fri, Mar 19, 2021 at 01:56:27PM +0100, Tony Przygienda wrote:
> > 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 ;-).
>
> There's some discussion in the draft about what transport layer we use, and
> a few of the headaches.  For BGP auto-discovery, the major implication is
> how wide your want your messages to travel.
>
> I won't argue your issues about the headaches in a given layer.
>
> > 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".
>
> Do you have to bother the BGP speaker to figure out if you want to talk to
> them or not?
>
> If you do, how do you handle retries.
>
> Those questions have to be answered.  You can not like a given mechanism
> all
> you like, but if you want to provide constructive criticism, describe how
> to
> do it better.
>
> > 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.
>
> Lifetime is a good point, and one that isn't in the current draft.  Section
> 3.2 mostly talks about how chatty to be, which might hint a bit about
> implicit lifetime.  (E.g. 2-3x the advertising window.  BFD makes that
> explicit for reasons you'll likely get to.)
>
> > 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 ;-)
>
> The IGPs might get it right if they use padding TLVs, but it was certainly
> not baked in up front.
>
> The autoconf considerations draft is intentionally silent on whether the
> design MUST have some sort of adjacency.  Some of the proposals are "shout
> into the dark" multicast style.  draft-xu-idr-neighbor-autodiscovery
> basically replicates LDP state machinery, including a full adjacency.  But
> it also discusses impacts on the BGP FSM by tying the fate of the BGP
> session to the auto-discovery session.
>
> MTU mis-matches are definitely a topic of interest elsewhere in IETF.  My
> personal opinion is that trying to solve it in auto-discovery is
> problematic
> in a few respects.  The biggest one is that the discovery protocol may run
> at a different layer (L2/L3) or different address family than the actual
> session.  Even if we did discover an acceptable MTU, most stacks want to
> interact with this either through configuring TCP MSS or performing PMTU-D.
> Whether you want this stuff to get added to your RFC 4271 style BGP session
> setup is where that leads.
>
> -- Jeff
>