Updates to network instance models for VLAN-VNI and VRF-VNI mappings

[abamberger-arista]

Change Scope

This is part 2 of splitting the original PR #1108 into 3 separate PRs. This one targets the changes to add the ability to configure local VLAN-to-VNI and VRF-to-VNI mappings.

The existing endpoint-vnis subtree for VXLAN endpoints is read-only, and seems intended for reporting state “learned on the local VXLAN Tunnel End Point from remote VTEPs in the default network instance” (see https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-network-instance.html).

To support the configuration of local VLAN-to-VNI and VRF-to-VNI mappings on a VTEP, this change proposes the addition of a “local-endpoint-vnis” subtree, which will be congruent with the existing “endpoint-vnis” subtree, but be read/write, and allow the configuration of local VLAN-to-VNI and VRF-to-VNI mappings.

It will specifically contain support for configuring the VNI, VNI type (L2 or L3), and either the bridge-domain (for L2 VNIs) or l3-vrf-name (for L3 VNIs).

Because this is a new subtree being added, this change is fully backwards compatible.

New tree state after proposed change (additions in bold):

module: openconfig-network-instance
+--rw network-instances
   +--rw network-instance* [name]
      +--rw connection-points
         +--rw connection-point* [connection-point-id]
            +--rw endpoints
               +--rw endpoint* [endpoint-id]
                  +--rw vxlan
                     +--rw local-endpoint-vnis
                        +--rw local-endpoint-vni* [vni]
                           +--rw vni       -> ../config/vni
                              +--rw config
                              |  +--rw vni?             oc-evpn-types:evi-id
                              |  +--rw vni-type?        enumeration
                              |  +--rw bridge-domain?   uint32
                              |  +--rw l3-vrf-name?     string
                              +--ro state
                                 +--ro vni?             oc-evpn-types:evi-id
                                 +--ro vni-type?        enumeration
                                 +--ro bridge-domain?   uint32
                                 +--ro l3-vrf-name?     string

New Yang Paths:

• network-instances/network-instance/connection-points/connection-point/endpoints/endpoint/vxlan/local-endpoint-vnis/…

Platform Implementations

Arista EOS

VLAN-to-VNI and VRF-to-VNI mapping:
https://www.arista.com/en/um-eos/eos-vxlan-configuration#xx1152323

interface Vxlan1
   vxlan udp-port 4789
   vxlan vlan 200 vni 658120
   vxlan vlan 100 vni 100
   vxlan vrf test vni 12345

[wenovus]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 508b156

[wenovus]

/gcbrun

[dplore]

@mikewiebe, @LimeHat, @earies can you give a review as well?

[abamberger-arista]

Just as an overall comment, since it's relevant to a few of the more specific comments here, this PR doesn't add any new terminal leaves, it's mostly just factoring out some parts of the existing endpoint-vnis container so they can be re-used in a new local-endpoint-vnis container. The contents that have been factored out (vni, vni-type, bridge-domain, and l3-vrf-name) are existing leaves already in the public model in the endpoint-vnis container.

[dplore]

LGTM, but please fix the revision statement as appropriate. I will move this to last call, to be merged on Aug 28, 2024)

[dplore]

/gcbrun

[dplore]

LGTM. Waiting for Aug 28, 2024 last call before merging.

[abamberger-arista]

I went ahead and fixed the merge conflict with the just-merged previous PR

[dplore]

/gcbrun

[mikewiebe]

@dplore Looks like I missed the notification on this one. I see the change is backwards compatible since it's adding a new tree so overall I think the change is ok.