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, [email protected] 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>). 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>) 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>) 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>).
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>)
* 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>)
* 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>)
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>) 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>
Best wishes
Thomas
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
