need to support ISIS metric

[xandrorel]

Currently, the ISIS metric can only be defined per Address Family using this OC path: /network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/config/metric However, for the IPv6 ISIS metric to be applied the multi-topology has to be enabled. This is true for Juniper, Arista and Cisco XR. Cisco XR enables ISIS multi-topology by default, while Juniper and Arista have single-topology by default. In the absence of IPv4 AF configured on the device/interface, the ISIS metric under IPv6 AF is ignored, unless multi-topology is enabled. Proposing to define an OC path for AF-independent metric for ISIS, defined for the level: [EDITED] /network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/config/metric

similar to how the metric-style OC path is defined today: /network-instances/network-instance/protocols/protocol/isis/levels/level/config/metric-style

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

From Juniper ISIS metric reference and Juniper ISIS multi-topology reference

isis {
    level 2 wide-metrics-only;
    interface ae2.0 {
        level 2 metric 100;
    }
}

From Arista ISIS config guide

switch(config)# interface ethernet 5
switch(config-if-Et5)# isis metric 30
switch(config-if-Et5)#

switch(config)# interface Ethernet 5
switch(config-if-Et5)# isis ipv6 metric 30
switch(config-if-Et5)#

IOS XR Configuring Single Topology for IS-IS

[dplore]

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

[xandrorel]

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.

[LimeHat]

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.

[xandrorel]

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.

[LimeHat]

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).

[xandrorel]

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)