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

[Keyur Patel <[e-mail]>]

Thanks for the review and comments Ketan. We will address them in our next revision. :)

Best Regards,
Keyur

> On May 4, 2023, at 4:24 AM, Ketan Talaulikar <[e-mail]> wrote:
> 
> 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
> [EXTERNAL]