Add uRPF drop counter in the lookup subsystem.

[sugrimov]

• (M) release/models/platform/openconfig-platform-pipeline-counters.yang

Change Scope

This change adds uRPF drop counters to the lookup subsystem. The counter represents dropped packets failing uRPF check on the forwarding path. This counter locations is specific for vendor platforms, which report uRPF drops on per-chip basis. The change is backwards compatible.

Platform Implementations

Cisco (IOS-XR)

Cisco IOS-XR on ASR9K and NCS platforms reports per-chip uPPF drops as bcmRxTrapUcLooseRpfFai.

CLI: show controller npu stats traps-all instance 0 location <chip> | in Rpf

Vendor telemetry path: Cisco-IOS-XR-fretta-bcm-dpa-npu-stats-oper:dpa/stats/nodes/node/npu-numbers/npu-number/display/trap-ids/trap-id/packet-dropped

Arista

Reports per-chip uRPF drops as dropVoqInRpf counter.

CLI: show hardware counter drop.

Vendor telemetry path: /Smash/hardware/counter/internalDrop/SandCounters/internalDrop

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[OpenConfigBot]

Compatibility Report for commit 63c4ae0df0b174222fc6909bfb7b08ee8db5afac: ⛔ yanglint@SO 1.10.17

[dplore]

To be compatible with #715 could you place this at a level like: /components/component/integrated-circuit/pipeline-counters/drop/urpf-total-drops

Since uRPF drop is not a hardware specific component perhaps it is not necessary to have vendor specific leafs like are proposed in #715. Can we have some comments from the community?

[sulrich]

Since uRPF drop is not a hardware specific component perhaps it is not necessary to have vendor specific leafs like are proposed in #715. Can we have some comments from the community?

there's certainly a notable intersecting set of drop counters across implementations.

the utility in having vendor/implementation-specific counters accessible is to avoid obfuscating valuable diagnostic data by exposing the data that the vendor's support organization may best utilize without having to disambiguate separately.

#715 allows implementors to, at their option, expose a wider range of counters which operators may choose to collect while allowing aggregation of counters as a high-level signal for operators to take action on.

@rolandphung

[robshakir]

I think where there are common counters that can be modelled in a common manner, it is best to do this. Especially where this is actionable telemetry - i.e., would allow us to be able to trigger some repair or diagnostic workflow at this point. (I'm not sure if the latter is true in this case, but this does appear common.)

The utility, to me, of the implementation-specific cases is to cover those scenarios that would obfuscate for the underlying implementor to do diagnostics. This likely means that there is some potential denormalisation between the implementation-specific and the implementation-neutral counters here.