Hi, thanks for the issue. I interpret the proposed path /network-instances/network-instance/protocols/protocol/isis/levels/level/config/metric to configure the metric for all links in a given level in every AFI/SAFI, but the examples shared configure metric at the interface level.

Can you find 2 or more examples of configuring metric at the ISIS level?

I imagine there will be some discussion if we need this additional way to configure isis metrics?

For convenience of reviewers, here are the current OC paths for

config isis metrics:

/network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/config/metric
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/config/metric

config isis metric style:

/network-instances/network-instance/protocols/protocol/isis/levels/level/config/metric-style

configuring isis multi-topology

/network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/multi-topology/config/afi-name
/network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/multi-topology/config/safi-name

My bad, I intended to propose this path instead:
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/config/metric

So it is per interface, but not dependent on the address-family.

Let me also change the original post. Sorry for the confusion.

Such metric will be used as a metric in ISIS single-topology mode, and can be overridden by the specific metric defined under AF.

No, that can't be done (the latter part).

The root cause of the issue/behavior you describe is the requirement that metrics in single-topology deployments must be identical.

Hence, implementers have a choice: enforce that both IPv4 and IPv6 metrics are always set to the same value in config (and reject other configurations), or ignore (and don't require) one value and always rely on the other to set both.

Most implementations on the market follow the latter approach and use the ipv4 metric (aka metric in your examples) for single topology deployments.

In my view, simply adding a new metric leaf is not an optimal solution, and there are no implementations that support three configuration levels in the way you describe it.

Most implementations on the market follow the latter approach and use the ipv4 metric (aka metric in your examples) > > for single topology deployments.

Correct, and the use of the ipv4 metric as a single-topology interface metric is exactly the problem this proposal attempts to solve.

Let's assume we have an ipv6-only device, i.e. none of the interfaces have ipv4 AF configured. Yet, an ISIS metric has to be configured under ipv4 AF on an interface in order to configure ISIS metric in a single-topology mode .
In other words, in the ipv6-only scenario, everything besides the ISIS metric is configured under the respective AF, but the metric is configured under ipv4 AF. This behavior is counter-intuitive and far from ideal.

One way to solve it is to use this additional leaf for single-topology metric.
Another potential solution is for the vendors to parse the config and in the absence of ipv4 metric and presence of ipv6 metric and enabled single-topology use the ipv6 metric as the single topology metric.

One way to solve it is to use this additional leaf for single-topology metric.

If you want to pursue this approach, I'd suggest opening a PR that adds/updates/deprecates leafs as necessary to get a full picture of what leafs can be used in the single-topology mode, what leafs are used in multi-topology deployments, etc.

it appears that the proposal in its current form de facto deprecates the ipv4/unicast afi/safi metric config (if the intent is to match the current implementations).

If you want to pursue this approach, I'd suggest opening a PR that adds/updates/deprecates leafs as necessary to get a >full picture of what leafs can be used in the single-topology mode, what leafs are used in multi-topology deployments, >etc.
Sure, will do.

I don't think the proposal causes the ipv4/unicast afi/safi metric to be deprecated. I believe we can follow the current implementation quite closely with the following logic:

if in single-topology and metric configured in
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/config/metric
use this as a single topology metric

if in single-topology and metric configured in v4 AF
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/config/metric
use this as a single topology metric

if in single-topology and metric configured in both
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/config/metric
and v4 AF
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/config/metric
use one of them as a single topology metric and ignore the other
(ideally the latter one should be used, but not the big deal if not)

if in single-topology and metric configured in v6 AF
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/config/metric
ignore this metric
(just like is done today)

if in multi-topology and metric configured in
/network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/config/metric
ignore this metric
(In an ideal world this can be used to set both v4 and v6 metrics on the interface, unless set via specific AF metric, but ignoring this is fine too)

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.