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

Jeffrey Haas <jhaas@pfrc.org> Wed, 23 June 2021 12:37 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 90AFF3A3681; Wed, 23 Jun 2021 05:37:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AUfpYxTutiHT; Wed, 23 Jun 2021 05:37:48 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D94453A367D; Wed, 23 Jun 2021 05:37:47 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id E92631E467; Wed, 23 Jun 2021 09:03:35 -0400 (EDT)
Date: Wed, 23 Jun 2021 09:03:35 -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: <20210623130335.GA14665@pfrc.org>
References: <20210622203227.GA17412@pfrc.org> <CAOj+MMH1qRbHjqTJAdbgV1_OGC5x18VYgzfweN3KwmwOrryDhg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMH1qRbHjqTJAdbgV1_OGC5x18VYgzfweN3KwmwOrryDhg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/b0yEJ_NxJ-7aq8E5wjqCPWjoqkA>
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 12:37:50 -0000

Robert,

On Wed, Jun 23, 2021 at 07:47:02AM +0200, Robert Raszuk wrote:
> I think one thing from the list below requires a bit of clarification ...
> specifically this is about AFI/SAFI list.
> 
>    BGP Session Protocol State, discovered at BGP OPEN:
> 
>    *  AS Numbers
>    *  BGP Identifier
>   * *  Supported AFI/SAFIs*
> 
> 
> So I have two questions:
> 
> 
> Q1 Assume operator needs to enable new AFI/SAFI at some point. How
> would it work as far as auto discovery is concerned ?

In my opinion, it's uninvolved beyond perhaps bumping the version number in
the auto-discovery packet.

The feedback from the working group is that afi/safi is not to be contained
in those packets.  So, if you're already peering with the discovered peer,
it's no different than if there's a configuration change to an existing
session.  If you're not peering with it because the session was previously
unacceptable, the version number is bumped, the client can connect and see
if the contents of the OPEN are acceptable, and then peer - or not.

> Q2 Assume we use dynamic capabilities (only for AFI/SAFI update) how
> would it work with auto discovery if at all ?

I'd consider it out of scope since it's not a deployed feature.

> I guess the bigger question here is the scope of auto discovery.
> 
> 
> Is auto-discovery simply bootstrap any BGP relation between peers ?
> 
> 
> or
> 
> 
> Is auto discovery required/to be also used in run time when adding new
> AFI/SAFIs for already established session(s) ?
> 
> 
> The reason for this is that what we are doing is essentially
> duplicating AFI/SAFI from BGP OPEN which I am not sure if this is a
> feature or a bug.

This information is not carried in the auto-discovery PDU.  It is learned
from connecting to the peer and learning it from the OPEN message.

If you think the text doesn't adequately explain that, please supply some
clarifying text.

> Lastly, how about cases where endpoints have configured potential
> peering, however it is not activated in cfg. Assuming that we would
> still want to signal those in autodiscovery would you send it when
> enabled and not activated on a neighbor ?

I have no idea what this might mean.

If you haven't activated it in configuration, why would the discovery
protocol advertise an endpoint is available?

-- Jeff