Subject: Re: [netmod] changes in the routing model

From: David Lamparter <[email-masked]>
Date: Sun, 3 Nov 2013 19:43:03 +0100

On Thu, Oct 24, 2013 at 02:38:12PM +0200, Ladislav Lhotka wrote:
>    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.

I disagree that this distinction is sufficient - or it might be in the
wrong place.  There is a very large class of devices that support ECMP,
but not multiple RIBs.  Members of this class are most medium-level "L3
switches", and a good number of software forwarders (e.g. firewalls.)

Features aren't high-cost, are they?

If you want to not make this a feature, having simple devices constrain
it to a single entry list might be an option too.

-David

[will raise this on the mic for discussion if needed]

PS: I've read the entirety of it & the draft otherwise looks good to me.
Content review only, didn't look at language or formal correctness.
 
>    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.

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 3 Nov 2013 14:50:50 -0800

> switches", and a good number of software forwarders (e.g. firewalls.)

OK, if it is so, we can make it into distinct features.

> Features aren't high-cost, are they?

No, not really.

> [will raise this on the mic for discussion if needed]

I will add it as an open issue to my presentation.

> Content review only, didn't look at language or formal correctness.

Thanks!

Cheers, Lada

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 14:41:36 -0800 (PST)

Hi,

I have some comments on the recent changes:

Ladislav Lhotka <[email-masked]> wrote:
>    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.

Based on the above, I understand that the route and nexthop lists have
integer keys (they are actually uint32 in the model).  But why do the
'routing-instance' and 'rib' need to have uint64 id as key in
operational state?  This just seems to make configuration complex -
the user must find some numerical id in the operstate, then give the
rib a name, and write the numerical id.  Couldn't the name be key in
both config and state, and if a numerical id is needed in oper state
it could be a normal (unique) leaf?

If the current design is kept, what is the 'id' of a user-controlled
entry?  I assume it is not needed, and if so this should be made clear
in the description.

-----------

s/A routing instance together with its operational status is/
  A routing instance together with its operational state is/

-----------

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

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Nov 2013 15:54:35 -0800

> integer keys (they are actually uint32 in the model).  But why do the

Actually they are all uint64. I2RS guys insisted on numeric handles because they will be sent back and forth in their messages.

> it could be a normal (unique) leaf?

I think it is better to have distinct keys in config and state lists. The keys of system-controlled entries in operational state need not be persistent, and should they change after reboot, they couldn’t be updated in config if they are keys there as well. Note that a system-controlled entry (from the NECONF POV) can also be injected by an I2RS agent.

The user also has to care only about uniqueness of keys that he himself assigned to config entries.

> entry?  I assume it is not needed, and if so this should be made clear

The user creates the entry in config with an arbitrary name, and if the system accepts the entry, it will assign it a unique “id", and both “name" and “id" appears in operational state.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 05 Nov 2013 16:49:25 -0800 (PST)

Ladislav Lhotka <[email-masked]> wrote:
> Actually they are all uint64.

Some are uint32 in the draft.

> I2RS guys insisted on numeric handles
> because they will be sent back and forth in their messages.

This doesn't imply that they have to be keys.

> I think it is better to have distinct keys in config and state
> lists. The keys of system-controlled entries in operational state need
> not be persistent, and should they change after reboot, they couldn’t
> be updated in config if they are keys there as well. Note that a
> system-controlled entry (from the NECONF POV) can also be injected by
> an I2RS agent.

If the id changes after a reboot, it means the config after a reboot
might lead to surprising results.  Suppose there are oper entries with
id 1 and 2, and we config those by inventing names and use them in the
config.  After a reboot, the old entry 1 is now 2, and the old 2 is 1.
The system applies the config, but it will be for the wrong entries.

With persistent names, the id can change after a reboot.

/martin