Remove before change for list having multiple keys

YANG
1

Hi,

I need to implement following CLI in yang

inside host 2.2.2.3 to 3.3.3.3
inside host 2.2.2.2 to 3.3.3.2
inside host 2.2.2.1 to 3.3.3.1

I implemented this as a list with both the IP’s as keys (both are unique - one to one). Now if someone enters a rule like 2.2.2.1 to 4.4.4.1, we need to replace the 3rd rule with this since 2.2.2.1 is part of 3rd rule.

Is we give, 4.4.4.1 to 3.3.3.1, again 3rd rule needs to be replaced with this since 3.3.3.1 is part of 3rd rule.

Is it possible to achieve this behavior? How can this be done.

container inside {
     tailf:cli-incomplete-no;
        list host {
          tailf:cli-suppress-mode;
          tailf:cli-suppress-list-no;
          tailf:cli-delete-when-empty;
          key "from_ip to_ip";
          leaf from_ip {
            tailf:cli-incomplete-command;
            type inet:ipv4-address;
          }
          leaf to_ip {
            tailf:cli-expose-key-name;
            tailf:alt-name "to";
            type inet:ipv4-address;
          }
        }

Please help

2

This is possible only partially. The following data model (modulo tailf:cli-... annotations) describes your intent, I believe:

container inside {
  list host {
    key "from_ip";
    unique to_ip;
    leaf from_ip {
      type inet:ipv4-address;
    }
    leaf to_ip {
      type inet:ipv4-address;
    }
  }
}

Note that you need to have only one of the leaves as the key, otherwise it says that their combination should be unique, not each of them individually, let’s use from_ip as the unique key. The fact that to_ip should be also unique is said by the unique statement.

The behavior is now that, in your example, if the operator enters 4.4.4.1 to 3.3.3.1, ConfD would complain that 3.3.3.1 is not unique. The operator would first have to remove the other entry and only then add the new entry. (Note that this applies only to the I-style CLI, otherwise the order of remove/add operations is not relevant, the uniqueness is checked only after validate or the final commit commands; but still, there is no “automatic removal” of old entries.)

I am afraid this is it, you cannot get any further via data model means. To get the exact behavior you would have to resort to custom CLI commands.

(Btw., not sure if you have noticed: in your example, if the operator enters 2.2.2.1 to 3.3.3.3, this would mean that two entries have to be removed, the first and the third ones - or perhaps more appropriate description would be, given the data model suggested above: removal of the first entry and modification of the third entry. I believe this indicates that the behavior you require is unusual, to say the least.)