Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Dec 2013 14:24:16 +0100

Martin Bjorklund <[email-masked]> writes:
...
>
>> > introduction and objectives section it is mentioned that this data
>> > model is suitable for such a device.  I think the document should
>> > include a section that discusses what such an implementation should
>> > do.  For example, implement the "static" and "direct"
>> 
>> I can add this, perhaps as an appendix, although it won't be as straightforward
>> as you might think, see below.
>
> This is actually a good reason for having such a text.  Otherwise an
> implementor of a host that "just want some static routes" might think
> that this module is overkill and not suitable.

OK, I will try to write an appendix describing the minimum variant.

>
>> > pseudo-protocols, allow exactly one user-controlled routing instance
>> > (?), do not implement "multiple-ribs".  What does router-id mean for a
>> 
>> It depends on where you draw the line between a host and a router. For example,
>> in Linux you can configure user-defined routing tables straight in the kernel.
>> 
>> router-id is only useful for (some) routing protocols. On the other hand,
>> configuring it on a host is OK, it will only have no effect.
>
> This should probably be clarified in the description of this leaf.

OK.

>
>> > host?  Does a host have to implement the configuration tree for ribs?
>> 
>> It depends, see above, but probably only when implementing "multiple-ribs".
>
> So should the entire subtree (/routing/ribs) have an if-feature
> multiple-ribs stmt?  Or would this be too limiting?  If it is too

Almost, there is one problem though, that even with a single (default) RIB per address family, it can be useful to be able to define import and export filters for controlling the exchange of routes between routing protocols and the RIB. To do this, one has to configure a "connected-rib" entry, which has "rib-name" as the key. And because "rib-name" is a leafref, the default RIB has to appear in the configuration, due to the CLR that a configuration leafref cannot point to state data.

Actually, "connected-ribs" is already "if-feature multiple-ribs", which is also incorrect, for the same reason.

> limiting, maybe we can provide some additional info in the description
> text.  As it is defined right now, I am not sure what is expected of
> an implementation of a "simple host".
>
>> > In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
>> > instead?
>> >
>> > -----------
>> >
>> > In the document, term "netxhop" is used.  Should this be "next hop"
>> > (in text) and "next-hop" (in data models).
>> >
>> > -----------
>> 
>> We have "leaf gateway" and "list nexhop" appearing in two different cases of
>> the same choice ("nexthop-options"), so due to YANG rules they cannot have the
>> same name. In my view, the term "gateway" is acceptable for this purpose, it
>> only should be also mentioned in the text of the document.
>> 
>> Or do you have another proposal for modelling that choice? 
>
> Maybe:
>
>       case next-hop-list {
>         if-feature multipath-routes;
>         container next-hops { // or container next-hop-list
>           list next-hop {
>
> This would also be consistent with the design of the rest of the
> module.

I was thinking about this, too, but it means an extra container per route, and I am not sure whether this is an issue or not, i.e. whether there can be tens of thousands of multipath routes.

>
>> > 5.1
>> >
>> >    A routing instance together with its operational status is
>> >    represented as an entry of the list "/routing-state/
>> >    routing-instance", and identified by a unique numeric identifier.
>> >    Configuration of that router instance appears as entry of the list
>> >    "/routing/routing-instance" whose key is a routing instance name
>> >    selected by the client.
>> >
>> > But there is no numeric identifier anymore.
>> 
>> OK, this has to be updated.
>> 
>> >
>> > And: s/operational status/operational state/
>> 
>> OK, although I consider "status" and "state" to be synonyms.
>
> 6241 has this definition:
>
>    o  state data: The additional data on a system that is not
>       configuration data such as read-only status information and
>       collected statistics.
>
> So it seems there is some distinction between the terms...

OK.

>
>> > -----------
>> >
>> > Since the /routing-state/routing-instance list has a name, and the
>> > name is the key, why does it also have an "id", and why is the "id"
>> > used in references to the routing-instance?  When I invoke the
>> 
>> It was a specific request from I2RS to have numeric entry identifiers for the
>> lists they are interested in, mainly because these IDs will be sent back and
>> forth in their protocol data and they strongly prefer fixed-size integers to
>> free-form strings.
>
> Ok, this motivates the "id" - I think it would be useful to explain
> this in the description text, i.e, that the id can be used in
> protocols that requires a fixed-size integer.
>
> This is fine, but I still think this data model should use the list
> key (string) in references.  If some (future) protocol needs to use
> the id, they can do that.
>
> Also, we discussed previously the persistency of these identifiers.
> Is it required that these ids are the same after a reboot?  This
> should be clarified.

Actually, I was considering the option of leaving these "id" leaves out, with the assumption that I2RS can augment them as needed. The only problem with this is another YANG CLR - they might want these ids to be mandatory, and this is not allowed via "augment".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Dec 2013 15:54:49 +0100 (CET)

> Almost, there is one problem though, that even with a single (default) RIB per
> address family, it can be useful to be able to define import and export filters
> for controlling the exchange of routes between routing protocols and the
> RIB. To do this, one has to configure a "connected-rib" entry, which has
> "rib-name" as the key. And because "rib-name" is a leafref, the default RIB has
> to appear in the configuration, due to the CLR that a configuration leafref
> cannot point to state data.
> 

So this feature is not needed?  I guess it should still be defined,
since it means that ribs other than the default rib can be
configured.

> I was thinking about this, too, but it means an extra container per route, and
> I am not sure whether this is an issue or not, i.e. whether there can be tens
> of thousands of multipath routes.
 
It is a NP-container so it shouldn't be a problem.  It adds some noise
to the payload, but I think it should be ok.

> Actually, I was considering the option of leaving these "id" leaves out, with
> the assumption that I2RS can augment them as needed. The only problem with this
> is another YANG CLR - they might want these ids to be mandatory, and this is
> not allowed via "augment".

Right, and it not possible to declare them as "unique" either
afterwards :(

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Dec 2013 16:52:39 +0100

> since it means that ribs other than the default rib can be

It should mean that no user-controlled list entries are allowed. However, as I wrote, it is sometimes necessary to put a system-controlled entry into the config list in order to be able to refer to it elsewhere in the configuration. So it is not possible to use “if-feature multiple-ribs” for the whole /routing/ribs container.

An alternative is to change the type of “rib-name” links from leafref to a simple string and just say in the description that its value must be the key of an existing entry in /routing-state/ribs/rib, i.e. in the operational state list. Then we could have “if-feature multiple-ribs” on /routing/ribs, though not on connected-ribs.

> to the payload, but I think it should be ok.

OK, if there are no objections from others, I will do that. (Maybe be have to leave some time after the holidays for other people to catch up.)

> Right, and it not possible to declare them as "unique" either

Well, unique could be simulated with a must statement, but anyway, it seems we have to have them in the core routing model. So maybe I can leave them there (perhaps introduce a new feature for them?), but avoid any references to them, and use “name” everywhere. Would this be OK?

Concerning persistence, I *think* these ids are supposed to be ephemeral - they are handles to other ephemeral items.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Dec 2013 18:35:13 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> >> Actually, "connected-ribs" is already "if-feature multiple-ribs", which is
> >> also
> >> incorrect, for the same reason.
> > 
> It should mean that no user-controlled list entries are allowed.

Ok.

> However, as I
> wrote, it is sometimes necessary to put a system-controlled entry into the
> config list in order to be able to refer to it elsewhere in the
> configuration. So it is not possible to use “if-feature multiple-ribs” for the
> whole /routing/ribs container.
> 
> An alternative is to change the type of “rib-name” links from leafref to a
> simple string and just say in the description that its value must be the key of
> an existing entry in /routing-state/ribs/rib, i.e. in the operational state
> list. Then we could have “if-feature multiple-ribs” on /routing/ribs, though
> not on connected-ribs.

I'd rather not make this change now... if you do this, what happens
if the config doesn't match the oper state, e.g., after a reboot or
upgrade?

> Well, unique could be simulated with a must statement, but anyway, it seems we
> have to have them in the core routing model. So maybe I can leave them there
> (perhaps introduce a new feature for them?), but avoid any references to them,
> and use “name” everywhere. Would this be OK?

Works for me, and I don't think a feature is necessary.

> are handles to other ephemeral items.

Ok.  In any case it should be stated.

/martin