Re: [GROW] GROW, draft-lucente-grow-bmp-rel - BMP warning and upper bound event reason codes

[[e-mail]]

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" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> 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, [e-mail] <mailto:[e-mail]> 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&gt;>). 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&gt;>) 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&gt;>) 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&gt;>).
>
> 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&gt;>)
> * 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&gt;>)
> * 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&gt;>)
>
> 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&gt;>) 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&gt;>
>
> Best wishes
>
> Thomas
>
>
> _______________________________________________
> GROW mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>


_______________________________________________
GROW mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>