Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-04

From: "Yi Yang (yiya)" <[email-masked]>
Date: Fri, 27 Jul 2012 18:49:53 +0000

Hi Lavislav,

Here are my comments for the current draft:

1. How about to add a leaf "enabled" (default "true") under routing-protocol? Administrator may choose to temporarily disable a routing protocol instance for troubleshooting.

2. Add a leaf "isActive" under route -- The value should be true if the route is being used for forwarding. An reply to the NETCONF <get> (like the example in the appendix B) will not only give the whole routing table but also shows which routes are active.

Yi

---

From: Benoit Claise <[email-masked]>
Date: Sat, 28 Jul 2012 22:06:58 -0700

Thanks mister YANG.
Sorry Yi, I could not resist ;-)

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 29 Jul 2012 05:11:26 -0700

> 1. How about to add a leaf "enabled" (default "true") under routing-protocol? Administrator may choose to temporarily disable a routing protocol instance for troubleshooting.

Good point, this should be added.

> 2. Add a leaf "isActive" under route -- The value should be true if the route is being used for forwarding. An reply to the NETCONF <get> (like the example in the appendix B) will not only give the…

Some implementations would have hard time maintaining this flag. Implementations that use a forwarding table (where all routes are active by definition) may allow the client to inspect this table.

Moreover, in routing tables other than "main", the "isActive" flag makes no sense.

I added a new RPC method that returns the active route (or routes, in the case of multi-path routing) for a given address.

Thanks, Lada

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

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Mon, 30 Jul 2012 01:59:07 +0000

Hi Ladislav,

> Some implementations would have hard time maintaining this flag.

Actually, in practice, when a user want to show a routing table, they are expecting a list of active routes. They could get a full table with inactive routes with adding some extra key words, such as "all" or "detail", but by default, they are more interested what system is using right now. 

> Implementations that use a forwarding table (where all routes are active by definition) may allow the client to inspect this table.

Does this mandate a separated routing table? In addition, I am confused by the term "forwarding table". A forwarding table is normally referred to something different to a routing table, as the former is optimized for fast lookup. For example, it may not care about the age/source of the route.

> Moreover, in routing tables other than "main", the "isActive" flag makes no sense.

Why?

> I added a new RPC method that returns the active route (or routes, in the case of multi-path routing) for a given address.

This seems opposite to current practice. In daily operation, people are interested in the active routes in most cases, and "show detail" if they want to know more.

I have two more questions/comments about the draft.

1. If an option node is missed in the reply to the NETCONF <get> message, what does it mean? Does it mean the device doesn't not support the option node, or does it mean the device supports such a option but with a default value?

2. For the interaction between routing protocol and routing table, "routes appearing in a routing table are passed to all routing protocols connected to the table". Such a behaviors is called redistribution, which is off by default. If a routing table by default passes the routes to all routing protocols, this sounds we have to have a deny-all export filter for each  
routing protocol by default?

Yi

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 30 Jul 2012 07:27:19 -0700

> Does this mandate a separated routing table? In addition, I am confused by the term "forwarding table". A forwarding table is normally referred to something different to a routing table, as the for…

I think there is a terminology mismatch here. Let me cite from Junos documentation (http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/routing-protocols-routing-databases-overview.html#id-10137188):

<quote>
The Junos OS installs all active routes from the routing table into the forwarding table. The active routes are used to forward packets to their destinations.

The Junos OS kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the part of the router responsible for forwarding packets.
</quote>

So it seems "forwarding table" in Junos terms is "routing table" in IOS terms, because IOS only accepts active routes into the routing table based on prefix length, administrative distance and protocol-specific metrics.

But both platforms maintain this "table with active routes", and in this case I would indeed recommend to have a separate routing table playing this role (see the proposed setup at the end of my mail). So one can just use <get> on this table to obtain the active routes.

Linux, in contrast, doesn't keep this "table with active routes". Its routing table may contain routes that are clearly inactive, as in this example where two otherwise identical routes differ in the metric:

$ ip route
default via 1.2.3.129 dev eth0  metric 100
default via 1.2.3.129 dev eth0  metric 200
1.2.3.128/27 dev eth0  proto kernel  scope link  src 1.2.3.143

Linux uses a route cache, which however contains only /32 (or /128) routes. In the case of a route cache miss, a lookup in the (main) routing table must be performed.

>> Moreover, in routing tables other than "main", the "isActive" flag makes no sense.

Because all routes may be subject to one or more route filters before they reach the main routing table (or, in general, the place from which active routes are selected).

> 1. If an option node is missed in the reply to the NETCONF <get> message, what does it mean? Does it mean the device doesn't not support the option node, or does it mean the device supports such a…

If the node has a default value defined in the data model, then it means that the default value is used - see also RFC 6243.

> routing protocol by default?

I would use this setup for IOS emulation:

1. Make a separate routing table for each protocol instance.

2. Make the main routing table a recipient of the routing tables of all protocol instances, and state in the data model documentation that incoming routes are processed so that only active routes appear in the main table.

3. If you want routes from protocol A to be redistributed to protocol B, define the B routing table as a recipient routing table of A.

ASCII art:

            +---------+          +---------+
            | proto A |          | proto B |
            +---------+          +---------+
                | ^                  | ^
                v |                  v |
            +---------+          +---------+
            | table A |--------->| table B |
            +---------+          +---------+
                 |                    |
                 |   +------------+   |
                 +-->| main table |<--+
                     +------------+

Thanks, Lada

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Mon, 30 Jul 2012 19:20:56 +0000

Hi Ladiskav,

> The Junos OS kernel maintains a master copy of the forwarding table. It copies the forwarding table to the Packet Forwarding Engine, which is the part of the router responsible for forwarding packe…

I am not an expert on Junos, but here is the output of "show route forwarding-table", from http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-summary/show-route-forwarding-table-mpls-ex-series.html

user@switch> show route forwarding-table
Routing table: default.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     2 0:12:f2:21:cf:0    ucst   333     5 me0.0
default            perm     0                    rjct    36     2
0.0.0.0/32         perm     0                    dscd    34     1
2.2.2.0/24         intf     0                    rslv  1309     1 ae0.0
.......

Compared to the output of "show route", from
http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/command-summary/show-route.html

user@host> show route
inet.0: 10 destinations, 10 routes (9 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0          *[Static/5] 1w5d 20:30:29
                      Discard
10.255.245.51/32   *[Direct/0] 2w4d 13:11:14
                    > via lo0.0
172.16.0.0/12      *[Static/5] 2w4d 13:11:14
                    > to 192.168.167.254 via fxp0.0
192.168.0.0/18     *[Static/5] 1w5d 20:30:29
                    > to 192.168.167.254 via fxp0.0

As mentioned earlier, source/age are not shown in the forwarding table, unless they are hidden intentionally? Maybe someone familiar with Junos can comment on this?

> Because all routes may be subject to one or more route filters before they reach the main routing table (or, in general, the place from which active routes are selected).

What's the definition of main routing table? Previously, I was thinking the default routing table, but now it seems a superset of all the routing tables (default + VRFs) for a specific AF.

> If the node has a default value defined in the data model, then it means that the default value is used - see also RFC 6243.

In the appendix B, under <rt:router>, <rt:enabled> is not shown and it should be interpreted as router "A" supports <rt:enabled> and has a default value "true". But if router "A" doesn't support <rt:enabled> (which is an optional node), how will it reply?

Yi

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 30 Jul 2012 14:14:17 -0700

> As mentioned earlier, source/age are not shown in the forwarding table, unless they are hidden intentionally? Maybe someone familiar with Junos can comment on this?

Would it help if "age" and "source-protocol" were not mandatory?

>From the point of view of the core routing model, every implementation has to have at least one routing table per address family, which is called main. However, its role in routing/forwarding is not predetermined, so implementations can combine the components in different ways and specify additional semantics and/or restrictions.

> In the appendix B, under <rt:router>, <rt:enabled> is not shown and it should be interpreted as router "A" supports <rt:enabled> and has a default value "true". But if router "A" doesn't support <r…

It's optional in the sense that it needn't appear in a <get-config> reply. But every server implementing the "ietf-routing" module must allow the client to set this leaf to "false".

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 30 Jul 2012 13:38:38 -0700 (PDT)

Hi,

"Yi Yang (yiya)" <[email-masked]> wrote:
> >> 1. If an option node is missed in the reply to the NETCONF <get> message,
> >> what does it mean? Does it mean the device doesn't not support the option
> >> node, or does it mean the device supports such a option but with a default
> >> value?
> >> 
> > 
> > If the node has a default value defined in the data model, then it means
> > that the default value is used - see also RFC 6243.
> 
> In the appendix B, under <rt:router>, <rt:enabled> is not shown and it should
> be interpreted as router "A" supports <rt:enabled> and has a default value
> "true".

Yes.

> But if router "A" doesn't support <rt:enabled> (which is an optional
> node), how will it reply?

Note that an "optional" leaf (i.e., mandatory false) does NOT mean
that the server doesn't have to implement it.  It means that it is
optional / non-mandatory in the configuration, i.e., the user doesn't
have to give the leaf a value.

/martin

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Tue, 31 Jul 2012 01:27:53 +0000

Hi Ladislav,

> Would it help if "age" and "source-protocol" were not mandatory?

I am inclined to separate forwarding table from routing table. The forwarding table is so special that it has a different data structure, doesn't interact with routing protocol directly, and doesn't support export filters...

Yi

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 30 Jul 2012 18:45:18 -0700

On Jul 30, 2012, at 6:27 PM, Yi Yang (yiya) wrote:

> I am inclined to separate forwarding table from routing table. The forwarding table is so special that it has a different data structure, doesn't interact with routing protocol directly, and doesn't support export filters…

This is certainly an option - somebody can write such an extension as a separate module. But, as I said, some implementations do not use a forwarding table.

Lada

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Tue, 31 Jul 2012 14:29:10 +0000

Hi Ladislav,

> This is certainly an option - somebody can write such an extension as a separate module. But, as I said, some implementations do not use a forwarding table.

Or, forwarding table as an optional? 

IMO, no matter if forwarding table is specified in a separate module, or specified as an optional node, the reference of forwarding table and FIB in the draft should be clarified as they are not routing tables.

Yi