Hello all, I second Thomas Graf, these are important metrics to monitor. However, I would approach it slightly differently: - Max configured number of prefixes for AFI/SAFI - Current used number of prefixes for AFI/SAFI. - Absolute max or Hardware max (if applicable) for AFI/SAFI.
And would avoid sending percentages, to avoid nasty floating points being sent in the wire protocol. Best, -Ahmed On 10.01.2024, 23:30, "GROW on behalf of Paolo Lucente" <grow-boun...@ietf.org <mailto:grow-boun...@ietf.org> on behalf of pa...@ntt.net <mailto:pa...@ntt.net>> wrote: Be aware: This is an external email. Hi Thomas, Thanks for your comment. I see your need for these reason codes and i will include them in the next revision of the draft -- the more event-driven use-cases for REL, the better. As i may have said before, I also like that counters make it to the Stats message as i regard Stats and REL highly complementary in that regard, one provides the summary, the other optionally provides the details. Paolo On 6/1/24 13:04, thomas.g...@swisscom.com <mailto:thomas.g...@swisscom.com> wrote: > 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 > > <https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-rel-03#section-3.3.1> > > <https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-rel-03#section-3.3.1> > > <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 > <https://datatracker.ietf.org/doc/html/rfc4271#section-6.7> > <https://datatracker.ietf.org/doc/html/rfc4271#section-6.7> > <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 > <https://datatracker.ietf.org/doc/html/rfc4486#section-3> > <https://datatracker.ietf.org/doc/html/rfc4486#section-3> > <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 > <https://datatracker.ietf.org/doc/html/rfc7854#section-4.9> > <https://datatracker.ietf.org/doc/html/rfc7854#section-4.9> > <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 > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1> > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.1> > <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 > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.2> > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.2> > <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 > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3> > <https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.3> > <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 > > <https://datatracker.ietf.org/doc/html/draft-netana-opsawg-nmrg-network-anomaly-semantics-01#symptom_control_plane_actions_table> > > <https://datatracker.ietf.org/doc/html/draft-netana-opsawg-nmrg-network-anomaly-semantics-01#symptom_control_plane_actions_table> > > <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 > > <https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf> > > <https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf> > > <https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf>> > > Best wishes > > Thomas > > > _______________________________________________ > GROW mailing list > GROW@ietf.org <mailto:GROW@ietf.org> > https://www.ietf.org/mailman/listinfo/grow > <https://www.ietf.org/mailman/listinfo/grow> _______________________________________________ GROW mailing list GROW@ietf.org <mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow> _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
