Dear Paolo and Camilo, I have a comment on Section 3.3.1 of draft draft-lucente-grow-bmp-rel (https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-rel-03#section-3.3.1). Please consider to add two additional event reason codes as described below.
As described in my previous post to the draft-msri-grow-bmp-bgp-rib-stats authors. A BGP speaker may have an prefix count upper bound as described in Section 6.7 of RFC 4271 (https://datatracker.ietf.org/doc/html/rfc4271#section-6.7) configured. When this upper bound is being reached, the BGP peer will be temporarely be teared down and a BGP NOTIFICATION message with reason subcode as described in Section 3 of RFC 4486 (https://datatracker.ietf.org/doc/html/rfc4486#section-3) is being encapsulated in the BMP peer_down message with reason code 1 as described in Section 4.9 of RFC 7854 (https://datatracker.ietf.org/doc/html/rfc7854#section-4.9). However that the network operator is being notified when the upper bound is being reached is not sufficient, the network operator also wants to monitor the capacity, how many prefixes left until the upper bound is being reached. I suggest therefore to add an additional BMP stats counter in draft-msri-grow-bmp-bgp-rib-stats describing - how many prefixes until upper bound is being reached - how much percentage of the defined bound is currently being used The network operator usually has the possibility to chose between taking the peer down when the upper bound is being reached, or filter the paths above the configured upper bound. I suggest therefore to add two event reason codes in draft-lucente-grow-bmp-rel describing - Crossed warning bound, path not being dropped - Crossed upper bound, path being dropped These two reasons codes enables the network operator to perform root cause analysis. Its not only enough to monitor proactively the capacity of the peer and being notified with the right reason code and upper bound value in the BGP notification message when peer is being proactively being taken down. The network operator also wants to understand who caused the crossing of the warning and upper bound. The who translates to paths being exported by BMP route-monitoring sharing the following BGP attributes: * BGP origin (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1) * BGP AS Path (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.2) * BGP next-hop (https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3) I hope that makes sense. Feedback and comments welcome. I will also augment the control plane a list of common symptoms in Semantic Metadata Annotation for Network Anomaly Detection (https://datatracker.ietf.org/doc/html/draft-netana-opsawg-nmrg-network-anomaly-semantics-01#symptom_control_plane_actions_table) where we start defining an informational module for network symptoms for network anomaly detection describing network action, reason, cause. Was presented at NMRG and IEPG at IETF 118. https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf Best wishes Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
