On Thu, 2019-02-28 at 22:40 +0200, Edward Haas via networkmanager-list
wrote:
> 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.
I think it should be mandatory. Kernel or iproute2 may detect certain
next-hop-interfaces by looking at whether there is a direct route to
the next hop (on an interface). But that seems fragile to me, and
something you can do ad-hoc (at the moment when issuing the iproute2
command), but not so well in a description of the state (which, is
kinda timeless).
Also, it is mandatory *for a lot* of cases. It's effort to pin down
exactly when it's mandatory and when not.
Also, a mandatory paramter can later always be relaxed for bing not
mandatory. But making it mandatory later is an API break.
The implementation can require it per its logic, but I prefer the schema to allow it.
I think that most usages are for simple IP route entries and not P2P ones, in which
we do not want to be bound to a specific device at the desired state.
If this is supported, changes to the devices names or addresses on them do not
need to change the route/desired state.
For a user, it also does not require knowledge about which device to use, the system
will take care of that for him.
best,
Thomas
