Hello Prasad, Dhananjay,
We are preparing the next version of the draft, including a lot of your feedback. A couple of concrete questions: What would be the use case of the flapping delay? What condition are we trying to avoid? The BMP limit queue would be for all BMP type messages? FRR for instance has a queue https://docs.frrouting.org/en/latest/bmp.html#clicmd-bmp-mirror-buffer-limit-0-4294967294 but only for mirroring, so we wonder if these queues could be per message type instead of a general queue? Could you share configuration of route mirroring? Thanks! Camilo C From: Camilo Cardona <cam...@gin.ntt.net> Date: Friday, 29 November 2024 at 11:37 To: "Narasimha Prasad S N (snprasad)" <snpra...@cisco.com>, "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 Prasad, Dhananjay, Thanks a lot again for the review and the time you could share with us in a call describing these points. Some comments inline of the next steps (After CC:). Thanks, 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 CC: ACK update-source : Name of the interface used to connect to the monitoring station CC: ACK. This might require some time to think how to do it well, but we’ll take the time to analyse it. dscp: To set in the IP packets sent to the monitoring station CC: Ack precedence: To set in the IP packets sent to the monitoring station CC: Ack flapping-delay: To delay connecting to the monitoring station after a flap was detected CC: Ack. We’ll need to differentiate from the other flappings arguments we have there which are just for the initial connection. We will also enhance the init-delay description with the feedback you provided. Thanks. 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’. CC: This is an excellent point. Since the establishment of different BGP processes seems to be vendor dependent, we might not be able to add it here so clearly (the ietf view on processes is to configure them using their own tree I think, but I will have to recheck). However, since there are not thousand BGP processes, but just a few, we might recommed to tackle this by agumenting the BMP monitoring description. We’ll work on it. Add support for enabling monitoring stations on a per BGP peer basis CC: We do support it, we’ll add an example for further clarification. 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. CC: Is this something that is on the BMP level independent from TCP? Meaning, this would also apply to a hypothetical case in which BMP can go over Quic, right? Per mode (aka RIB-type) configuration pertinent to update generation and garbage collection advertisement-interval scan-time CC: Noted. This might be implementation dependent, We will ask Jeff about it to see the commonalities across vendors. (if Jeff is seeing this he might answer directly) 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. CC: We dont have route-mirroing yet, and we should add it, are these the only two tunable parameters you offer? Is there anything else? Session stats Cisco also supports detailed per-peer statistics (per BMP server, per RIB-type/mode) in addition to global sessions stats CC: Is this something that would fall under session-stats? If you have details, we can add them. 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. CC: Having a filter in the server can help us save bandwidth and process power in some cases. We understand that we should not force implementations to support it. We will make it optional (either through the if-feature or some other means). 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 CC: We see the point here. The only issue is that BMP will be heavily dependent in the BGP module, which is something we don’t want initially. 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 CC: Ack 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’. CC: Ack 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> CC: Ack, We will check this one in detail, thanks! 4. Should ‘container peer-types’ be ‘container bgp-peer-types’ to make it more explicit? Same comment for the list underneath. CC: Most probably, We will revisit names again, including the misplaced peer-id that we saw yesterday during the call. 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
