Re: [Lsvr] AD Review of draft-ietf-lsvr-bgp-spf-11.txt

Alvaro Retana <aretana.ietf@gmail.com> Tue, 11 May 2021 14:48 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B433A1A59; Tue, 11 May 2021 07:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.902
X-Spam-Level: **
X-Spam-Status: No, score=2.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 59V5NNgi_ZlS; Tue, 11 May 2021 07:48:21 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98F93A1A81; Tue, 11 May 2021 07:48:20 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id di13so23209075edb.2; Tue, 11 May 2021 07:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=Wk5JXtjOe4O+JYwnJ38H9GM6tr+OXsssdxqM91zx2WU=; b=NlivbJZmMU3fLQteGmzqhUhr/YghTOVnRC3GFVDmJ1T9CsYk8bwGf/RVWWW99SiMOG BaoWUpNnvV+ZqvYNyW38ypRUP5Nk5iLS0k7rF7dlUPyIWMFBvXUXOLnd1gfaQoX5kbm6 FemIj1ekLDyzFUuIWhxVC4AS475+9mN3ft2AFZxc/6LtTv60QlBmuESq6TJINGwX0Coe NyLVvTOIY7mSp8mnl8Qe0k/wSmpYIgikI46UuqlphRnaWPVlBTbAI/eHA8S7bEnXdX4G 1sfeyVUYDXLCtZuJdYjoq6J2bMZ0nufLx0IE3DglxQA3MkOF2RAhJNcjI7NRmiZprEUa meeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=Wk5JXtjOe4O+JYwnJ38H9GM6tr+OXsssdxqM91zx2WU=; b=deppzKYUE47ndzYuBV43/mCein7xTK184ZJitZvMLSlKUCu57/rxUMD8GsFCOI/mY2 HwpFCbCw671S54bqCVr4Nu1bF2Jm3C6t28ApgmHPWW4Zx4rRRUsxDjYaZR2F8Ta7R1t6 qnQev5+37xP1bLTuoTBChGScMZwQ1NRgCsO2Gw1znGv/BO0GQPKbCPb7+gd/mc3xHnJk HvUd1hC3rvSYwHvu77Jwgmo7Y479Xl3fxeLBc8jSyZt9sP+JCXj2suEbVDFh9/vNaWC4 CWYaclziULFzi3X5RmPbxknPohu3fT0TVMKNiCdlWXm/9MZWEMaEUBuzm1FkWH7MsL9D eB3w==
X-Gm-Message-State: AOAM530rCHKfaBp/8QcFcGzkj2X9eyzgayCg8PuYffnztb4LMMadSKR5 IBY+ytvEANQ4UE6JCtH6cBgffQTJoJ0Zuqfp9hY=
X-Google-Smtp-Source: ABdhPJy6ySJDsYWN3rDJh+RYN60BXTMajMmDYvdXO2NHYC7cp667Dl743nSILxfd0dcNyRKvJdaHBzjkmypffRtNQBA=
X-Received: by 2002:a05:6402:17d8:: with SMTP id s24mr36536463edy.155.1620744494113; Tue, 11 May 2021 07:48:14 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 May 2021 07:48:13 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <F1DFEA4B-600C-4989-AA84-F81AAF3BD19B@cisco.com>
References: <F1DFEA4B-600C-4989-AA84-F81AAF3BD19B@cisco.com>
MIME-Version: 1.0
Date: Tue, 11 May 2021 07:48:13 -0700
Message-ID: <CAMMESsx3UbaExJFUzvvNMFYc9NKQEfRDJ0TDqVmo=sUPnNf2uA@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Victor Kuarsingh <victor@jvknet.com>, lsvr-chairs@ietf.org
Cc: "draft-ietf-lsvr-bgp-spf@ietf.org" <draft-ietf-lsvr-bgp-spf@ietf.org>, "lsvr@ietf.org" <lsvr@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/57uKIUZpYSGbcvT9CWrYZ9ooGQk>
Subject: Re: [Lsvr] AD Review of draft-ietf-lsvr-bgp-spf-11.txt
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2021 14:48:31 -0000

On February 15, 2021 at 10:55:53 AM, Acee Lindem wrote:


Acee:

Hi!

I took a quick look at the diffs (11-13) and the document looks in
much better shape!  Thanks!  I will take a deeper look when the WG is
done with it, but I don't anticipate as many comments.

I have to confess I was a little bit worried about this part:

> > I approached this document from the point of view of it defining a *new*
> > link-state protocol, one that borrows from existing work.  I am loosely
> > defining "protocol" here as a set of rules for what happens inside a
> > specific AFI/SAFI that doesn't carry "traditional" BGP routes, similar to
> > BGP-LS, FlowSpec, etc.  Specifically, I see BGP SPF as the sum of the BGP
> > base as transport + BGP-LS encodings + SPF-based route calculation.  ...
>
> The authors don't really agree that this is a completely new link-state
> protocol. We've added to clarify the relationship to both the BGP base
> protocol and BGP-LS.

However, your explanation about the relationship is clear and helps in
better understanding the document.  :-)


This is for the Chairs/Shepherd:  As Acee mentions, keep in mind that
the document is back in the WG -- IOW, you should not be waiting for
me. :-)  It is important for the WG to review the updated document (a
new WGLC will be required of course).  There are several points that
Acee calls out that need discussion in the WG (see below).  Also, I
need you to specifically ask for comments from idr and lsr (which
could be done at the same time as the WGLC).

Thanks!!

Alvaro.


> Thank you for your extensive review and comments. Now that the document
> is back in the WG, we have couple things to discuss in the WG:
>
> 1. NLRI packing - Well it is almost implied, I think we need to
> limit a BGP Update to a single NLRI and BGP-LS Attribute.
>
> 2. Initial synchronization - we need to discuss this in the draft
> and potentially add an option to require this, such as the IS-IS
> suppress adjacency option. I don't think we'd want to require
> this as it would limit deployment.
>
> 3. NEXT_HOP requiremeent - We now say we are following RFC 4760.
> However, we need to be sure we are consistent throughout.
>
> 4. Single session requirement for BGP-LS. Right now we don't
> prevent this.



...
> > The mail archive contains early requests to both idr/lsr for review,
> > but no answers. :-( I would like both of those WGs to (again) be
> > given the opportunity to comment -- we can do that as this document
> > addresses some of my concerns. [I'm putting this note here so we
> > don't forget.]
>
> It is better that LSR and IDR review the updated version as the changes are
> significant.