Discussing Adding switches between originasn/asn for AS hegemony alarms and start/endpoint for network delay alarms

[mohamedawnallah]

@romain-fontugne This feature actually makes sense for detecting anomalies, but we have a concern regarding the Startpoint and Endpoint values, namely IP, PB, and CT in Network Delay Alarms API. We have the following potential options:

1. Option 1: Ignore all IP, PB, and CT start point and endpoint types for Network Delay Alarms. This would result in an AS -> AS relationship type. The advantage here is that we don't need to deal with the complexity of IP, PB, and CT and we applied the switches on both Data Vizs and Table, but the downside is that we might miss valuable alarms, especially on the level of CT.

2. Option 2: Limit the switches to only the Alarms Table and filter only alarms where the start point equals AS and the endpoint types are still the same could be AS, IP, PB, and CT in the Data Vizs. The benefit is that we won't miss any information, but the drawback is that we don't apply the switches on the Alarms Data Vizs i.e.: World Map, Tree Map, and Time Series.

3. Option 3: Ignore IP and PB and include only CT because it contains the country information. This might seem like a good compromise, but we'll face a problem when users are interested in AS granularity.

Please let me know your thoughts.

[romain-fontugne]

Thanks for detailing the different options. I think we can go with option 1. Currently the IP and PB alarms are not very insightful and, although we try to be as inclusive as possible, the AS granularity is a good compromise for the global report.

[mohamedawnallah]

Thanks! I think so as well