...
The current implementation of the reference relations between system adapters and physical IO is confusing. EVE code does not have a uniform way of looking up for referenced objects. It is sometimes the Name field that is used to lookup lower layer adapters and some other times it is the lowerLayerName field that gets used to lookup lower layer adapters. We should streamline the way we maintain references between different layers of adapters. Controllers should always have the upper layers reference lower layers making the lowerLayerName field of upper layers reference to the logicalLabel field of lower layers.
When we specify a Network Instance we have a port field (which can be a group like “uplink” which means a management port, or a specific interface). That reference can now be to a logical label of a PhysicalIO or to the name/label of a L2 object (vlans/bonds).
...
The picture below shows the new vlan and bond constructs that will be implemented in EVE OS. Without vlans or bond interfaces, physical IO interfaces are directly enslaved to shadow bridge interfaces (bridge created with name of physical IO and the name of physical IO itself changed to avoid conflicts). In a similar fashion with vlans/bonds it will be the vlan/bond adapter that gets enslaved to the shadow bridge. With vlans and bonds, the shadow bridge gets the name of the vlan/bond adapter and the name of the vlan/bond adapter itself gets mangled to avoid conflicts.
Device model changes
Current device model has an ioMemberList that describes the various physical IO interfaces present on the device. Two additional lists - vlanAdapters list, bondGroups list will be included in the device model to describe the vlan adapters and bond groups respectively. Though there are different types of IO adapters like USB, ethernet audio etc, the sample device model below only shows IO adapters of type ethernet for brevity.
...
The pictures below show examples for vlan adapter and bond group lists that will be part of EdgeDevConfig.
Each vlan adapter object contains a user given name (from device model file), its vlan id, and the parent physical adapter of this vlan adapter. Vlan adapters can have both physical adapter and bond interface types as parent adapter. It might make sense for EVE code to collapse the vlan related fields into the existing NetworkPortConfig (add the new vlan id field) object that is part of the DevicePortConfig object. Bond interfaces may need to be sent as a separate list inside DevicePortConfig. Also NetworkPortConfig will have a new indicator field that indicates if the current network port is a vlan interface or bond interface or a regular interface.
Domain manager service in EVE should skip PhysicalIO adapters that are used for system adapters of type vlan and bond. Physical IO adapters that are made part of vlans and bond interfaces from device model files can never be changed to app-direct interfaces.
NIM service should take care of not creating the kethx interfaces for physical IO adapters that are underlying adapters for other Vland or bond adapters. NIM should also have the additional logic of creating any non-existing vlan interfaces or bond interfaces in linux kernel when the edge node decides to change its DevicePortConfig. There should also be additional logic to remove any pre-created vlan/bond interfaces that are no longer part of the new DevicePortConfig that is being applied. Even though the vlan and bond interfaces being part of the device model cannot be added/deleted from user agents (UI/zcli), the edge node may in the event of prolonged network disconnection try to replace the running network configuration with last resort configuration. During such an event, NIM service should take care of creating new vlans/bonds that are required and remove any stale vlans/bonds that are not required according to the DevicePortConfig file being applied.
Example EdgeDevConfig that cloud controller backend would send to Edge node
...