Subject: Re: [netmod] draft-ietf-netmod-routing-cfg-06

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 13 Jan 2013 18:37:51 +0100

Hi Muthu,

thank you for reviewing the draft, please see my responses inline. I am also sending it to the NETMOD mailing list so that other people can comment the issues.

"Muthumayan Madhayyan (muthu)" <[email-masked]> writes:

> Hello Lada,
>
> I am reviewing this draft with an intent to see if this can be augmented for specific routing protocols and such.

That would indeed be an important work!

>
> However, the terminology:
>
>  main-routing-table, connected-routing-table, additional-routing-table and routing-table is confusing.

What we learnt in the process about terminology was that some terms, such as FIB, RIB, routing table a forwarding table, are used by different vendors in different ways, and IETF standards sometimes use the same terms with yet another meaning. See for example this thread:

http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html

It seems that using terms that look familiar but aren't understood in the same way makes the confusion even worse, so I tried to use other terms that don't bear such connotations.

In any case, additional routing table is not a technical term, it is just used in Figure 2 to illustrate the fact that there may be multiple routing tables.
 
>
> Correct me if my understanding is off base here:
>
>   *   To start with all tables are scoped to a specific afi/safi.

Yes.

>   *   Connected-routing-table is really protocol-routes-table (meaning it is populated by individual routing protocols). There is a connected-routing-table per AFI/SAFI per protocol per router instance.

Yes, but multiple protocols may be connected to the same table, so the term protocol-routes-table would be misleading, in my opinion. Structures that are specific to a particular protocol instance, such as the link-state database, should be addressed by the (future) routing protocol module.

>   *   Main-routing-table  is the final routing table per router instance that consolidates input from all connected-routing-table and creates routes based on some filters and other metrics.

What distiguishes main routing tables from the other routing tables is that the main routing tables always receive the direct routes. Other than that, it is up to an implementation to define the role of each routing table. A simple implementation will have just one routing table (per address family) which will be the main routing table and also all protocol instances will be connected to it. 

>   *   Routing-table-list is simply a listing of all connected-routing-tables and main-routing-tables across ALL router instances.

A flexible routing system may allow for user-defined routing tables that are (by definition) not main routing tables and no protocol is connected to them. Such routing tables may still receive routes from some routing tables and provide routes to others, subject to filters.

>   *   Additional-routing-table is used in the figure, but is not reference anywhere else.

The draft clearly states that the figure is only an example. As I said above, "additional routing table" has no special meaning, it just shows that tere can be more than one routing table.

>
> Can the connected-routing-table be simply called protocol-routes-table ?   There is a concept of connected routes which is equivalent to 'direct' routes in your draft.  So, at first connected-routing-table was a bit confusing to me.

I think the term "connected route" is not correct because such a route is not connected to anything - it is a route to a directly connected network. Also, protocol-routes-table doesn't seem appropriate because the fact that a routing table is connected to a protocol instance doesn't mean that it is reserved for that protocol instance. As I said, the same routing table can be connected to multiple protocol instances.  

>
> Also if the figure can be changed to show the protocol-routes-table and remove references to the 'additional-routing-table' that would be clearer.
>
> There are two 'filters' defined here:
>
>   *   One pair between the connected-routing-table and the routing-protocol
>   *   One pair between source and recipient routing tables.
>
> Currently both of them refer to the same reference - route-filter-ref.  Wouldn't it help to keep them as two different identities ?
>

Each node of the route-filter-ref type can refer to a different entry in the route-filter list, so I think it is general enough.
 
>
> One final question:
>
> All routing-tables are 'global'  meaning it should be possible for a routing table in one router instance to designate the main-routing-table of a different router instance as the recipient routing table. Is that assumption correct ?

In principle, yes, but the draft says in sec. 4.3 that implementations may specify additional business rules, and one that is specifically mentioned there is that router instances may not be allowed to share routing tables.

Thanks, Lada

> Thanks,
> - muthu

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

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Mon, 14 Jan 2013 06:05:59 +0000

Any ideas on how to achieve route export between VRF and global route
tables ?

I was hoping to model VRF as a router instance - have multiple protocols
and connected-routing-tables and main-routing-table defined under that
router instance.  

With the restrictions of 4.3, seems like that is not permitted. Any other
alternatives ?

Thanks,
- muthu

On 1/13/13 9:37 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Hi Muthu,
>
>thank you for reviewing the draft, please see my responses inline. I am
>also sending it to the NETMOD mailing list so that other people can
>comment the issues.
>
>> I am reviewing this draft with an intent to see if this can be
>>augmented for specific routing protocols and such.
>
>What we learnt in the process about terminology was that some terms, such
>as FIB, RIB, routing table a forwarding table, are used by different
>vendors in different ways, and IETF standards sometimes use the same
>terms with yet another meaning. See for example this thread:
>
>It seems that using terms that look familiar but aren't understood in the
>same way makes the confusion even worse, so I tried to use other terms
>that don't bear such connotations.
>
>In any case, additional routing table is not a technical term, it is just
>used in Figure 2 to illustrate the fact that there may be multiple
>routing tables.
> 
>>
>>   *   Connected-routing-table is really protocol-routes-table (meaning
>>it is populated by individual routing protocols). There is a
>>connected-routing-table per AFI/SAFI per protocol per router instance.
>
>Yes, but multiple protocols may be connected to the same table, so the
>term protocol-routes-table would be misleading, in my opinion. Structures
>that are specific to a particular protocol instance, such as the
>link-state database, should be addressed by the (future) routing protocol
>module.
>
>>   *   Main-routing-table  is the final routing table per router
>>instance that consolidates input from all connected-routing-table and
>>creates routes based on some filters and other metrics.
>
>What distiguishes main routing tables from the other routing tables is
>that the main routing tables always receive the direct routes. Other than
>that, it is up to an implementation to define the role of each routing
>table. A simple implementation will have just one routing table (per
>address family) which will be the main routing table and also all
>protocol instances will be connected to it.
>
>>   *   Routing-table-list is simply a listing of all
>>connected-routing-tables and main-routing-tables across ALL router
>>instances.
>
>A flexible routing system may allow for user-defined routing tables that
>are (by definition) not main routing tables and no protocol is connected
>to them. Such routing tables may still receive routes from some routing
>tables and provide routes to others, subject to filters.
>
>The draft clearly states that the figure is only an example. As I said
>above, "additional routing table" has no special meaning, it just shows
>that tere can be more than one routing table.
>
>>
>> Can the connected-routing-table be simply called protocol-routes-table
>>?   There is a concept of connected routes which is equivalent to
>>'direct' routes in your draft.  So, at first connected-routing-table was
>>a bit confusing to me.
>
>I think the term "connected route" is not correct because such a route is
>not connected to anything - it is a route to a directly connected
>network. Also, protocol-routes-table doesn't seem appropriate because the
>fact that a routing table is connected to a protocol instance doesn't
>mean that it is reserved for that protocol instance. As I said, the same
>routing table can be connected to multiple protocol instances.
>
>>
>> Also if the figure can be changed to show the protocol-routes-table and
>>remove references to the 'additional-routing-table' that would be
>>clearer.
>>
>> Currently both of them refer to the same reference - route-filter-ref.
>>Wouldn't it help to keep them as two different identities ?
>>
>
>Each node of the route-filter-ref type can refer to a different entry in
>the route-filter list, so I think it is general enough.
> 
>>
>> One final question:
>>
>> All routing-tables are 'global'  meaning it should be possible for a
>>routing table in one router instance to designate the main-routing-table
>>of a different router instance as the recipient routing table. Is that
>>assumption correct ?
>
>In principle, yes, but the draft says in sec. 4.3 that implementations
>may specify additional business rules, and one that is specifically
>mentioned there is that router instances may not be allowed to share
>routing tables.
>
>Thanks, Lada
>
>>
>>
>> Thanks,
>> - muthu
>>
>
>--

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Jan 2013 09:24:52 +0100

> and connected-routing-tables and main-routing-table defined under that

This should be possible. In fact, in earlier revisions of the draft each router instance had its private set of routing tables, and we changed this so that VRFs can exchange routes with the master instance on a PE router.

> With the restrictions of 4.3, seems like that is not permitted. Any other

Oh, this is a misunderstanding. Sec. 4.3 says: "Some implementations MAY pose restrictions …" and examples of typical restrictions are given. This means that by default router instances may arbitrarily share routing tables and it is up to an implementation to specify the exact rules. In the case of MPLS/BGP VPNs, for example, the rules would state constraints for the exchange of routes between different VRFs and between each VRF and the master instance.

In another implementation, router instances may represent independent logical routers, and then each routing table will be private to a single router instance.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Jan 2013 09:37:51 +0100

>   *   Connected-routing-table is really protocol-routes-table (meaning it is populated by individual routing protocols). There is a connected-routing-table per AFI/SAFI per protocol per router inst…

If an implementation requires a separate routing table for each protocol instance, it is also easy to do: The main routing table will only receive direct routes, and each protocol instance will be connected to its own routing table. Then, "route pipes" between pairs of these protocol routing tables can be established via the recipient-routing-table configuration. IMO, this is how the Cisco IOS notion of redistributing routes between routing protocols can be implemented.

Lada

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Mon, 14 Jan 2013 16:43:17 +0000

On 1/14/13 12:24 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Oh, this is a misunderstanding. Sec. 4.3 says: "Some implementations MAY
>pose restrictions Š" and examples of typical restrictions are given. This
>means that by default router instances may arbitrarily share routing
>tables and it is up to an implementation to specify the exact rules. In
>the case of MPLS/BGP VPNs, for example, the rules would state constraints
>for the exchange of routes between different VRFs and between each VRF
>and the master instance.
>
>In another implementation, router instances may represent independent
>logical routers, and then each routing table will be private to a single
>router instance.

OK. Thanks for the clarification. THis keeps it flexible.