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

From: Alvaro Retana <[email-masked]>
Date: Tue, 11 May 2021 07:48:13 -0700

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.