Dhananjay & Prasad,
This is wonderful, really, thanks a lot for this review. We will process this (not sure how long since it is a very detailed review), and get back to you. Thanks a lot, Camilo C From: "Narasimha Prasad S N (snprasad)" <snpra...@cisco.com> Date: Tuesday, 12 November 2024 at 12:52 To: Camilo Cardona <cam...@gin.ntt.net>, "draft-ietf-grow-bmp-y...@ietf.org" <draft-ietf-grow-bmp-y...@ietf.org>, Paolo Lucente <pa...@ntt.net>, "thomas.g...@swisscom.com" <thomas.g...@swisscom.com> Cc: "Dhananjay Patki (dhpatki)" <dhpa...@cisco.com>, "grow@ietf.org" <grow@ietf.org> Subject: RE: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-yang/ - Feedback from Cisco Hi Camilo, Paolo, Thomas, Benoit, Thank you for accommodating us. Following is our feedback, we would be happy to discuss this more in a meeting. Have split them up into multiple categories, hopefully that makes reviewing the feedback a bit easy. Feedback: It is a well written draft, covering a breadth of well thought of configuration options. Category#1: BMP Configurations currently supported by Cisco, but not part of the Draft We could review this and see which ones makes sense to be added to the draft. IP Connectivity Per BMP server (monitoring station) configs (under ‘bmp server <>’ config mode) description: BMP server specific description update-source : Name of the interface used to connect to the monitoring station dscp: To set in the IP packets sent to the monitoring station precedence: To set in the IP packets sent to the monitoring station flapping-delay: To delay connecting to the monitoring station after a flap was detected BMP Data Network-instance: Cisco supports, multi-instance BGP. So, we have BGP instances and VRFs under each BGP instances. So, there is a two-level network-instance hierarchy. Each BGP instance runs in a separate BGP process. To map this two-level network-instance hierarchy, in addition to ‘network-instance-id' we perhaps need ‘process-instance-id'. So, something like below <network-instance> <process-instance-id>instance-two</process-instance-id> <network-instance-id>red</network-instance-id> The default for process-instance-id would be ‘default’ which is the default BGP instance and for a config that applies to all BGP instances, the process-instance-id would be something like ‘bmp-pi-types-all-pi’. Add support for enabling monitoring stations on a per BGP peer basis Limit BMP station queue size (protects router from running out of memory by endless queueing, when BMP station is slow in consuming) max-buffer-size: Maximum buffer limit upto which BMP messages will be queued to TCP sockets. This could probably go under a new section related to performance tuning of the monitored router. Per mode (aka RIB-type) configuration pertinent to update generation and garbage collection advertisement-interval scan-time Configuration for Route-Mirroring initial-refresh and spread: This is used in case of route-mirroring for delaying and spacing Route-Refresh messages towards BGP peers to regenerate BGP updates. Session stats Cisco also supports detailed per-peer statistics (per BMP server, per RIB-type/mode) in addition to global sessions stats Category#2: Filtering Options added Adding the variety of filtering on a per-peer, peer-group, peer-type, AFI/SAFI, mode etc, does give a lot of flexibility and control on the router, but this comes at a cost of adding more processing load to the Router during the update generation for BMP updates & is something to think about. Secondly, getting this implemented across all vendors on the router will take a lot of time from a deployment angle. Given this, wonder if we should instead push the heavy weight filtering to the BMP Station – keep the router filtering to a few simple options. The con of doing this is we end up sending more data from router to station – this is something we should discuss and strike a balance between the two may be. The current filtering is added under the BMP sub-modes / node, another option to compare against is adding some of these options to BGP config with sub-mode as BMP, please see if this makes sense. We could discuss a combination of both of these approaches as well. Both have their pros/cons & broader vendor configs needs to be considered. For example - router bgp 1 <snip> neighbor 1.1.1.1 address-family ipv4 unicast bmp route-monitoring adj-rib-in bmp server 1 // server 1 only route-policy bmp-filter bmp server all // all bmp servers route-policy bmp-filter2 Category#3: General Comments 1. The description .. This document specifies a YANG module for configuring and monitoring the BGP Monitoring Protocol (BMP) [RFC7854] .. should be This document specifies a YANG module for configuring and monitoring the BGP Monitoring Protocol (BMP) [RFC7854] on the monitored router 2. Since BMP uses the terminology ‘monitoring station’ and ‘monitored router’, ‘monitored-router-address' and ‘monitored-router-port' (or simply ‘router-address’ and ‘router-port’) would probably be better names rather than ‘local-address’ and ‘local-port’. 3. Figure 9 should have <network-instance-id>bmp-ni-types-global-ni</network-instance-id> in place of <network-instance-id>bmp-ni-types-all-ni</network-instance-id> 4. Should ‘container peer-types’ be ‘container bgp-peer-types’ to make it more explicit? Same comment for the list underneath. Thanks. /snnp (Dhananjay & Prasad) From: Camilo Cardona <cam...@gin.ntt.net> To: Narasimha Prasad S N (snprasad) <snpra...@cisco.com>; draft-ietf-grow-bmp-y...@ietf.org; grow-cha...@ietf.org Cc: Dhananjay Patki (dhpatki) <dhpa...@cisco.com> Subject: Re: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-yang/ - Reviewing from Cisco Hello Prasad, Thanks! We will appreciate any feedback. Tell us if you have any question or need anything from us. Thanks a lot, Camilo C. From: Narasimha Prasad S N (snprasad) To: draft-ietf-grow-bmp-y...@ietf.org; grow-cha...@ietf.org Cc: "Dhananjay Patki (dhpatki)" <dhpa...@cisco.com> Subject: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-yang/ - Reviewing from Cisco Dear All, We are interested in reviewing this draft (https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-yang/) from Cisco perspective and will revert with feedback soon. Thanks /snnp (Prasad)
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
