Subject: Re: [netmod] RTG DIR <Early> Review of http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-00

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 May 2011 18:20:44 +0200

Hello Eric,

thanks for your thorough review, my replies and comments are inline.

On May 20, 2011, at 8:26 PM, Eric Gray wrote:

> Authors,
>  
> There's probably boiler-plate for this review, somewhere.  Assume I found it, put
> it here and you read it.
>  
> In general: it looks to me as if the intention with this draft may be to provide a
> data model that is good enough for static route configuration, but with enough
> flexibility to support more complex management of dynamic routing and routing
> protocols.

Yes, that was the intention.

>  
> I get the sense that this is the case because - while the parameters defined in this
> draft at present seem adequate to support configuration of static routes, there are
> a lot of holes that would need to be filled to support anything more complicated.

Right. It would also be possible to put static routing in a separate module, but I thought static routing was so ubiquitous that every implementation would need it.

>  
> You include an example for RIP in an appendix, probably intended to be illustrative
> rather than definitive.  Is that correct?

Yes, and this is clearly stated in the first paragraph of Appendix A.

>  
> If this is the case, this should be made clearer in the abstract.  This would also
> help in understanding the objectives.

As it is just an example, it is IMO not worth mentioning in the abstract. In fact, as soon as there is a real module for any routing protocol, this appendix could be removed.

>  
> Also, in general, I found this draft to be very well written.
>  
> Section 2 (Terminology and Notation):
>  
> I am not certain that I would call what RFC 4741 does with respect to the terms
> "client" and "server" (at least) as "defining" them.  It uses these terms extensively,
> and the introduction provides a brief description of both.  The situation is worse for
> the terms "message" and "operation" - because these are generic terms that are
> not even described generically (messages are defined, as are operations, but not
> the generic terms, and certainly not the terms "message" and "operation").

In this case I just followed the suit of other documents of the NETMOD WG, such as RFC 6087.

>  
> I suspect that what the author(s) mean is that these terms are meant to be used
> as they are used in RFC 4741.

That's right, but a reader should certainly have no doubts about their meaning. 

>  
> There appears to be a mix for terms listed as "defined" in RFC 6020.  Most terms
> are actually defined in RFC 6020 ("augment", "configuration data", "data model",
> "data node", "data type", etc.)  while others are not ("identity", "mandatory node",
> etc.).  In many cases, the terms are either described in detail (e.g. "mandatory
> node"), or there is an implicit definition ("identifier" is defined, but "identity" is not).

I guess it depends on what you call a definition. My original background is math, so I do see your point, but I have no problem accepting Sec. 3.1 in RFC 6020 as the definition of the term "mandatory node".

> Also, in at least one case, the usage is clear but I cannot determine that there is
> a "definition" per se (e.g. - "prefix").
>  
> When stating that the terms are "defined" in another document, the author needs
> to consider who may be a reader.  Either the reader will be familar with the terms
> as used in these other documents (and will not have to look them up), or they will
> expect to find actual explicit definitions in these other documents.
>  
> Since the documents referred to are published, it would not hurt to explicitly repeat
> the definitions in this draft.

It's possible, but the same would be needed to be done in other documents as well. I would prefer to have concise and authoritative definitions in one place.

>  
> Section 3 (Objectives)
>  
> It is not clear what usefulness there is in the expression "On the other hand" (third
> bullet, first paragraph).  Also, with this bullet, it is very unclear what objective is

It means that simple things should be done in a simple way but complex things should also be possible.
 
> meant to be addressed by "complicated setups invoving multiple routing tables and
> multiple routing protocols" - this makes me nervous, because this is sufficiently
> inclusive that it could very likely be meant to include implementation-specific stuff.
> I suspect that what it is meant to describe is simpler - for example - describing a
> set of rules for resolving conflicting route information.

At the end of the day, implementors will be encouraged to publish even their proprietary knobs, bells and whistles as YANG modules. This should not make you or anybody nervous because the proprietary stuff cannot be avoided, and it is IMO better if it is published.
 
>  
> The fourth bullet is written in a relatively loose way, starting with a justification and
> then listing the objective.  I suggest a clean listing of objectives should be separate
> from justifications for any of them.

OK, I agree.

>  
> Section 3 and 4 (Design of the Core Routing Data Model) both use the term "setup"
> in a way that does not seem clear to me.  Is this term meant to be synonymous
> with "configuration"?  Is there a reason to use "setup" instead of what it means, or
> should we include a definition for what is meant by "setup"?

The term "configuration" has a more specific meaning in NETCONF/NETMOD circles, the word "setup" is intended to mean "organization of a routing subsystem".
  
>  
> (By the way, there is no information content in a leading "The" in a section title.)

Which section title do you mean, I don't see any leading "The" in the titles of Sec. 3 or 4. (Nevertheless, I am ready to admit that my use of English articles is far from perfect because my native language - Czech - has no such beast.)
 
>  
> The example in Figure 1 is probably not typical.  For example, implementers will
> not usually have the concept of a "main routing table" and "additional routing table"
> (or "tables") but will have tables comprising input to a function meant to resolve
> discrepancies and combine inputs (thus resulting in a combined routing table). It
> seems likely that this is an isomorphism of what you show, but it also seems (to
> me) like this example may engender more confusion that it helps to eliminate. 
> In many implementations I've seen, static routes (for example) are just another set
> of inputs (typically with the highest resolution priority, or preemptive rules).

In the routing configuration languages I have used in the past, this seems a plausible setup, though by no means the only one. The present design also has to do with the distinction between configuration and operational state data - routing tables belong to the latter category.

>  
> Minimally, I would change "the routing subsystem" to "a routing subsystem" in
> the figure caption.

OK.

>  
> Section 4.3 (Routing Protocol Instances):
>  
> The model in this section implied by the text in the second paragraph seems to be
> implementation specific.  In at least a few implementations this is inconsistent with
> how the implementations actually work.  For example, implementations may have
> a single routing (or route) table with the input to a filtering function from each of a
> number of different routing protocols.  Storage of routing protocol information may
> or may not be in some form that can be logically represented as a separate table,
> and will very likely include a considerable amount of protocol-relevant additional
> information.

I believe all this is still possible. For example, all routing protocols may be connected to the same routing table. Do you have a particular implementation in mind which cannot be represented using the framework of the draft? Note that routing protocols may store other information apart from routing tables, both as configuration and operational state data. 

>  
> Also, the filtering described in the bullets of the fourth paragraph implies what may
> be a messy mechanism for determining which of several routing inputs is used in
> constructing a set of route table entries.  If you were - for example - required to
> describe route-input by route-input which one would be accepted or rejected, this
> information might be harder to maintain than the separate route tables.  Also, I
> strongly suspect that the filters would need to be defined pair-wise for all pairs of
> routing protocols in use (i.e. if RP1, RP2, RP3 and RP4 are in use, there would
> need to be a set of filters for each pair {RP1:RP2}, {RP1:RP3}, {RP1:RP4}, etc.)
> and this too could get messy.

This very much depends on the number of routing tables in use. Essentially, any structure of interconnected routing tables with filtering functions attached to any connection should be possible. Various implementations differ in their configuration logic, so it is quite likely that some will be a better fit for the generic framework than others.
 
>  
> Section 7 (IANA Considerations):
>  
> Are the two namespace URIs already allocated (using the early allocation process),
> or are we simply assuming these values will be allocated?
>  
> Same question for YANG modules.

My understanding is that these allocations are performed quite late in the document life cycle, just before it is published as an RFC.
  
>  
> Section 8 (Security Considerations):
>  
> I suspect that there is text you can import for this section from other extensions to
> YANG.  The idea should be that configuration operations usually need to be verified
> and authenticated.

Yes, that would be useful, but no such text exists, AFAIK.

>  
> I didn't review the Appendix, or much of the actual modules elsewhere in the draft.
> I assume there is some tool to verify that the text has the right number of opens
> and closes and is other wise syntactically correct and that these tools will be used
> prior to publication of this draft.

Yes, the modules and XML instance documents were validated with pyang tools.

Thanks again, Lada

>  
> Thanks!
> --
> Eric Gray
>  
> PS: if the boiler-plate is supposed to include some closing remarks, pretend I
> put that here, and you read it...

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C