Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need to support ISIS metric #1093

Closed
xandrorel opened this issue Apr 11, 2024 · 7 comments · May be fixed by #1206
Closed

need to support ISIS metric #1093

xandrorel opened this issue Apr 11, 2024 · 7 comments · May be fixed by #1206
Assignees
Labels

Comments

@xandrorel
Copy link

xandrorel commented Apr 11, 2024

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 dplore self-assigned this Apr 12, 2024
@dplore
Copy link
Member

dplore commented Apr 12, 2024

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
Copy link
Author

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
Copy link

LimeHat commented Apr 19, 2024

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
Copy link
Author

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
Copy link

LimeHat commented Apr 22, 2024

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
Copy link
Author

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)

Copy link

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.

@github-actions github-actions bot added the Stale label Oct 21, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants