Hi Gyan,
Please check inline below for response.
On Sat, Nov 19, 2022 at 10:23 PM Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:
Hi KetanYou 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 ThanksGyan
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
