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

Jeffrey Haas <jhaas@pfrc.org> Wed, 23 June 2021 13:38 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: bgp-autoconf@ietfa.amsl.com
Delivered-To: bgp-autoconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24243A3853; Wed, 23 Jun 2021 06:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXES1GPxexTx; Wed, 23 Jun 2021 06:38:48 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A370E3A384F; Wed, 23 Jun 2021 06:38:48 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 016C91E467; Wed, 23 Jun 2021 10:04:36 -0400 (EDT)
Date: Wed, 23 Jun 2021 10:04:36 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: bgp-autoconf@ietf.org, idr-chairs <idr-chairs@ietf.org>
Message-ID: <20210623140436.GA18680@pfrc.org>
References: <20210622203227.GA17412@pfrc.org> <CAOj+MMH1qRbHjqTJAdbgV1_OGC5x18VYgzfweN3KwmwOrryDhg@mail.gmail.com> <20210623130335.GA14665@pfrc.org> <CAOj+MMEE4BZeOw0LNfHSoquocTTw_PK0KnS8YBUoefsdHhPYpg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMEE4BZeOw0LNfHSoquocTTw_PK0KnS8YBUoefsdHhPYpg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/tASKutWCvzqwlVFrkg3HHD9CHrg>
Subject: Re: [Bgp-autoconf] bgp auto configuration -01 update after interim discussion
X-BeenThere: bgp-autoconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP autoconfiguration design team discussion list <bgp-autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bgp-autoconf/>
List-Post: <mailto:bgp-autoconf@ietf.org>
List-Help: <mailto:bgp-autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bgp-autoconf>, <mailto:bgp-autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2021 13:38:51 -0000

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