Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-routing-cfg

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Mar 2012 20:38:16 +0100

On Fri, 23 Mar 2012 12:04:10 +0100, <[email-masked]> wrote:
> Hello, 
> 
> I have been selected as Routing Directorate reviewer for an early review of this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. This particular case is an early review requested by Routing ADs, with the goal of assessing the relevance of the work and eventually provide guidance.
> 
> 
> Although these comments are primarily for the use of the Routing ADs, it can be helpful if you consider them along with any other comments that you receive.
> 
> For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html 
> 
> Document: draft-ietf-netmod-routing-cfg-02
> Reviewer: Thomas Morin
> Review Date: 2012-03-22
> Intended Status: Standards Track
> 
> 
> Summary: 
> 
> My overall impression of this document is rather positive, it seem to me as providing a good starting point for covering routing tables and routing protocols in netmod. 
> 
> However, I think there is possibly some room for improvement for making this base Yang routing module generic enough to really be applicable to all routing protocols and use cases.  See  below for more specific questions/suggestions, generic or related to specific protocols or use cases (ECMP support, multicast, MPLS/BGP VPNs, etc.).
> 

This is quite possible, I only dared to address areas I am reasonably familiar with, which is essentially standard IP routing and some MPLS.

> 
> It is also important to note that the usefulness of these specs is conditioned (a) by the development of Yang modules for each relevant routing protocol (which should be fairly doable assuming this base module is generic enough) and (b) conditioned by the development of additional Yang modules allowing the description of non-trivial import/export filters between routing protocols and routing tables (this part being possibly harder to achieve, since it means finding a common language able to express the variety of ACLs/policies that can be expressed on different router OSes today).
> 

Absolutely. This is a usual dilemma: we can either try to develop a full-fledged route filtering framework and expect/force everybody to use it, or open the space for multiple competing frameworks. The draft and the routing module take the latter approach, because the logics of existing implementations differ from each other considerably, so it is not very likely to find their common denominator. I plan to implement the route filtering framework of the BIRD routing daemon which it is maintained by my company.

> 
> Comments:
> 
> --- Note Well ...
> 
> I'm hoping this review will be relevant and useful. But, keeping in mind that doing this review was my first exposure at Yang, some comments I'm making could possibly be completely off track, and what I think I understood could as well be, partly or fully, wrong. If/when this happens to be the case, I apologize; just be frank and honest and eventually tell me to go back home and read a few other specs before I come back... ;-)

No, I don't think it is necessary. :^) Andy Bierman once described the problem we are facing here:

"The domain experts don't really know the data modeling stuff, and the data modeling experts don't really know the domain stuff."

I certainly hope we can obtain sound results through cooperation between both classes of experts.

> 
> There was one specific difficulty for doing this review: for someone lacking XPath fluency, it is hard to understand some details of the Yand modules. For instance, there is a complex condition for routing-protocol/connected-routing-tables, and it would have remained totally obscure to me without the error-message that is also provided ; the corresponding constraint was also explained in the Intro of section 4, so this particular case was ok (see more precise comment below). Beyond this example, the real issue is that I can't know if there is any other similar XPath constraint or other detail that I might have missed.
> 

RFC 6087 requires all Standards Track modules to describe the purpose of all 'must' statements in 'description'. Actually, such a description often seems superfluous if there is an 'error-message' statement. At any rate, the purpose of such statement should be reasonably clear even without deciphering the XPath expressions. Please let me know if it is not the case and I will try to improve the descriptions and/or error messages. 

> 
> -- Document organization
> 
> The interface parameters for IPv6 Neighbor Discovery would I think deserve being moved in a companion Yang module, unless there is a strong reason (such as a dependency) why it would be needed to be kept here.

Other IPv6 ND parameters are defined by the "ietf-ip" module. It may indeed be worth reconsidering the structure of the "core" modules.
  
> 
> 
> --- Extensibility
> 
> It seems to me that these specs where written with extensibility in mind, which is a very positive point. One routing protocol example is given (RIP), but the structure is supposedly applicable to other routing protocols. You will find below a few questions related to the genericness, in fact mostly cases that may show that the current specs may not be generic enough with suggestions on possible fixes.
> 
> 
> --- Completeness
> 
> One question is how these Yang modules can be used today. It is clear that without companion specs for specific protocols and filters, not very much can be done with it (merely static routing with only trivial accept-all / deny-all filters). It is perfectly acknowledged in the document.  One part that may prove hard to achieve is the unification of the variety of ACL/policies existing on different routing equipment vendors OSes, into one common Yang language for routing filters.

Right. When we were preparing the current NETMOD charter, I actually proposed to include a route filtering framework but the WG consensus then was not to do so. As a proof of concept covering both routing protocols and route filtering, I will try to develop a complete data model for BIRD.
 
> 
> 
> ---  Information on routes
> 
> The Yang module let's the operator read the routing tables. It looks like a very valid and useful thing (and not new, see RFC1213 MIB). 
> 
> However, I'm wondering about the following points:
> 
> - usually, a routing table may have multiple routes for a said destination address, some being possibly less specific than others, or inactive due to various reasons : it did not identify how these specification allow the operator to see all routes of a routing table for a said prefix, or all the most specific routes including the inactive ones, or all the most specific actives routes when there is more than one (required I think for ECMP support), etc. ? it seems it would be worth to extend the get-route RPC to allow expressing all these kind of questions

The 'get-route' method doesn't try to be terribly general or extensible, it is mainly intended as a reminder to routing experts that YANG also allows for defining new RPC methods. I think it will be easier to decide what methods are needed as soon as there are data models for the major routing protocols, such as OSPF or BGP.   

> 
> - when dumping a full routing table, will this be efficient ? wouldn't it be more efficient to rely on other dedicated mechanism already used today to get knowledge of a routing protocol (e.g. BCP or Route Reflection for BGP, or IGP tapping techniques for IGPs)

RPC methods doing such things should be defined as a part of data models for routing protocols. With a route filtering framework, one could also set up an extra routing table and feed it with an appropriately filtered selection of routes.
 
> 
> - assuming that in some cases dumping whole routing tables would not be efficient, will there be an efficient way to get aggregate information on a routing table ; such as "how many routes in the routing table" ? or "how many inactive routes in the routing table" ?  "how many routes for prefix x.y.z" ?

Yup, this sounds like a useful thing to have. Perhaps it might make sense to also have a generic RPC returning the number of entries in a list or leaf-list.

> 
> - the term "destination-address" chosen to designate the piece of information based on which the get-route RPC works, is possibly not suitable for all routing protocols. The examples that I would see are (a) MP-BGP, where the routing information (NLRI) can be mostly anything (depends on the SAFI), and (b) multicast, where the routing information on which the PIM protocols work can be a (source,group) tuple, possibly augmented with flags

Yes, see above. Do you have an idea how to define a general method without having the data models for MP-BGP or multicast routing?

> 
> - (related to the previous point:) : I'm unclear if these specs allow a get-route to match on different portions or attributes of a routes  (eg. get route for prefix X advertised by peer X, or having been readvertised by AS Y...)... As I understand, there can be some AFN/SAFI specific extensions, but no per-protocol extensions. Is this a correct understanding ? If not, wouldn't it make sense to make it more extensible ?

There can be per-protocol extensions, too, it is also demonstrated in the RIP example.

> 
> - why restrict the get-route RPC to only query the special/default "FIB" routing table ? it would seem useful to be able to query any routing table.

This could be done but it would bring new issues to consider - multiple candidate routes etc. The 'get-route' method is supposed to answer the simple question: "Which route will be used for forwarding packets to destination W.X.Y.Z?"
  
> 
> 
> 
> --- Redistributing routes directly between routing protocols
> 
> These specifications only allow the exchange of routes from a routing protocol or routing table to a routing table, but not from a routing protocol to another routing protocols. However, the latter is something used a lot in practice (e.g. controlling redistribution between two IGP areas). Of course, by using an intermediate routing table you could achieve the same result, but doesn't it look like extra overhead ?

Some implementations (IOS, for example) redistribute routes between protocols while others (JUNOS, BIRD) use an intermediate routing table. But as you say, the former approach may be emulated with the latter. In the most typical case when two protocols are connected to the same (e.g. main) routing table, each protocol can use a filter to pull the routes originating from the other protocol.
 
> 
> 
> --- Modify routes being redistributed
> 
> There does not seem to be any way through which a route may be modified/augmented by a filter when exported from a routing table or protocol to another. It seems to me that this is something that is used a lot in practice.

Of course, this is just another task for the future route filtering framework(s).

> 
> 
> --- Multiple routing instances
> 
> The specs are written so as to allow multiple "routers" to co-exist on an equipment in isolation, which looks very useful.  However, I'm wondering if such an ability is specific to "routing", or if it shouldn't be part of a more generic Yang module, so as to reuse the same sub-router hierarchy for routing and other Yang modules.

OK, so you mean virtualization of the entire device, be it a router or anything else. AFAIK, this hasn't been discussed by the WG yet.

> 
> 
> ---  Applicability to RFC4364
> 
> Allowing multiple "routers" is a good starting point for using these specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I understand correctly Yang syntax, the way the filters are defined would not work in the context of RFC4364, where a BGP routing instance in the master "router" exports selected routes in each of the routing table of each VPN (VRF).  The VRF also export routes to the master instance.

The draft says: "Although it it not enforced by the data model, different router instances normally do not internally share any data." So this may be a use case for sharing data among different router instances. There is nothing in the data model (or YANG) preventing this. I will also relax the cited sentence, in the following sense: "Implementations may specify the rules for sharing data among router instances."

> 
> The two obstacles I would see (I might be wrong) are the following:
> - no way to modify routes while they are imported/exported : the RFC4364 use-case would require the ability to (at least) add/strip attributes to/from the routes

Each import/export is subject to a route filter, which should be able to perform such manipulations.

> - no way to redistribute routes between routing tables of different "routers" (what let me think this constraint exists is (a) the inability to name a router when designating a routing-table to import/export from/to, and (b) the XPaths for connected-routing-tables/routing-table/name and recipient-routing-tables recipient-name, which seems to not be able to point higher in the hierarchy than the 'router' on which they are defined )

True, the connected routing table currently must be within the same router instance. So this constraint should be removed, and implementations that need such an isolation will have to state it explicitly.

> - the constraint that for a said routing protocols "For each AFN/SAFI pair there may be at most one connected routing table." . In the RFC4364 case, the global BGP routing process would push routes to multiple VRFs.

This is most likely not a problem because any number of recipient routing tables can be configured to receive (filtered) routes from the single routing table which is connected to a routing protocol, cf. the "recipient-routing-tables" list.
  
> 
> 
> --- Enabling/disabling an interface
> 
> Something done very often on a router consists in putting an interface "shutdown" or "inactive", preserving its configuration but making it ignored by the router and keeping the link down.  These specifications don't seem to provide this.  Is this something already, or expected to be, provided by another Yang extension ?

The "ietf-interfaces" module has this "enabled" switch, that will server this purpose. We are also discussing where to put the "is-router" toggle that enables/disables forwarding on an interface.

> 
> If so, how would the two interact, if for instance, an interface is shutdown in this other module but used in the routing module ?

Good point, this has to be specified in the draft.

> 
> 
> --- Enabling/Disabling a protocol on an interface, or modifying protocol per-interface parameters
> 
> Something done very often on a router consists in enabling/disabling a said protocol on a said interface, or more generally modifying parameters for a said protocol on a said interface (typical example being the metric).  As I understand this would be allowed by these specs by having a module extending protocol X augment routing/router/interface with its own parameters.  However, I'm wondering if these per-protocol per-interface parameters wouldn't be better placed under each routing/router/routing-protocol[X].

It is up to the designer of the protocol data model, both options are possible. Maybe we should give some guidelines.
 
> 
> The reasons I see are the following:
> * in some cases a said router may run multiple instances of a said protocol type, in parallel, and you may need to have a way to differentiate enabling instance A of protocol X from instance B of protocol X
> * you could even find use cases where a multiple instances of a said protocol type run in parallel on a said interface (eg. multi instance ISIS)
> * my understanding of the Yang module is that the current structure would not allow augmenting a said interface multiple times for a same parameter of a said protocol type.

If something like this is necessary, one can augment an interface configuration with a list where each entry corresponds to one instance of the routing protocol.

> 
> 
> --- Editorial aspects...
> 
> Although it's not the primary purpose of this review, I have to mention that the editorial quality of the document is excellent ; I have particularly appreciated the HTML-rendered version produced by the XML RFC editing toolchain.

Thank you.

Best regards, Lada

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