Re: [Bgp-autoconf] bgp auto configuration -01 update after interim discussion

[Robert Raszuk <[e-mail]>]

Hey Jeff,

Ok this sounds good. I was not clear - apologies if I did not get this from
Interim.

One related and one unrelated question:

Related:

* Assume we did not reach mutually interesting AFs to establish session and
we suppressed OPENs as you said. Now if I add a new AF on either side - do
I need AD PDU or can I just try BGP OPEN as I already know the peer(s) ?

Not related:

Just like in BGP perhaps we should also support passive AD side ? Say in
leaf <--> spines or leaf <--> controller that can be perhaps useful
optimization.

Thx a lot !
R.












On Wed, Jun 23, 2021 at 3:38 PM Jeffrey Haas <[e-mail]> wrote:

> On Wed, Jun 23, 2021 at 03:16:06PM +0200, Robert Raszuk wrote:
> > Hi Jeff,
> >
> > I am referring to this slide
> >
> > [image: image.png]
> >
> >
> > > The feedback from the working group is that afi/safi is not to be
> contained
> > > in those packets.
>
> As we discussed in the interim, slide 4 was the contents we discussed at
> prior IETF 110.
>
> Slide 5 covered the discussion that while this state is needed by the
> auto-discovery procedure, the session state could be gathered from the BGP
> OPEN message as "discovery at open".
>
> It's still state for an auto-discoverying peer needs.
>
> > So are you saying that AFI/SAFI will not be part of the auto discovery ?
>
> Correct.
>
> Tersely:
> Auto-discovery PDUs containing sufficient information to do a BGP
> connection
> are sent in their protocol.
>
> A client that is receiving those auto-discovery PDUs creates and opens a
> BGP
> session to that endpoint.  It then has the information present in the BGP
> OPEN.
>
> If the client decides that it wishes to continue peering with the
> discovered
> endpoint (the peer is acceptable), it sends its KEEPALIVE message and
> transitions to Established.
>
> Otherwise, the peer is unacceptable, and the client tears down the session
> with a NOTIFICATION message.
>
> The remaining procedures are intended to avoid repeated connection attempts
> where no progress will be made:
> - The client doesn't initiate any new connections to the discovered peer
>   unless its own acceptance criteria have changed for the session, or the
>   version number in the auto-discovery PDU changes from the last version
>   tried.
> - When either changes, the process above repats.
>
> > Then I am not quite sure why do we then even talk about it ? Especially
> > looking at the slide it seems like this is part of AD.
>
> Hopefully the interim's recording will be posted and won't have the
> problems
> many people experienced with meetecho.  The context was clear during the
> interim.
>
> However, the description above is what the consensus was.
>
> -- Jeff
>