Subject: [netmod] half-review of routing-cfg-04

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Aug 2012 14:21:13 -0700

I've reviewed the non-yang-module sections of the routing-cfg file.  I
think I'd really need another read to fully absorb it all.  But in the
mean time, I have the following concerns/questions/suggestions:

1) section 4.1, this text is really not needed:

      Apart from the key, each entry of the "rt:interface" list MAY contain
      other configuration or operational state data related to the
      corresponding router interface.

   That's really the whole point of netconf/netmod in the first place:
   nearly anything may contain more data.  If you're stating that future
   sections will conditionally add more data to this section, then I'd
   suggest being more explicit about that.

2) section 4.2 should probably include RPKI status, as should another of
   other references to it (eg, the active-route RPC).  At a minimum,
   I'd suggest listing 3 RPKI result status types: "unknown", "valid"
   and "invalid".

3) for 4.3, I had the same question previously discussed: why wouldn't
   "main-ipv4-unicast" and "main-ipv6-unicast" naming be a MUST.  I'm
   trying to envision writing a manager that can take the config and do
   something like draw a pretty diagram based on what I pull in, and
   without a starting point I have to make educated guesses about what a
   vendor might have intended by a random label such as "myroutes", and
   these guesses will most likely be incorrect.  Interoperability, IMHO,
   will fail if we don't have a standard starting container name.  It
   doesn't prevent you from having others, if implementations need more
   than one.

4) section 4.3 says that additional routing tables are
   implementation-specific.  I'd add "and/or configuration-specific".

5) 4.4.1: I'd also argue that "a typical implementation will have
   exactly one instance per logical router" should be "a typical
   configuration..."

6) 4.4.1: ' "rt:route" inside "rt:routing-table" ' would be better
   expressed as simply a full path.

7) 4.4.2: the 'tag' is a uint16, and I think it should be a uint32.
   Although current RIP defines a uint16, it doesn't make sense to limit
   the data model to uint16 if a future version may rev the protocol to
   allow for uint32 tag space.  See the discussion surrounding the
   configuration of SNMP data lengths recently discussed here :-)

8) Similar for the range 10..60 for the update-interval.  I actually
   wonder if vendors have allowed for shorter/longer update intervals in
   their implementations in places.  I don't know, so I'll defer to your
   judgment, of course, but I thought I'd mention it for consideration.

9) 5.1: so if if:enabled is changed to 'false', then all configuration
   is dropped?  Disabled?  vendor-specific-decision?  The way the text
   is now, I'd argue it's vendor-specific but clarity might be a good
   thing.

10) 5.2: The way I read the final paragraph, it means that if I have a
    manually configured change to the routing configuration such that
    I've modified a direct route in the main routing table to redirect
    it, then the instant the interface's netmask, for example, is
    reduced then it'll reset my original configuration change to the
    default outgoing interface output?  Or is the direct route in the
    main routing table read-only and the only way to modify it would be
    to inject a manual static route that would take precedence?

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Aug 2012 17:58:49 +0200

Hi Wes,

thanks for the review, my responses are inline.

>    suggest being more explicit about that.

You are right. Actually, the point to explain here is that "rt:interface" is modelled as a list rather than a leaf-list in order to allow for augmenting the entries with other stuff.

>    I'd suggest listing 3 RPKI result status types: "unknown", "valid"

I think this attribute should be augmented in from a separate RPKI module (remember the DHCP discussion in Vancouver). We only have static routes so far and for them RPKI makes no sense.

>    doesn't prevent you from having others, if implementations need more

OK, if there are no objections, I will make it a MUST.

>    implementation-specific.  I'd add "and/or configuration-specific".

Martin asked about that paragraph in his review. It is intended to say that implementations may decide (i) to add other "system" routing tables that cannot be deleted, and (ii) to provide (or not) the option of user-configured tables. I will clarify the text.

>    exactly one instance per logical router" should be "a typical

Yes, Martin also had this comment.

>    expressed as simply a full path.

OK, it still fits the line length limit:
 
/rt:routing/rt:router/rt:routing-tables/rt:routing-table/rt:route

>    configuration of SNMP data lengths recently discussed here :-)

Appendix E says that the "example-rip" module is intended only as an illustration rather than a real definition of a data model for the RIP routing protocol. So I think this doesn't really matter.

>    judgment, of course, but I thought I'd mention it for consideration.

Ditto.

>    is now, I'd argue it's vendor-specific but clarity might be a good

The text says: If this switch is set to "false" for a given network layer interface, the device MUST behave exactly as if that interface was not assigned to any logical router at all.

Nothing about dropping any configuration (there is no "when" statement based on "if:enabled").

>     to inject a manual static route that would take precedence?

It is the latter. Direct routes are operational state resulting from IP configuration on interfaces. Within the routing module, the only configurable part is that the "direct" pseudo-protocol may be reconnected to a "non-main" routing table.

Lada
 
>
> -- 
> Wes Hardaker
> SPARTA, Inc.
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Aug 2012 09:08:55 -0700

> Hi Wes,
....
> OK, if there are no objections, I will make it a MUST.

It appears you are introducing a "YANG identifier CLR".
IMO this is a really bad idea.  Introducing any sort of
structure into identifier strings is a bad idea, let alone
a SHOULD or MUST requirement.

If this issue is something else then ignore this comment ;-)

> Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 21 Aug 2012 20:07:29 +0200

> a SHOULD or MUST requirement.

So what do you suggest?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Aug 2012 11:29:33 -0700

>> a SHOULD or MUST requirement.

I assume this is the text in question:

  One routing table MUST be present for each router instance and each
   address family supported by that router instance.  It is the so-
   called main routing table to which all routing protocol instances
   supporting the given address family SHOULD be connected by default.
   For the two address families that are part of the core routing data
   model, the names of the main routing tables SHOULD be as follows:

   o  "main-ipv4-unicast" for IPv4 unicast,
   o  "main-ipv6-unicast" for IPv6 unicast.

If it is so important to identity each 'main routing table' then add
an schema-identifier leaf (config=false) that the server
will set, pointing to it.

We don't need YANG node naming CLRs.
We did that with SNMP requiring "the plural form"
of the counter name in all cases.  IMO, a waste of time
and just adds historical baggage.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Aug 2012 10:51:33 +0200

> and just adds historical baggage.

An alternative is to add a new leaf representing routing table type, and require that exactly one routing table of the type "main" be present for each address family.

Lada

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Aug 2012 09:28:46 -0700

Ladislav Lhotka <[email-masked]> writes:

> Appendix E says that the "example-rip" module is intended only as an
> illustration rather than a real definition of a data model for the RIP
> routing protocol. So I think this doesn't really matter.

People use examples far too often as normative, or cut-and-paste them
into the "reals" later.  IMHO, a fix now prevents that and doesn't hurt
the now.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Aug 2012 09:32:09 -0700

> and just adds historical baggage.

The issue is how a manager, unfamiliar with a device, would know where
in the data routing tree to take as the "top" table to which everything
else is connected.  If you don't have something labelled as
"main-ipv4-unicast" then a manager has no hope of achieving
interoperable configuration settings across multiple routers when one
implementation chooses "four-forever" and another "routes" and another
"main-ipv4-unicast".  There is no way a manager can know the possible
starting names of all the route tables unless there is commonality
between the implementations (or you end up with managers that have to
know of every implementation and their hacks).
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Aug 2012 09:46:37 -0700

> know of every implementation and their hacks).

IMO a leaf pointer identifying the top routing table is a much
better solution.

Unfortunately, the node-instance-identifier data type is in
ietf-netconf-acm.yang:
http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#node-instance-identifier.167

  leaf main-ipv4-unicast-ptr {
    type acm:node-instance-identifier;
    description
       "Identifies the object node of the main IPv4 unicast routing table.";
  }

Hard-wiring YANG node names seems wrong to me.
You want to encode semantics into the node identifier.
The only semantics should be "the local-name that uniquely
identifies this node among its sibling nodes.".

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Aug 2012 12:43:46 -0700

> IMO a leaf pointer identifying the top routing table is a much

That's fine too, IMHO, as long as there is a starting point.  Nuking it
entirely leaves none.

[note you need multiple lookups though, not just one leaf...  you need
one per routing starting point, eg ipv4 and ipv6]
-- 
Wes Hardaker
SPARTA, Inc.