Subject: [netmod] review of draft-ietf-netmod-routing-cfg-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Jun 2012 15:49:39 +0200

I have reviewed draft-ietf-netmod-routing-cfg-03 and here are my
comments/questions.

a) p1: The abstract reads:

   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring a routing subsystem.  It is therefore
   expected that this module will be augmented by additional YANG
   modules defining data models for individual routing protocols and
   other related functions. [...]

   It is unclear that "this module" in the fourth line refers to. Do
   you mean "these modules"? Or are you referring only to the core
   module? In this case, be explicit.

b) p3: s/ etc//

c) p8: According to the figure, both the outgoing-interface and the
       next-hop are optional. Is this by intention?

d) p10: s/.[YANG-IF]./ [YANG-IF]./

e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)?

f) p14: s/and fit it into/and it has to fit into/

g) p18: s/real route filtering/more flexible route filtering/

h) p19: Is "missing-element" the right error-tag? If a router with the
        requested name does not exist, then it is not a missing
        element in the XML sense. Is this perhaps "data-missing"?

i) p20: s/also depends on several/also depend on several/

j) p24: I think the note below should be removed. Such a note may make
        sense where the identity is used but not as part of the identity
	definition itself. (And I noted that the text where this is used
	actually says something slightly different.)

     identity allow-all-route-filter {
       base route-filter;
       description
         "Route filter that permits all routes.

          Note that use of this filter is equivalent to no filter at
          all.
         ";
     }

k) p27: Is it useful to hardwire the router-id to be an IPv4 address?

l) p36/p45: The route list is indexed by seqno, which is a "sequential
            number of the route". What does this mean? Do I have to do
            a major renumbering just to insert a route? Why not using
            "dest-prefix next-hop" as a key and eliminating seqno or
	    something like that?

m) p40: s/name] "/name]"/ ?

n) p41: s/from the interface/to the interface/ ?

o) There are these dynamic defaults in the RA config and I am
   wondering what this really means. Do the defaults change
   dynamically when I change max-rtr-adv-interval? Or are they
   calculated only onces? How does this interact with the many ways of
   dealing with defaults in NETCONF?

p) p44: I do not understand how valid-lifetime and preferred-lifetime
        would work given that implementations may use the value to
        refer to absolute point in time or a fixed interval. In fact,
        to configure a fixed point in time, I would prefer to
        configure a date-and-time value. I think this needs to be
	broken into separate objects.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 13:13:10 +0200

Hi Juergen,

thanks for the review. My replies are inline.

>    module? In this case, be explicit.

It should read "these modules".

> b) p3: s/ etc//

Removed.

>        next-hop are optional. Is this by intention?

One of them must be present, or both. So none of them is mandatory, nor is it a choice.

Damn, I now realized I had not properly updated the tree in Fig. 1. The "route" subtree should be:

+--ro route
   +--ro outgoing-interface?
   +--ro source-protocol
   +--ro age
   +--ro v4ur:dest-prefix?
   +--ro v4ur:next-hop?
   +--ro v6ur:dest-prefix?
   +--ro v6ur:next-hop?

> d) p10: s/.[YANG-IF]./ [YANG-IF]./

Fixed.

> e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)?

RA-based DNS configuration is optional so I think it needn't be done here. This is different from the basic RAs - RFC 4861 states in sec. 6.2.1: "A router MUST allow for the following conceptual variables to be configured by system management."

> f) p14: s/and fit it into/and it has to fit into/

OK.

> g) p18: s/real route filtering/more flexible route filtering/

Or perhaps "more comprehensive"?

>         element in the XML sense. Is this perhaps "data-missing"?

I wasn't sure here. So "missing-element" would be used only if an element is missing that is mandatory according to the schema?

> i) p20: s/also depends on several/also depend on several/

Fixed.

>           Note that use of this filter is equivalent to no filter at

I removed the note from the identity description and placed it to the I-D text (sec. 4.5).
 
> k) p27: Is it useful to hardwire the router-id to be an IPv4 address?

I think this is how it currently works - even IPv6 routers use an IPv4 dotted quad notation. Routing protocols that do not want to use this global-id can define a specific id which can be anything.

>             "dest-prefix next-hop" as a key and eliminating seqno or

It would be too limiting to require that "dest-prefix next-hop" be unique. Thing is, 
there is no natural key to be used here and the list can be very long. So it could be a royal pain for the client to always have to select a unique key for each entry.

A good solution to this problem might be to leave the assignment of the key to the server - and then the sequential numbers can really be sorted in the datastore. It is how it is done in Mikrotik routers and I find it quite handy. Maybe it could become another item in the NETCONF 2.0 wishlist.

But for the time being I don't really know how to deal with this issue. Should I change the key type to an opaque string?

> m) p40: s/name] "/name]"/ ?

OK.

> n) p41: s/from the interface/to the interface/ ?

I took the description verbatim from RFC 4861 so I assume it's correct. It is about RAs sent out of the interface.

>    dealing with defaults in NETCONF?

Again, it's more a question for the authors of RFC 4861, but I assume it means that the default is calculated dynamically each time the particular (missing) value is used.

>         refer to absolute point in time or a fixed interval. In fact,

As I understand it, the meaning for the receiving node is always the same (number of seconds), the two variants differ only in the behaviour of the sending router - in the first case it sends always the same value while in the second case the value in the next RA will be decremented by the amount time elapsed after the preceding RA.

> 	broken into separate objects.

No, I think it has to remain in seconds.

Lada

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jun 2012 14:47:43 +0200

> RA-based DNS configuration is optional so I think it needn't be done here. This is different from the basic RAs - RFC 4861 states in sec. 6.2.1: "A router MUST allow for the following conceptual va…

OK, this is reasoning. But is it a reasonable thing to do?

> I wasn't sure here. So "missing-element" would be used only if an element is missing that is mandatory according to the schema?

RFC 6241 error descriptions are not super precise. My reading of

   error-tag:      missing-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the missing element
   Description:    An expected element is missing.

is that we are talking about missing XML element - but then the text
just says element. I guess NETCONF implementors should clarify what
their use of the error-tags really is.

> But for the time being I don't really know how to deal with this issue. Should I change the key type to an opaque string?

I do not know what the correct answer is. I just found it unclear what
the text implies. And I surely do not want to renumber to insert a
route.

> Again, it's more a question for the authors of RFC 4861, but I assume it means that the default is calculated dynamically each time the particular (missing) value is used.

Is used? Anybody here who can clarify the intention of RFC 4861?

> As I understand it, the meaning for the receiving node is always the same (number of seconds), the two variants differ only in the behaviour of the sending router - in the first case it sends alway…

I understand that but the point is that a single number is not telling
you whether its behaviour A or B.
 
> No, I think it has to remain in seconds.

If the intention is that the RA is valid until say 6pm today, does it
really make sense to calculate the seconds until 6pm at the time the
edit-config is sent to the box? I doubt it. I would prefer to
configure the date, that is 2012-06-11T18:00+0100 and let the box
calculate the number of seconds. This is much more robust.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 16:07:34 +0200

> OK, this is reasoning. But is it a reasonable thing to do?

Yes, I think it is reasonable to set the boundary for the core routing model between MUST and SHOULD because otherwise there would be other candidates for inclusion, e.g. IPSec.

> their use of the error-tags really is.

Agreed. Is the general feeling that "data-missing" is better for this case than "missing-element"?

> the text implies. And I surely do not want to renumber to insert a

Sure, this was not intended although the description ("sequential") seems to indicate so. Would "number of the route" be any better?

> Is used? Anybody here who can clarify the intention of RFC 4861?

The text describing these parameters in 4861 is IMO quite sloppy, and I have already submitted an erratum.

> calculate the number of seconds. This is much more robust.

The option of a constant lifetime (in seconds) must remain available, so it would require either a "union" type for these leafs (which I don't like at all) or a choice between two alternative leafs.

At any rate, all three implementations I am using as a reference (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of seconds in their configurations, and implement (I think) only the constant values.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jun 2012 17:17:33 +0200

> At any rate, all three implementations I am using as a reference (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of seconds in their configurations, and implement (I think) only the…

I personally do not mind to support only the relative time
interval. But in any case, it simply needs to be clear what the
configured number means.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 17:27:32 +0200

> interval. But in any case, it simply needs to be clear what the

An option could be to add a boolean switch for configuring the behaviour, with a default meaning the fixed lifetime.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jun 2012 17:30:18 +0200

> An option could be to add a boolean switch for configuring the behaviour, with a default meaning the fixed lifetime.

But having the seconds in config is IMHO broken if we talk about an
absolute time stamp. Is this number constantly changing? What happens
if I reload a configuration? If we do this, I think we need to do it
properly.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Jun 2012 17:43:18 +0200

> if I reload a configuration? If we do this, I think we need to do it

1. The router reads the configured value in seconds at startup or when the configuration changes, and then decrements it in real time in the consecutive RAs.

2. The router used the same (configured) value in consecutive RAs.

If a configuration is reloaded, scenario 1 will start from the original (higher) value. I guess it is just another manifestation of the difference between configuration and operational parameters.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jun 2012 17:51:39 +0200

> If a configuration is reloaded, scenario 1 will start from the original (higher) value. I guess it is just another manifestation of the difference between configuration and operational parameters.

If option 1. is as you describe, then I tend to conclude that option
1. does operationally not make much sense (and perhaps this is why it
is not commonly implemented).

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 Jun 2012 23:07:04 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > I wasn't sure here. So "missing-element" would be used only if an element is
> > missing that is mandatory according to the schema?
> 

We use 'missing-element' for missing XML elements.  6241 uses the term
'element' for XML elements (almost consistently :)

The descripton for "data-missing" is:

   Description:    Request could not be completed because the relevant
                   data model content does not exist.  For example,
                   a "delete" operation was attempted on
                   data that does not exist.

So in this case the error-tag should be "data-missing".

> > It would be too limiting to require that "dest-prefix next-hop" be
> > unique.

Why is this too limiting?

> > there is no natural key to be used here and the list can be very long. So it
> > could be a royal pain for the client to always have to select a unique key
> > for each entry.
> >
> > A good solution to this problem might be to leave the assignment of the key
> > to the server - and then the sequential numbers can really be sorted in the
> > datastore. It is how it is done in Mikrotik routers and I find it quite
> > handy. Maybe it could become another item in the NETCONF 2.0 wishlist.

I think Andy described the problem with this approach for NETCONF that
there is no way for the server to tell the client what the newly
assigned index is.

> > But for the time being I don't really know how to deal with this
> > issue. Should I change the key type to an opaque string?

Currently this list is ordered-by user, and has a key which is
described as being the "sequentional number", which seems a bit
confusing.  An opaque string is imo better.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 10:30:32 +0200

> So in this case the error-tag should be "data-missing".

OK, I will change it accordingly.

> Why is this too limiting?

Two routes having the same dest-prefix and next-hop may differ in other attributes that will be added via augmentation by other modules, e.g. for policy routing. Linux example:

# ip route add 192.0.2.0/24 tos 0x01 via 77.48.224.129
# ip route add 192.0.2.0/24 tos 0x10 via 77.48.224.129

> there is no way for the server to tell the client what the newly

Why? The client can use get-config whenever the numbering of entries is needed.

> confusing.  An opaque string is imo better.

Strings would consume more memory, which may be an issue with very long lists. And it can still be difficult for the client to determine a unique key for a new entry.

Lada