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

[Ladislav Lhotka <[e-mail]>]

Hi Bruno,

first of all, I have to apologise that I didn't answer your comments in a timely manner, the message somehow fell through the cracks. :-( I hope it's still not too late though the draft is now at revision -05.

So, thanks for your comments, please see my responses inline.

  
> 
> -------- Original Message --------
> Subject:	[irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
> Date:	Mon, 3 Sep 2012 07:15:08 -0400
> From:	Bruno Rijsman <[e-mail]>
> To:	[e-mail] <[e-mail]>
> CC:	[e-mail] <[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.

I assume that multiple next-hops to the same destination will appear as two separate routes. And indeed, the two routes may have different weights.

MPLS is outside the scope for the core routing data model, although the framework should be ready to incorporate MPLS etc. via augments from other modules.

> 
> 
> 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

Why is it a problem? These parameters are address family specific, so they are defined in the ietf-ipv[46]-unicast-routing modules. Each routing table only contains routes of a single address family, so the ipv4:* and ipv6:* nodes can never appear as sibling elements in a configuration or state data.

> 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 implemen
> tations even use the "routing table" abstraction to represent Ethernet routes (as exact /48 routes on MAC addresses).

Sure, modules for other address families can define their own parameters of routes. They are supposed to be filled in via YANG augments. The core routing data model only deals with IP.

> 
> 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?

This is now better explained in revision -05. Direct routes are always installed in the main routing table but the static pseudo-protocol can be connected to any table. Routes from any table can be installed in other routing tables by means of the mechanism of recipient routing tables and filters (sec. 4.3).

Figure 2 is just an example.

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

This can be done, although the use case for metrics of static routes is not very clear to me, unless there is a way for redistributing such routes to other routing protocols. Such parameters can be added via augments from other (generic or vendor-specific) modules, if necessary. In the core routing model, we tried to limit the number of parameters to a reasonable minimum, or otherwise we will never finish this work.

> 
> 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.

In rev. -05, each router instance has the "type" parameter so that the same flat list of router instances may contain VRFs as well as self-contained logical/virtual routers that differ in the type parameter. New modules defining a particular router type then have to specify the rules. e.g., whether/how routing tables can be shared among router instances.

> 
> 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.

This can be done using a NETCONF notification, but again - I am afraid of feature creep, so I would leave this extension to a separate module.

> 
> 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.

When we were discussing the current NETMOD charter, I proposed to work on route filters but I didn't get support for this idea. Anyway, this should probably be addressed by routing experts - I will be happy to help.

There is now a draft/module on ACLs (http://tools.ietf.org/html/draft-huang-netmod-acl-01) that goes in this direction.

Thanks, Lada

> 
> -- Bruno
> 
> PS: Cross-post to the Interface to the Routing System (IRS) mailing list because they are discussing very similar functionality.
> _______________________________________________
> irs-discuss mailing list
> 
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> 
> 
> 
> 
> 
> 
> 
> 

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