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

[Thomas Haller <thaller redhat com>]

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.


best,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part