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

[Paolo Lucente <[e-mail]>]

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] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow