openconfig
Add enabled leaf into isis multi-topology config
Change Scope
This change adds a leaf node to enable isis multi-topology configuration. For some reason the enabled leaf node was not defined under config and some implementations use proprietary leaf nodes to enable isis multi-topology.
module: openconfig-network-instance
+--rw network-instances
+--rw network-instance* [name]
+--rw protocols
+--rw protocol* [identifier name]
+--rw isis
+--rw global
+--rw afi-safi
+--rw af* [afi-name safi-name]
+--rw multi-topology
+--rw config
| +--rw afi-name? identityref
| +--rw safi-name? identityref
| +--rw enabled? boolean <<< new
+--ro state
+--ro afi-name? identityref
+--ro safi-name? identityref
+--ro enabled? boolean
Platform Implementations
Juniper ISIS multi-topology reference
[edit protocols isis]
user@R1# set topologies ipv6-unicast
switch(config)# router isis 1
switch(config-router-isis)# address-family ipv6 unicast
switch(config-router-isis-af)# multi-topology
Cisco IOS XR config guide
In Cisco IOS XR isis multi-topology is enabled by default. It can be disabled by single-topology command.
router isis isp
net 49.0000.0000.0001.00
address-family ipv6 unicast
single-topology
No major YANG version changes in commit 2a3e9e5dd85dfcb4edf32385811996d2e7883f4f
Hi @xandrorel , We reviewed this in the Oct 29, 2024 OC operators meeting.
It seems the intent of the current OC model is configuring the ISIS afi/safi implies enabling single topology.
ie:
/network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/config/afi-name
If one configures the ISIS multitopology afi/safi, then multi-topology is implicitly enabled.
ie:
``/network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/multi-topology/config/afi-name`
This seems "roughly" aligned with the vendor CLI references provided. In each case, there is a configuration for the multitopology and the address family. If configured, it is in use.
Is there any operational use case to configure multi-topology and have it disabled? (as is the case for things like interfaces and bgp sessions).
@s19nal pointed out that the existing model might be more elegant if there was a boolean for multi-topology inside the container /network-instances/network-instance/protocols/protocol/isis/global/afi-safi/af/config. But I am not sure it's worth changing the model to add this since it doesn't create any new, needed functionality?
Adding the enabled leaf will not add any new functionality but it will make the YANG tree consistent with the state container.
The current tree already looks weird with afi-name and safi-name leaf under the multi-topology container, these are redundant as this container is already under the afi-safi container which has these two leafs. We may not want to remove these leafs now but we should add the enabled leaf under it.
Quote reply
Ugh, you are correct, there is redundancy in this (git blame shows it goes all the way back to the original model 8 years ago).
I also see the point that the state leaf for enabled already exists which is inconsistent with the config container.
The problem with introducing this enabled leaf is that it is probably in effect, a breaking change. If a existing config doesn't specify this leaf and a device OS update is performed to a new OC release which has this leaf, what will the behavior be? It is ambiguous.
If we leave things as is, it seems clear that if
+--rw multi-topology
+--rw config
| +--rw afi-name? identityref
| +--rw safi-name? identityref
are not present, then multi-topology is not enabled.
We can add a new leaf here to resolve this issue -- I think deprecating these afi-name and safi-name leaves sounds like the right thing to do.
If we add:
leaf mt-enabled {
type boolean;
description
"When set to true indicates that multi-topology is enabled for this <AFI, SAFI>.";
}
Then we can introduce this safely -- if an operator sets (afi-name && safi-name) || (mt-enabled) then we know that MT is enabled for the <AFI,SAFI>. OSes can accept both for some time, and remove the afi-name and safi-name. The state/enabled leaf can be deprecated at some point too -- in favour of state/mt-enabled.
WDYT?
