[c-nsp] XR6 process conflicts

[James Bensley]

On 15 September 2020 10:17:09 CEST, "tim at pelican.org" <tim at pelican.org> wrote:
>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.

Yeah well that's the ideal dream scenario. The reality is that many operators (especially small operators who's entire OSS stack is a single Observium/LibreNMS/Cacti/Solarwinds/whatever server) can't handle this.

I wonder if Cisco have tried to do what they did with LPTS in IOS-XR and implement what they consider a "sensible" default, i.e., the control plane is not fully open and unlimited, and not 100% closed by default, but some rate limiting is implemented out of the box as a compromise.

I guess the OP's concern is that there doesn't appear to be a command (unless I missed it?) to change the threshold above which XR starts surprising traps?

Cheers,
James.