Skip to content

(TID) New feature: Multivendor Support for Openconfig Driver

Proposers

  • Oscar Gonzalez de Dios (Telefonica)
  • Pablo Armingol Robles (Telefonica)
  • Lluis Gifre (CTTC) [Reviewer]

Description

The proposed feature is an enhancement of the OpenConfig Device Driver to support multi-vendor configuration, adjusting to the particularities of each device vendor.

The motivation is that each vendor (and even each O.S. version of a vendor) support a different version of the required OpenConfig YANG model, in some cases, the YANG model is similar to the one use by other vendors, but deviations apply (ideally documented in a deviations file, worst case, detected in tests) and, sometimes, proprietary rules needs to be used (e.g. mandatory presence of some parameter, or a particular naming or a fixed value in one field).

It is proposed to be able to identify a new device by both vendor and Operating System (O.S.) version. Then, TFS can apply (and read) the proper configuration.

In this version of the feature, the proposal is to cover the following situations:

  1. The OpenConfig YANG model supported by the device is non-backwards compatible with the OpenConfig version used in TFS. Hence, if XML payload with the current OpenConfig model used in TFS is sent to the device, the device produces an error.

  2. The vendor requires some mandatory fields in addition to those already defined in the standard.

  3. The vendor requires a specific naming convention in a given field different than the one defined by the standard.

  4. The vendor requires a specific vendor augmented filed over the OpenConfig YANG model to support the functionality.

  5. The vendor requires a specific value for some field. E.g. in some vendors sub-interface must be set to 0.

The proposal is that (1) is covered by creating classes that implement different versions of the Yang model. For example, pyangbing (alternatives to be explored) is an alternative to create dynamically the XML payload.

Points 2-3 should be implemented by making the adjustments in the existing methods in the device driver. Note that THE INPUT TO THE DEVICE DRIVER MUST BE KEPT VENDOR AGNOSTIC.

The scope in the change will be focused on existing services (ACLs, L3 VPNs and L2 VPNs). New services are expected to follow this approach.

Demo or definition of done

TFS can configure OpenConfig-based ACLs (openconfig-acl) and Openconfig-based L3/L2 VPNs (using openconfig-interfaces, openconfig-network-instance and openconfig-routing-policies) in at least 2 vendors. In new issues we can increase the coverage for more vendors.

References

None

Feature Design (for New-Features)

In order to be able to identify a new device by both vendor and Operating System (O.S.) version, a new field, "Version" is added to the information stored about the equipment in TFS.

The device driver will receive the configuration rules defined in TFS which MUST ALWAYS BE AGNOSTIC of the specific VENDOR and OpenConfig YANG version). Based on the rules received, instead of filling the templates to generate the XML payloads to send to the device, python classes are created in which the vendor /version are indicated. These classes hide the complexity of dealing with multiple versions of the yang model. The wrapper class is initiated with the necessary field. For example, there will be one class for ACLs.

Change template generation to dynamic templates with pyangbind.

Change configuration generation to adapt to the new model.

Make the necessary adjustments in on existing services (ACLs, L3 VPNs and L2 VPNs).

Clarifications to Expected Behavior Changes

None, all logic affects to the OpenConfig/NetConf Device Driver only.

References

None

Assumptions

The exact versions of the OpenConfig YANG model are known in advance. TFS has saved the corresponding yang model for the version of each device to be configured. TFS will not dynamically update the support of new versions. That is, TFS will support specific versions and the support will be updated per TFS release.

Impacted Components

Device

Device Component Impact

A new field (version) from each added OpenConfig device must be processed. Change template generation to create dynamic templates with pyangbind adapted to the specific Openconfig YANG model version and specific vendor requirements when needed.

Testing

  • Onboard multiple devices from different vendors
  • Configure all of them to use same OpenConfig driver
  • The OpenConfig driver should configure them properly even if the data model is not exactly the same or even using vendor-specific CLI/SSH commands for unsupported OpenConfig features.
Edited by Lluis Gifre Renom