Add Table ID in CNI Result and Attribute

[LionelJouin]

Using Source Based Routing and VRF meta plugins, routes are configured in different tables that are not represented in the result.

In a chained CNI configuration, the first main cni will create the requested routes and currently, VRF and SBR plugins are moving some of those routes to newly created routing table(s). Adding the Table property in the Result would help with the clarity of what and how networks are being configured.

Routes could be configured in a specific table by the "main" CNI in the chain, and the SBR plugin could just create the policy route towards this table without moving any route. The current behavior could be also kept, the SBR and VRF plugin would have to modify the result to specify in which table routes have been moved.

Adding the option to pass the table number is described as future enhancement in the SBR plugin documentation: https://www.cni.dev/plugins/current/meta/sbr/#future-enhancements-and-known-limitations
Here is what would be the changes in the SBR plugin with the table ID without moving routes: LionelJouin/plugins@0987743

[tamilmani1989]

Why CNI has to return table ID and what container runtime will do with this?

[LionelJouin]

Sorry for the misleading title, the idea was to change the CNI route result AND attribute, as done in the PR #1041.

I don't see any usage for the container runtime to get this information. The table ID in the result could be utilized (or not) by the next CNI Plugin in the chain.

The changes, as set in the PR #1062, would be for the Route struct here: https://github.com/containernetworking/cni/blob/v1.2.0-rc0/pkg/types/types.go#L167
The user would then be able to describe to which table the routes must be added:

{
    "cniVersion": "1.0.0",
    "name": "macvlan-sbr",
    "plugins": [
        {
            "master": "eth0",
            "type": "macvlan",
            "ipam": {
                "addresses": [
                    {
                        "address": "169.255.100.100/24"
                    }
                ],
                "routes": [
                    {
                        "dst": "10.0.0.1/32",
                        "gw": "169.255.100.105",
                        "table": 5001
                    },
                    {
                        "dst": "20.0.0.1/32",
                        "gw": "169.255.100.160",
                        "table": 5001
                    }
                ],
                "type": "static"
            }
        },
        {
            "table": 5001,
            "type": "sbr"
        }
    ]
}

In the example above (that also includes the SBR changes LionelJouin/plugins@0987743), the routes will be added to a table 5001 by the first CNI in the chain (macvlan), the second CNI plugin (SBR) would just add a source based route (with 169.255.100.100/32 as source IP) toward this table (5001).

For comparison, with the current SBR behavior, table IDs are generated automatically, then routes reported in the result are being moved to the newly created table.