Re: [Lsvr] WGLC for draft-ietf-lsvr-applicability-09 (to end May 4, 2023)

[Ketan Talaulikar <[e-mail]>]

Hello Authors,

Following are some review comments based on the latest version of the
document:

1) Please update reference to RFC7752 (BGP-LS) with
draft-ietf-idr-rfc7752bis

2) Section 6 refers to the use of BGP-LS in BGP-based DCs as a matter of
fact. I am not sure to what extent this is deployed, but regardless there
is no reference to draft-ietf-idr-bgp-ls-bgp-only-fabric which is the spec
that covers how BGP-LS reporting of topology in BGP-only networks is done.

3) Section 6.1 talks about the use of traditional BGP along with BGP-SPF,
but the motivation or applicability of when and why this would be done is
not described. I think it would help if some guidance is provided on when
and how BGP-SPF should be used/deployed with other BGP address-families.

4) Section 6.1.1 says the following:

"However, if BGP-LS NLRI is also being advertised for controller
consumption, there is no need to replicate the Node, Link, and Prefix NLRI
in BGP-NLRI. Rather, additional NLRI attributes can be advertised in the
BGP-LS SPF AFI/SAFI as required (e.g., BGP-LS TE metric extensions
[RFC8571] and BGP-LS segment routing extensions [RFC9085])."

It is not clear to me what this means. Additional attributes/extensions
cannot be advertised without the NLRIs being also advertised. Something
does not parse well in the above paragraph. Can you please clarify?

5) Section 6.2. For the controller based peering model, the draft does not
explain how the reachability between the routers and controllers is
achieved. Such guidance would be helpful.

6) Section 6.3 says the following, but does not explain or describe how
things work without such advertisement. It seems like the DC is split into
areas/levels/domains, but those details are not specified. Right?

 "In Spine/Leaf topologies, it is not necessary to advertise BGP-LS NLRI
received by leaves northbound to the spine nodes at the level above."

7) Section 6.4 & 6.5 - why is peer discovery mandatory for BGP SPF. Why
would it not work with peers being provisioned via some configuration or
other automation mechanism?

8) Sec 8 & 6.3, talks about aggregation. However, in traditional link-state
routing protocols, such/any aggregation is done at between
areas/levels/domain - not within an area. How is BGP SPF going to be able
to do something different?

9) Some normative language should be removed from sec 6.5.1 and then remove
sec 2.

Also, a general suggestion: RFC7938 is one document that is widely
referenced and referred to when it comes to deployment of BGP as the
underlay routing protocol in DCs. One can think that BGP-SPF is in some
ways building on top of it and bringing additional features/advantages.
Perhaps the authors may wish to consider referencing and leveraging RFC7938
as a base for providing deployment guidelines and applicability for BGP-SPF?

Thanks,
Ketan
(as a WG member)

On Thu, Apr 20, 2023 at 2:33 PM Gunter van de Velde (Nokia) <
[e-mail]> wrote:

> Hi All,
>
> The LSVR WG initiates a new working group last call for
> "draft-ietf-lsvr-applicability-09".
> Please send your comments to the list before EOB Thursday May 4, 2023.
>
> https://datatracker.ietf.org/doc/draft-ietf-lsvr-applicability/
>
> The current document went through early RTG-DIR and OPS-DIR reviews.
>
> https://datatracker.ietf.org/doc/review-ietf-lsvr-applicability-09-rtgdir-early-venaas-2023-04-14/
>
> https://datatracker.ietf.org/doc/review-ietf-lsvr-applicability-09-opsdir-early-bonica-2023-04-10/
>
> All, please reply on-list indicating if you're aware of an implementation.
> If not already completed, please reply on-list indicating if you're aware
> of any relevant IPR.
>
> Brgds,
> Gunter & Ketan
> LSVR WG co-chairs
>