Subject: [netmod] changes in the routing model

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Oct 2013 14:38:12 +0200

Hi,

I am sending more details about the recent changes in the routing draft. Most of them follow from the discussion with I2RS people (Jan Medved, Nitin Bahadur, Sriganesh Kini, and Hariharan Ananthakrishnan). Besides email exchange, we also had a teleconference.

The basic plan lies in the following correspondence:

| I2RS            | NETCONF/YANG           |
|-----------------+------------------------|
| ephemeral data  | operational state data |
| persistent data | configuration          |

It means that I2RS agents will be able to read and write (parts of) what is operational state data in the NETCONF sense, but any such changes will not survive reboot. To make persistent changes, I2RS agents will write NETCONF configuration datastore(s). It is an open question whether I2RS agent will be able to act as a compliant NETCONF client, with regard to locks etc.

The motivation and reasoning behind the main changes is the following:  

   o  Migrated address families from IANA enumerations to identities.

I2RS people strongly preferred identities to the IANA enumerations. Meanwhile, a discussion in this list also turned out in favour of identities, so I decided to bite the bullet, and there is now only one identityref leaf specifying an address family instead of two (AFN and SAFI), which is IMO a positive change.

   o  Terminology and node names aligned with the I2RS RIB model: router
      -> routing instance, routing table -> RIB.

I2RS WG are the domain experts, so it makes sense to follow suit. 

   o  Introduced uint64 keys for state lists: routing-instance, rib,
      route, nexthop.

The idea is that an I2RS client creates an entry (e.g. a route) and gets back a unique numeric handle that can be used later for referring to that entry. Modelling these handles as keys of operational state lists then seems quite natural.

   o  Feature "user-defined-routing-tables" changed into "advanced-
      router".

I didn't want to introduce more features, I think the distinction between a basic and advanced router should be sufficient.

   o  Made nexthop into a choice in order to allow for nexthop-list
      (I2RS requirement).

   o  Added nexthop-list with entries having priorities (backup) and
      weights (load balancing).

The last two changes implement multipath routes that are crucial for I2RS. Both are bound to the feature "advanced-router", so simple devices needn't bother with it.

Lada

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Oct 2013 13:21:28 -0400

I am a bit confused by teh discussion of configuration / persistent data 
in this email.
I believe the working group agreement with regard to the I2RS 
architecture and persistence is that NO i2RS changes persist across reboot.

Yours,
Joel M. Halpern

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Oct 2013 21:01:42 +0200

On 25 Oct 2013, at 19:21, Joel M. Halpern <[email-masked]> wrote:

> I am a bit confused by teh discussion of configuration / persistent data in this email.
> I believe the working group agreement with regard to the I2RS architecture and persistence is that NO i2RS changes persist across reboot.

This was my original understanding, too, but the authors of the RIB info model expressed the need for persistent data - routes in particular. This is an excerpt from the “minutes” of our teleconference, by Jan:

  The current model has clear distinction between config and operational
  data. If i2rs wants to use the data model it needs to define a yang
  extension identifying data as read-write as opposed to read-only. This
  will work well for ephemeral data. For persistent data, use the config
  tree to add static routes - but a static route entry has to have almost
  all (or all?) the attributes that an ephemeral route entry has.

Lada

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Oct 2013 15:13:39 -0400

There appears to be a miscommunication of some kind.
Quoting from section 5.2 of draft-ietf-i2rs-archtiecture:
    The I2RS Agent will not attempt to retain or reapply state across
    routing element reboot.

I will not attempt to read Jan's mind or provide interpretation.
Rather than taking my word, I suggest you raise this question on the 
I2RS mailing list.

Yours,
Joel

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 25 Oct 2013 21:28:55 +0200

On 25 Oct 2013, at 21:13, Joel M. Halpern <[email-masked]> wrote:

> Rather than taking my word, I suggest you raise this question on the I2RS mailing list.

Either way, it is not an issue for the NETMOD routing model, so I believe we can proceed to WGLC.

Lada