DAN-49 - Route map add match by local-preference

[bbs2web]

Signed-off-by: bbs2web bbs2web@hotmail.com

[nickbroon]

Thank you for your contribution!

We are still finalizing all the logistics around accepting contributions. The process will be documented here.

[deastoe]

Thanks once again for your contribution to DANOS @bbs2web!

Unfortunately we can't add these nodes unconditionally to the vyatta-policy-route-v1 module as it is also used in DANOS derivatives which do not use FRR, and therefore may not support these options.

There are a couple of ways we can re-work your changes to avoid this issue:

• Define YANG features and mark these nodes as conditional on those features being enabled; the feature can be disabled on DANOS derivatives as needed.
• Define a new YANG module in DANOS/vyatta-protocols-frr which augments these nodes into the policy tree; this module can then be included only in DANOS builds using FRR.

I'm favourable to the approach of using YANG features as this will allow DANOS derivatives to enable the functionality down the line as they are able to, without duplicate YANG modelling.

Whatever the chosen approach we can guide you along making the necessary changes to your PRs.

@jsouthworth, @JammyStuff, do you have any preference here? Or alternative solutions (YANG deviations perhaps)?

cc @dewi-morgan

[JammyStuff]

@deastoe I think you're right, YANG features seems like the way to go to me. We just need to make sure that the feature is specified in a separate package list that can be left disabled in derivatives.

[deastoe]

To move this PR towards a state where it can be merged we'll need to make these nodes conditional. Below are the steps for using YANG features to do this:

1. Define a YANG feature for each of the leaves
2. Mark each leaf as conditional on the corresponding feature
3. Create a Debian package for each feature which, when installed, enables the feature
4. List these packages in a package list for the base DANOS image so they are enabled automatically

1. YANG features are defined within a module and you can find an example here.

I would suggest two features eg. route-map-set-source and route-map-match-local-pref. These can be defined below the revision statements in vyatta-policy-route-v1.yang and given a suitable description.

2. To make a node conditional on a feature we add an if-feature statement.

So this would be done on each leaf with the corresponding feature, eg:

leaf local-preference {
    if-feature route-map-match-local-pref;
    ...
}

3. Features are enabled by the existence of a particular path on the DANOS system. In vyatta-protocols-common we can follow an existing pattern for doing this, so first we create two empty files at the following paths:

• ./features/vyatta-policy-route-v1/route-map-set-source
• ./features/vyatta-policy-route-v1/route-map-match-local-pref

These represent features defined by the vyatta-policy-route-v1 module.

Next we need to define the package for both features. I'll give the package definition for route-map-set-source as a reference.

Packages are defined in debian/control and we can use this one as an example.

Clearly we need to update the package name, its dependency, and description; something like this would work:

Package: vyatta-route-map-set-source-feature
Architecture: all
Depends: vyatta-policy-route-v1-yang, ${misc:Depends}
Priority: optional
Description: Vyatta feature for route map "set source"
 The feature flag for route map "set source" support.

Now we need to declare what will be contained in our new package. In this case we can do so with a simple .install file.

So we create a .install for our package, debian/control/vyatta-route-map-set-source-feature.install with contents:

features/vyatta-policy-route-v1/route-map-set-source opt/vyatta/etc/features/vyatta-policy-route-v1

When the vyatta-route-map-set-source-feature package is installed /opt/vyatta/etc/features/vyatta-policy-route-v1/route-map-set-sourcepath is created, and the feature is enabled.

4. The package lists define the content of the DANOS binary image and are maintained in the danos/build-iso repository to which PRs can be submitted.

For this final step all that's required is to list our two new feature Debian packages in the correct package list. In this case the correct package list is vyatta-protocols-frr.

[deastoe]

Please also add a description statement, you can re-use the text eg.

description "Preferred source address";

[deastoe]

Please also add a description statement.

[deastoe]

I think source would be better as it is not much longer and is consistent with other nodes in this module (eg. access lists).

[deastoe]

There is an existing type definition for this in vyatta-types-v1-yang. The advantage of the existing type is that it also ensures values are normalized into a canonical form.

vyatta-types-v1 is already imported, so you can use the type like so:

type types:ip-address;

[deastoe]

Please let me know if you have concerns or queries about the requested changes.

[deastoe]

A further point on YANG module changes, for info. We require a new or updated revision statement for pretty much any change made to a module (including those made in this PR). At a minimum a new revision statement must be added to any module changed between DANOS releases as this ensures proper interaction with NMSs (Network Management System).

In this case, as we have not yet reached a final process for accepting community contributions, we can take care of adding the necessary revision statements. These requirements will be documented in due course, as this process is defined.