Re: [RFC] [nmstate] Linux routing in nmstate
Hi, On Tue, 2019-02-26 at 14:56 +0800, Gris Ge via networkmanager-list > "protocol": "dhcp", # "static" or "dhcp" "protocol" sounds a bit like iproute2's "protocol" option (struct rtmsg's rtm_protocol). But I think it's not. I would call this "source". best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
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 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
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Fri, Mar 1, 2019 at 4:34 AM Gris Ge wrote: > On Thu, Feb 28, 2019 at 10:40:48PM +0200, Edward Haas wrote: > > > > What is the root level key? `routing`? > The root level is 'ipv4-routes' and 'ipv6-routes'. > > Try to save a layer for user to type comparing to ['routing']['routes'] > > The ip version is a detail, I do not think it should be exposed at the root. Please also note that the api users are mostly other applications, so we need a balance between a good programmatic structure and human ease of use. > ipv4 and ipv6 look identical to me here. > > It makes sense then to have `route` as the subtree and a `family` > > entry inside. > OK. And we could auto detect the family if user does not specify it when > applying. > Ahh... in the morning I realized that this is problematic when we need to represent it in a json schema. Usually one key has a single type (and a format is a type I guess). I do not know if we can overcome this. (think of a user that uses a typed language, how will it be described there (type)?) > "next-hop-iface": "eth0", # Mandatory > > > > > > This is not mandatory on `iproute2`, it is usually resolved based on > > the address next hop. > Will remove the mandatory thing. > > > "ipv6-routes": [# Sorted with 'table-id' then > 'destination' > > "protocol": "auto", # "static" or "auto"[1] > > I prefer a more meaningful name, `auto` is problematic. > How about 'ipv6-ra' for router advertisement? > If we will be under an ipv6 subtree, `ra` should be enough (or the full name, router-advertisement). If not, and we have here protocols for both, then +1. > * For future source routing support, we could add top entry as > >'route-rules' or other name to be decided. > > > > routing-->rule will be nice. > Same reason above, save some typing. > > 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. > User could just remove the entry from what he/she got from > `libnmstate.show()`. I don't know why that's hard for user. > Can you elaborate the use case? > We support it explicitly with interfaces. Using show and the apply is valid, but with a large number of routes, it is very traffic and process consuming. But perhaps the main disadvantage is the assumption that the user is reading the state. There are several users which we know today that handle things in one direction only. As a reminder, for the nmstate api we have taken an explicit decision to allow applying snippet configurations. > Thank you very much. > Best regards. > > -- > Gris Ge > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Thu, Feb 28, 2019 at 10:40:48PM +0200, Edward Haas wrote: > > What is the root level key? `routing`? The root level is 'ipv4-routes' and 'ipv6-routes'. Try to save a layer for user to type comparing to ['routing']['routes'] > ipv4 and ipv6 look identical to me here. > It makes sense then to have `route` as the subtree and a `family` > entry inside. OK. And we could auto detect the family if user does not specify it when applying. > "next-hop-iface": "eth0", # Mandatory > > > This is not mandatory on `iproute2`, it is usually resolved based on > the address next hop. Will remove the mandatory thing. > "ipv6-routes": [ # Sorted with 'table-id' then 'destination' > "protocol": "auto", # "static" or "auto"[1] > I prefer a more meaningful name, `auto` is problematic. How about 'ipv6-ra' for router advertisement? > * For future source routing support, we could add top entry as > 'route-rules' or other name to be decided. > > routing-->rule will be nice. Same reason above, save some typing. > 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. User could just remove the entry from what he/she got from `libnmstate.show()`. I don't know why that's hard for user. Can you elaborate the use case? Thank you very much. Best regards. -- Gris Ge signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
Thank you Gris.
Comments in-line.
On Tue, Feb 26, 2019 at 8:56 AM Gris Ge 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
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
