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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Dec 2013 16:16:10 +0100

Hi,

I hereby like to start a WG last call for the document "A YANG Data
Model for Routing Management":

  http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12

Please indicate your support by Friday December 20th. We are not only
interested in receiving defect reports, we are equally interested in
statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

This is the 1st WG last call on this document.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 3 Dec 2013 23:05:13 +0000

I have reviewed I-D draft-ietf-netmod-routing-cfg-12 and I found no issues.

Lisa

On 12/3/13 7:16 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 15 Dec 2013 22:03:38 +0100 (CET)

Hi,

I have reviewed this document, and here are my comments:

I plan to implement this data model for a non-router (host).  In the
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"
pseudo-protocols, allow exactly one user-controlled routing instance
(?), do not implement "multiple-ribs".  What does router-id mean for a
host?  Does a host have to implement the configuration tree for ribs?

-----------

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).

-----------

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.

And: s/operational status/operational state/

-----------

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
"active-route" operation, I have to first figure out the "id" of the
routing-instance, and then use this id.  It seems simpler to always
use the name.   Also, the "id" is optional, which makes it unsuitable
to be used as an identifier.

The same comment applies to /routing-state/ribs/rib.

Also, for the lists that do need an "id" (route, nexthop), the id leaf
needs to be mandatory.

-----------

In 5.4.1:

   Every routing instance MUST implement exactly one instance of the
   "direct" pseudo-protocol type.  The name of this instance MUST also
   be "direct".

Why does this name have to be "direct"?  I think this should be
removed or explained, b/c now if seems arbitrary.

------------

Editorial nit:  your yin2yang script adds (or doesn't strip) empty
lines in some cases:

       description
         "Return the current number of routes in a RIB.

          If the RIB with 'id' equal to 'rib-id' doesn't exist, then
          this operation SHALL fail with error-tag 'data-missing' and
          error-app-tag 'rib-not-found'.
         ";

-----------

Editorial: s/RIBS/RIBs/

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 16 Dec 2013 16:03:43 +0100

Hi Martin,

thank you for the review.

> I plan to implement this data model for a non-router (host).  In the

Good. Do you plan to generate some platform-specific init scripts, or use another mechanism for getting the configuration into the system guts?  

> 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.  

> (?), 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. 
 
> host?  Does a host have to implement the configuration tree for ribs?

It depends, see above, but probably only when implementing "multiple-ribs".

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? 
 
> 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.

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.

> "active-route" operation, I have to first figure out the "id" of the

Either way, you have to figure out the name or id, and the number seems safer than an arbitrary-length string in terms of type validation.

> to be used as an identifier.

They should be mandatory in any case, that's a mistake. As you know, I intended to have the numeric ids in the role of opstate list keys.

> Also, for the lists that do need an "id" (route, nexthop), the id leaf

Yes.

Yes, now that "source-protocol" contains the protocol type rather than protocol instance name, the name is not important. I will remove the last sentence.

We already talked privately about the closing quote and semicolon, and I changed the stylesheet so that they will be placed immediately after the text.

But if you mean the empty line inside the description, then I think it is important there.

OK, that's my "systematic" typo.

Thanks, Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Dec 2013 19:56:27 +0100

> This is the 1st WG last call on this document.

This WG last call did end. We received a detailed review by Martin
(but I am not sure all issues got resolved) and a review by Lisa. I
contacted the routing area but have not received anything from them.
It would not hurt to receive another review as an xmas present...

But assuming Martin's comments can get resolved, I will move this
document to Benoit's desk since it received significant reviews from
various routing experts before.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 27 Dec 2013 11:45:09 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
Hi,

> Good. Do you plan to generate some platform-specific init scripts, or use
> another mechanism for getting the configuration into the system guts?

Probably init scripts and using the ip command.

> 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.

> 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.

> 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
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".

> 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.
> 

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.

> 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...

> 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.

> Either way, you have to figure out the name or id, and the number seems safer
> than an arbitrary-length string in terms of type validation.
> 
> They should be mandatory in any case, that's a mistake. As you know, I intended
> to have the numeric ids in the role of opstate list keys.
> 
> >
> Yes, now that "source-protocol" contains the protocol type rather than protocol
> instance name, the name is not important. I will remove the last sentence.
> 
> >
> > ------------
> >
> We already talked privately about the closing quote and semicolon, and I
> changed the stylesheet so that they will be placed immediately after the text.

Ok.

> But if you mean the empty line inside the description, then I think it is

No I just meant the trailing newlines.  I agree that the newlines
inside the descriptions are correct.

/martin