Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13

[Ketan Talaulikar <[e-mail]>]

Hi Gyan,

Please check inline below for response.


On Sat, Nov 19, 2022 at 10:23 PM Gyan Mishra <[e-mail]> wrote:

> Hi Ketan
>
> You are very welcome!
>
> One final suggestion related to the use of RR versus the variety of ways
> you can setup the BGP-LS AFI/SAFI peering to collect the link state from
> the BGP-LS producer PEs, and BGP-LS can be very memory and CPU intensive
> with messaging on the RR.
>

KT> I do not agree that BGP-LS functionality is CPU intensive on the RR (as
opposed to other AFI/SAFI). I do agree that depending on the scale, the
memory requirements may be higher given the amount of information carried
in BGP-LS.


> My thoughts are maybe a sentence on an possible optimization  is to
> decouple the BGP-LS producer function off the RR and put it on a dedicated
> stub RS separate AS eBGP multihop loop to loop peering to two producers per
> core AS.  This way there heavy processing overhead does not impact the
> production RRs.
>

KT> We already have text in Sec 8.1.1 recommending that BGP-LS use separate
RRs.


>
> In Figure 1 it shows BGP-LS producer with peering directly to BGP-LS
> consumer application.  Is that in cases where an RR is not utilized?
>

KT> Yes.


> If so maybe some wording to explain that direct peering to BGP-LS consumer.
>

KT> I don't know what to explain here beyond what is already in  Sec 3
given that the interface to the BGP-LS consumer is out of scope.

Thanks,
Ketan


> Many Thanks
>
> Gyan
>
>
>