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
1. 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.
1. 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<mailto:draft-ietf-grow-bmp-y...@ietf.org>;
grow-cha...@ietf.org<mailto:grow-cha...@ietf.org>
Cc: "Dhananjay Patki (dhpatki)" <dhpa...@cisco.com<mailto: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
