[c-nsp] XR6 process conflicts

[tim at pelican.org]

On Monday, 14 September, 2020 19:38, "Radu-Adrian FEURDEAN" <cisco-nsp at radu-adrian.feurdean.net> said:

> On Sat, Sep 12, 2020, at 11:25, James Bensley wrote:
> 
>> In your specific case/example; if I have a PE with a single physical
>> interface connected to some 3rd party wholesale Ethernet NNI, with 500
>> sub-interfaces, each running OSPF to a remote CPE; if the physical
>> interface goes down I don't need 500 SNMP traps or syslog messages to
>> tell me that all 500 OSPF sessions are down. There are two sides to
> 
> OTOH, if the NNI service goes down (circuits are interrupted), but the interface
> stays up, you will be happy to know that ALL circuits are down (or at least which
> of them went down) when you open a ticket to the NNI provider.

And in an ideal world, of course, your monitoring platform will do intelligent root-cause analysis, suppress all the individual circuit alarms, generate a single master alarm for the NNI for the NOC to deal with, and notify all the impacted customers of the master ticket.

I'd usually want to err on the side of having more data and putting appropriate filtering between the data and the person viewing, rather than NOT having data it later turns out would be useful.

Regards,
Tim.