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

[Ahmed.Elhassany]

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" mailto:grow-boun...@ietf.org> on behalf of 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  
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
>  
> 
>  
> 
>  
> ).
>  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 
> 
> 

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

[Paolo Lucente]

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 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 ). 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


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[Thomas.Graf]

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
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow