Subject: [netmod] ietf-routing-cfg

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Mon, 9 Jul 2012 17:21:30 +0000

I know there has been a lot of back-and-forth in the past over whether or not to have a more simplistic routing configuration YANG model, but as I'm looking at the ietf-routing-cfg model, I think it would be useful to have the whole concept of transferring routes between tables hidden behind an if-feature.

Looking at how I would implement this for our products, which do not support any dynamic routing protocols, but do have many different interfaces that might need routing capabilities, I would leave out:
                - route-filters
                - recipient-routing-tables
                - connected-routing-tables
I think the model as it stands is perfectly usable without those additional items for the simple static and direct route use cases.

Without having this disabled via a feature, I would simply reject any attempts to set those items, but this clearly isn't the best solution.

-Jeff Lange

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Jul 2012 11:58:23 +0200

> Without having this disabled via a feature, I would simply reject any attempts to set those items, but this clearly isn't the best solution.

The draft allows implementations to restrict the number of routing tables to just one per address family, and with one table and static routing there isn't really much to do, because the only valid recipient/connected routing table can be the same main routing table, so configuring them has no effect. 

As for filters, the only sensible thing that can be done is to block all configured static routes from appearing in the main routing table, which might occassionaly be useful (and easy to implement).

An implementation that is not willing to implement even this trivial filtering may declare a deviation.

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

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

---

From: "Lange, Jeffrey K (GE Energy)" <[email-masked]>
Date: Tue, 10 Jul 2012 13:44:42 +0000

> The draft allows implementations to restrict the number of routing tables to just one per address family, and with one table and static routing there isn't really much to do, because > the only valid recipient/connected routing table can be the same main routing table, so configuring them has no effect. 
> 

I'm trying to understand how the connected-routing-tables would work in a simple real-world case.  The description of connected-routing-tables in the YANG model states:

                 If no connected routing table is defined for an
                 address family, the routing protocol should be
                 connected by default to the main routing table for
                 that address family.

But connected-routing-tables is a child-node of routing-protocol, which is not related at all to an address-family.  Only the routing-table container defines an address-family (uses afn-safi).

Is this description wrong? Or am I just missing something?

-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Jul 2012 16:05:55 +0200

> But connected-routing-tables is a child-node of routing-protocol, which is not related at all to an address-family.  Only the routing-table container defines an address-family (uses afn-safi).

This is because one protocol instance can be used for several address families. The idea is that for every such address family either (i) a routing table is explicitly configured as the connected routing table, or (ii) the main routing table for that address family is used. The formidable 'must' expression under "connected-routing-tables/routing-table" ensures that no more than one connected routing table is configured for each address family.

In other words, the list "connected-routing-tables/routing-table" may contain an entry for each address family supported by the routing protocol instance, and for missing entries the main routing table is used by default.

> Is this description wrong? Or am I just missing something?

I think it is correct but maybe not clear enough. Can you suggest a better formulation?

Thanks, Lada