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

From: <[email-masked]>
Date: Tue, 3 Apr 2012 16:57:29 +0200

Hi Ladislav,

(a few comments below)

2012-03-23, Ladislav Lhotka:
>>
>> 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.

It would be nice to see more vendors join and propose Yang modules for 
filtering/redistribution ; even if restricted to their own filtering 
semantics, that would be a start.

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

Either way, it's sane to have some textual description.

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

I did not do a full review on this aspect yet, but if you do indeed 
apply the rule above, then I expect this will be good enough.

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

Agreed.

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

You might want to find a balance between doing things in these 
specifications and punting to future work and new extensions.

It seems to me that, at the very least, the get-rpc should allow to 
return more than one route (all active ones) so as to be compatible with 
ECMP.  Filtering between active and inactive routes would be I think 
fairly generic and relevant to add in these specs.

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

Agreed.

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

Well, the above comment was more about the term chosen than about data 
modeling. Why not just call "match-data" the piece of information in the 
routes on which the get-rpc will try to match ?

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

I understand how the RIP example does extend the information *returned* 
by get-route. But I don't get how a protocol can extend the information 
on which get-rpc matches ? For instance, can I get-route to find the 
route for which tag = 42 ? (theoretical example, I'm not saying there's 
a use for this)

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

Two things:

- there is a strong, and possibly debatable, hypothesis here: that the 
operators that relies on Netconf/Yang will use this module with as the 
only need the need to know about forwarding.

- the "multiple candidate route" issue is, I think, something that needs 
to be taken care of, even for the FIB ; if only as to take care of ECMP, 
but also for use-cases such as IPFRR (where multiple next-hops are in 
the FIB for a said prefix, some of them will become active only when a 
certain failure arise)

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

Its often better when simple things could be doable in a simple way.

What are the drawbacks of allowing routes to be exchanged directly 
between routing protocols ?

(said otherwise: not allowing direct import/export between routing 
protocols looks like an arbitrary restriction; what is the driver for 
introducing this arbitrary restriction ? is this restriction worth the 
operational cost (more work to do to do protocol-to-protocol 
redistribution, more routing table to instantiate)  ?

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

Ok, then the text in paragraph §1 of section 4.5 is good enough

     Route filters may also manipulate routes, i.e., add, delete, or modify
     their properties.

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

This is good, but not enough (see below).

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

Ok.

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

Agreed.

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

Understood, there is a way to make it work, but see discuss above, it 
seems to me as possibly useless overhead to alway need an intermediate 
routing table in such cases.

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

Ok.

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

Ok, we agree.

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

Here, again, that would work, but it doesn't look to me as the simplest 
approach.

Thanks,

-Thomas

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Apr 2012 13:10:34 +0200

On Tue, 3 Apr 2012 16:57:29 +0200, <[email-masked]> wrote:

...

> specifications and punting to future work and new extensions.

Actually, there is also the generic "get" operation in NETCONF which allows for querying state data and specifying various filters. This might be sufficient for getting information from routing tables.

On the other hand, we had a discussion with Martin Björklund in Paris whether it is reasonable to expose routing tables as state data. The downside is that if a client issues (perhaps inadvertently) a "get" without any filters, the reply may contain the full BGP table and be therefore darn long. I am not sure which alternative is better but if we decide not to expose routing tables as state data, it will indeed be necessary to replicate the functionality of "get" (including filters) for obtaining routes.
   
> return more than one route (all active ones) so as to be compatible with

Yes, this is a good point.
 
> fairly generic and relevant to add in these specs.

Hmm, but the decision is based on parameters that are not defined in the routing module - metrics, preferences etc. How can we specify the algorithm without knowing these?

Also, in Paris I got another comment related to this, namely that some implementations don't use a special forwarding table. It's true that e.g. Linux selects the active route form a routing table on the fly (and uses a route cache). So I am now considering the option of removing the forwarding table (FIB) from the spec. In that case the "get-route" would be an implementation-independent way of learning the active route(s).

...

> route for which tag = 42 ? (theoretical example, I'm not saying there's 

The "get-route" does not provide this possibility but it can be done using the generic "get" operation with subtree filters.

> only need the need to know about forwarding.

I am not sure I understand this point but I definitely assume that other (protocol-specific) means for querying the routing system will be defined in other modules.

> the FIB for a said prefix, some of them will become active only when a 

Yes, I agree.

> redistribution, more routing table to instantiate)  ?

Two reasons:

1. Allowing the exchanges between both routing tables and protocols would make the system even 
   more complicated.

2. Routing protocols will mostly be defined elsewhere, so it seems to me it is better to keep 
   their interface to the protocol-independent part as simple as possible.

And it needn't really be any more complicated: an implementation may decide to reserve a routing table exclusively for each routing instance and in this case there will be effectively no difference between the two cases. Yes, there is some overhead, but some implementations use this approach (a single routing table connected to each protocol instance) and I see no way how this can be emulated if the only option was to exchange routes between protocols.  

Client sofware can certainly let the user pretend the exchange happens between routing protocols.

...
 
> routing table in such cases.

I don't think it's a viable approach to provide all existing alternatives directly in the same data model (I am old enough to remember the original PL/1 programming language). The important point is that it is doable.

Thanks, Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Apr 2012 13:19:56 +0200

> On the other hand, we had a discussion with Martin Björklund in Paris whether it is reasonable to expose routing tables as state data. The downside is that if a client issues (perhaps inadvertently…

If NETCONF's <get> is considered unusable in practice since it can
return huge amounts of data if not used carefully, then IMHO <get>
needs to be fixed or deprecated. I think it is backwards to not model
operational state because an unfiltered <get> operation may not be a
good idea.  That said, how to best model operational state seems to
remain a somewhat unresolved issue.

/js (as contributor)

-- 
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: Tue, 10 Apr 2012 13:53:25 +0200

> good idea.  That said, how to best model operational state seems to

I agree with this.

> remain a somewhat unresolved issue.

Interestingly, from a "RESTful" point of view the distinction between configuration and state data seems largely artificial (leaving aside statistics). For a device, an IP address is a piece of data (resource) that has to be specified somehow and it doesn't matter whether it is done through manual configuration, DHCP or otherwise.

What's really relevant is a representation of device's state and a specification of the parts of the state that may be modified via NETCONF - in fact, the latter may also be an implementation-specific decision. In other words, config true or false is just a matter of access rules.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Apr 2012 14:03:35 +0200 (CEST)

> > good idea.  That said, how to best model operational state seems to

+1

> Interestingly, from a "RESTful" point of view the distinction between
> configuration and state data seems largely artificial (leaving aside
> statistics). For a device, an IP address is a piece of data (resource)
> that has to be specified somehow and it doesn't matter whether it is
> done through manual configuration, DHCP or otherwise.
> 
> What's really relevant is a representation of device's state and a
> specification of the parts of the state that may be modified via
> NETCONF - in fact, the latter may also be an implementation-specific
> decision. In other words, config true or false is just a matter of
> access rules.

I don't think I agree with this.  You can easily have two separate
resources on the device; the operationally used ip address and the
configured ip address.  Both are in this case part of the device's
"state".

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Apr 2012 14:45:02 +0200

> configured ip address.  Both are in this case part of the device's

I agree with Martin.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Apr 2012 15:12:43 +0200

> I don't think I agree with this.  You can easily have two separate

I thought you wouldn't. :-)

> configured ip address.  Both are in this case part of the device's

What it means is that you may offer a value through NETCONF but it may or may not be taken into account. So the access rule is: you are allowed to specify a value for this resource but it may not be applied. 

I see your point - there is the "true" state on the one hand and a blueprint for it submitted by NETCONF on the other. But still, I think that a representation of the device state (no matter where it comes from) is a good starting point.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Apr 2012 08:06:38 -0700

On 04/10/2012 06:12 AM, Ladislav Lhotka wrote:
>> Ladislav Lhotka<[email-masked]>  wrote:
>>>
>>>> If NETCONF's<get>  is considered unusable in practice since it can
>>>> return huge amounts of data if not used carefully, then IMHO<get>
>>>> operational state because an unfiltered<get>  operation may not be a

IMO, both <get> and <get-config> are problematic for large lists.
NMS developers have asked me many times for "iterators" in NETCONF.
Some implementations prefer to give 'startEntry' and 'maxEntries'
parameters in addition to the target object, and make N requests, instead of
getting every possible entry streamed at them in 1 request.  Sometimes
the developer just wants to discover the list instances (get just keys)
and not retrieve every sub-tree. (Filters get too complicated for this task.)

The issue is not config=true/false, but rather how to deal with retrieval
of large lists.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Apr 2012 17:58:05 +0200

> Some implementations prefer to give 'startEntry' and 'maxEntries'

But this cannot work for <get> and <get-config> since they return an XML document.
 
> and not retrieve every sub-tree. (Filters get too complicated for this task.)

This looks like a good reason for defining special methods for querying routing tables. 

> The issue is not config=true/false, but rather how to deal with retrieval

Sure, although extremely long lists, which could be real showstoppers for <get> and <get-config>, are more likely to be found in state data.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Apr 2012 09:14:25 -0700

On 04/10/2012 08:58 AM, Ladislav Lhotka wrote:
>> IMO, both<get>  and<get-config>  are problematic for large lists.
> But this cannot work for<get>  and<get-config>  since they return an XML document.
>

They just use the <data> top-element and return data as usual.
I agree a new operation would probably be needed for this functionality.

> This looks like a good reason for defining special methods for querying routing tables.

yes -- I think several vendors are not using config=false, but are instead
defining RPC 'show' commands to sort of mirror the CLI.  I think NMS developers
realize it will be awhile before the CLI way of doing things is not tightly
coupled to the programmatic API.  Since YANG has the 'rpc-stmt', it doesn't
matter that much which way it's done.

> Sure, although extremely long lists, which could be real showstoppers for<get>  and<get-config>, are more likely to be found in state data.
>

I think even this data model will have large config=true lists on some implementations.

The issue is the size of the XML document returned in the <rpc-reply>.
Some applications would prefer to keep that to a reasonable size.
Maybe it's just an implementation detail, but that's what developers think about.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Apr 2012 22:22:13 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> getting every possible entry streamed at them in 1 request.

Agreed.

> Sometimes

We use subtree filters for this; it is pretty trivial to construct
such a filter.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Mon, 16 Apr 2012 15:31:54 -0700

> and not retrieve every sub-tree. (Filters get too complicated for this task.)

Wouldn't Xpath filters support this case?