[irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.

[Bruno Rijsman <[e-mail]>]

I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft.

1) Generalize the concept of a next-hop

It appears that in the current model, routes can point to an outgoing interface and a next-hop address. The concept of next-hops needs to be generalized. Next-hops can have multiple tuples of outgoing interfaces and next-hop addresses. The most common reasons is Equal Cost Multi Path (ECMP) where a single route has multiple next-hops. This is not the same as multi-pathing in the sense of multiple active routes to the same prefix each contributing one next-hop. A variation of this is NECMP where the next-hops are different weights. Another reason for multiple next-hops is fast re-route where the next-hops represent alternatives (the first one whose interface is up is used). Another needed generalization of next-hops is the ability to push and pop MPLS labels, VLAN tags, etc. Another is the ability to add a level of indirection (e.g. BGP indirect next-hop for fast BGP reconvergence). The OpenFlow 1.x documents are a good source to look for generalized next-hop examples. 

2) Generalize the concept of a prefix

Section 4.2 says that the core routing data model only defines the following minimal set of route attributes: destination-prefix, next-hop, outgoing-interface. However, in section 4 there are no destination-prefix or next-hop. There are only v4ur:dest-prefix, v4ur:next-hop, v6ur:dest-prefix, v6ur:next-hop. It appears that the destination-prefix and next-hop were removed from the base object and moved to the derived object. In my opinion, it would make sense to move the destination-prefix (as a simple bit-string and length) and the next-hop back to the base object. The derived object could have a string object to contain the destination-prefix as a human-readable string (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes that the routes are always IP routes (it uses repeatedly uses terms like "IP prefix"). The routes can be non-IP routes. For example, MPLS routes which are /20 exact matches on a label, or CLNS routes, or other protocols. Some VPLS implementations even use the "routing table" abstraction to represent Ethernet routes (as exact /48 routes on MAC addresses).

3) Static (and direct) routes for multiple routing tables.

Figure 2 appears to imply that static and direct routes can only be inserted in the main routing table. Is it possible to install static routes in multiple additional routing tables?  

4) More attributes for static routes.

Configured static routes (routes in the pseudo routing-protocol "static") need more attributes  (e.g. metric).

5) Add support for routing-instances.

Allow the creation of multiple routing-instances (also known as VRFs) per logical-router. Allow interfaces to be assigned to routing-instances. Allow multiple instances of routing protocols, scoped by routing-instance.

6) Ability for a client to subscribe to RIB changes

It would be very useful for a client to be able to subscribe to route table changes. (I am not a YANG expert and I don't know if such a thing is even possible in YANG.) In the subscription, the client could specify one or more routing tables in which it is interested and filter(s) to specify which subset of routes it is interested in.

7) More sophisticated filters

Section 4.5 explicitly says that the core routing data model only defines a skeleton for filtering. It would be "good" for the working group to continue this work and define more sophisticated filtering mechanisms.

-- Bruno

PS: Cross-post to the Interface to the Routing System (IRS) mailing list because they are discussing very similar functionality.