Subject: [netmod] routing-cfg issues

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Sep 2012 13:48:33 +0200

Hi,

the WGLC for the routing-cfg document resulted in several open issues where I am not sure how to proceed. I am summarising these issues below and listing the available options that are known to me. Please express your opinions.

Thanks, Lada

1. Multiple router instances
----------------------------

Phil Shafer argued that the present attempt to provide a list of router instances as a "one size fits all" means for implementing various forms of router virtualisation (complete logical routers, VRF instances for MLPS etc.) is doomed to failure. He proposed to get rid of this list and deal with just a single router instance in the core model. Every virtualisation style then would define its own data model, possibly repeating some data nodes from the core model.

On the other hand, previously I received positive feedback on having the list of router instances in the core model.

Options:

1.1. Do nothing.

1.2. Add the "type" leaf under "router" so that router instances of different virtualisation types can coexist in the same list, have their specific data etc.

1.3. Remove the list and have just one router instance.

2. Required list entries
------------------------

The core routing model requires that certain objects (typically list entries) exist in every implementation - for example the main routing table, or the "direct" routing protocol. These objects are supposed to be provided by the device, so they are in fact operational state data. However, other entries in the same type may be configured by the client. It is necessary to be able to refer from the same location (a leafref node) both to the system-provided entry and to the configured entries.

Options:

2.1. Implementations will supply the mandatory objects as entries of a config=true list but declare them read-only so that they cannot be deleted by the client.

2.2. The mandatory entries will exist as state data, but outside the core data model. A client wanting to refer to them will have to explicitly configure a corresponding dummy entry in the config=true list and refer to this entry.

3. Designating the main routing table
-------------------------------------

The core routing model requires that every implementation have the main routing table for each protocol family, which is the destination for direct routes and default destination for other routes. The text currently fixes the name of the main routing table (using SHOULD) to "main-ipv4-unicast" etc. So this is the way how the main table can be recognised among other routing tables. Several different changes have been proposed during the WGLC: Martin and Wes proposed to make the name a MUST instead of SHOULD, whilst Andy argued that semantics should not be encoded in the name. 

Options:

3.1. Really fix the main routing table name, i.e. make it a MUST.

3.2. Introduce a new leaf node, e.g. "main-routing-table", pointing to the main table. 

3.3. Add the "type" leaf under "routing-table" and use it for distinguishing the main routing table from the rest.

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Sep 2012 10:11:43 -0700

Ladislav Lhotka <[email-masked]> writes:

> 2.1. Implementations will supply the mandatory objects as entries of a
> config=true list but declare them read-only so that they cannot be
> deleted by the client.
>
> 2.2. The mandatory entries will exist as state data, but outside the
> core data model. A client wanting to refer to them will have to
> explicitly configure a corresponding dummy entry in the config=true
> list and refer to this entry.

ugh...  This is where the whole "lets separate config and operational
state" kinda falls apart.  If you want to keep that separation pure,
then when someone does a get-config dump so they can later re-upload it
after rebuilding a system, you certainly don't want "direct" entries in it
that will conflict because they don't match the new-device's internal
state.  Thus, it seems to me they shouldn't be listed as config or else
those scripted config-grabs will get confused.

But that doesn't feel right either.  Sigh.

> 3.3. Add the "type" leaf under "routing-table" and use it for
> distinguishing the main routing table from the rest.

My preference order: 3.2, 3.1 then 3.3
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 11 Sep 2012 20:57:28 +0200

> those scripted config-grabs will get confused.

The *contents* of routing tables, i.e. routes, are always state data, even in an explicitly configured table, so a get-config dump can only contain a list of static routes but never any direct routes.
  
> My preference order: 3.2, 3.1 then 3.3

OK.

Thanks, Lada