Re: [RFC] [nmstate] Linux routing in nmstate



Thank you Gris.
Comments in-line.

On Tue, Feb 26, 2019 at 8:56 AM Gris Ge <fge redhat com> wrote:
Hi Guys,

Could you review below schema for routing in nmstate before we start
add routing support in nmstate?

```
What is the root level key? `routing`?

    {
        "ipv4-routes": [    # Sorted with 'table-id' then 'destination'
 
ipv4 and ipv6 look identical to me here.
It makes sense then to have `route` as the subtree and a `family` entry inside.
            {
                "table-name": "main",   # Empty if no name attached
                "table-id": 254,
                "protocol": "dhcp",     # "static" or "dhcp"
                "metric": 100,
                "destination": "0.0.0.0/0",
                "next-hop-iface": "eth0",       # Mandatory

This is not mandatory on `iproute2`, it is usually resolved based on the address next hop.
I think it is mandatory for p2p links only.

                "next-hop-address": "192.0.2.1"
                # ^ Empty on point-to-point link
            },
        ],
        "ipv6-routes": [    # Sorted with 'table-id' then 'destination'
            {
                "table-name": "main",   # Empty if no name attached
                "table-id": 254,
                "protocol": "auto",     # "static" or "auto"[1]

I prefer a more meaningful name, `auto` is problematic.

                "metric": 100,
                "destination": "::/0",
                "next-hop-iface": "eth0",   # Mandatory

Same, I do not think it is mandatory.
                "next-hop-address": "fe80::1"
            },
        ],
    }
```

Notes:
 * The 'auto' or 'dhcp' route entry will be ignored when applying via
   nmstate.
 * For single route entry with multiple next-hops, nmstate will show it
   as multiple route entries with the same destination.
 * Regarding YANG(RFC-8022) compatibility, we will create a translator
   when we adding YANG support.
 * For future source routing support, we could add top entry as
   'route-rules' or other name to be decided.
routing-->rule will be nice.
 * For future support of OSPF, BGP, we could add top entry as 'ospf'
   or 'bgp' to hold their configuration and extend the 'protocol' types
   in above schema.

Any comments or suggestions will be appreciated.

What about adding or deleting an entry.
Can we use `state` to express existence and absent?
For cases where there are hundreds of routes, asking the user to specify all will not work well.


Thank you very much in advance.
Best regards.

[1]: The "auto" protocol in "ipv6-routes" means IPv6 Router
     Advertisement.

--
Gris Ge


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]