Re: [Bgp-autoconf] Short comparison of the different documents.

Jeffrey Haas <jhaas@pfrc.org> Wed, 04 March 2020 22:01 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 79D013A0A1E for <bgp-autoconf@ietfa.amsl.com>; Wed, 4 Mar 2020 14:01:34 -0800 (PST)
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 z2yimkOstSUy for <bgp-autoconf@ietfa.amsl.com>; Wed, 4 Mar 2020 14:01:33 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5E3A0A21 for <bgp-autoconf@ietf.org>; Wed, 4 Mar 2020 14:01:32 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 0BEDB1E2D6; Wed, 4 Mar 2020 17:07:28 -0500 (EST)
Date: Wed, 04 Mar 2020 17:07:27 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Warren Kumari <warren@kumari.net>
Cc: bgp-autoconf@ietf.org
Message-ID: <20200304220727.GC32422@pfrc.org>
References: <CAHw9_i+0rDUJOR3mAMAh9+whaKX0Koc_VaibbfX1zRzocOAvhw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHw9_i+0rDUJOR3mAMAh9+whaKX0Koc_VaibbfX1zRzocOAvhw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bgp-autoconf/60QdyTfse2DPD1Z4FZ8CEifDCkQ>
Subject: Re: [Bgp-autoconf] Short comparison of the different documents.
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, 04 Mar 2020 22:01:35 -0000

Warren,

On Sat, Feb 29, 2020 at 03:52:14PM -0500, Warren Kumari wrote:
> 4: BGP LLDP Peer Discovery - draft-acee-idr-lldp-peer-discovery
> ------------------
> This seems like a very good option to me -- LLDP is a well-known, well
> implemented protocol. It also already carries information which solves
> much of the "auditability" (are the cables right?) use-case.
> I am concerned about the possible message size limits

The size consideration is valid.  It does mean that if we end up with a
large bit of configuration blob that baseline LLDP is no longer suitable.

There is work going on in IEEE that will permit larger stuff for LLDP.
But for purposes of our analysis I don't think we are specifically hung up
on that expectation.

> The document does still need work -  e.g it talks about Session
> Group-IDs, but is very handwavey about what they are / what you do
> with them.

This was intentional. :-)  Much like "color" or "tag" or "community", we
have situations where we want to tag a bit of discovery in a way that
flexibly allows the deployment to decide what things mean.

Easy examples of this was role in a switching fabric.  

I think for purposes of our analysis, the property I'd prefer to highlight
is that discovery information may carry a way of marking that information
for purposes of letting listeners do something useful.  This markup may
carry non-standardized code points.  We may wish to design standardized code
points as well for specific profiles, for example fabrics.

-- Jeff