Subject: [netmod] host routing

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 May 2012 11:59:11 +0200

Hi,

the -03 version of ip-cfg refers in sec. 2 to the routing-cfg draft regarding configuration of IP routing. This means that any device that does IP routing (which is pretty much every device, not only routers) needs to implement the ip-routing module. Dave Thaler in his review of routing-cfg also points out that some of the concepts (routing table, active route) are necessary for hosts as well as for routers but the terminology in routing-cfg often seems to define the concepts only for routers.

This leads me to the conclusion that the routing-cfg draft should use more generic terms in such cases. For instance, given the standard host/router/system terminology, already the top-level container should probably be "system" rather than "router". But that would be confusing because it really contains only routing parameters and we also have the "ietf-system" module.  

Any comments or ideas?

Lada 

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 May 2012 14:20:37 +0200 (CEST)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> This leads me to the conclusion that the routing-cfg draft should use
> more generic terms in such cases. For instance, given the standard
> host/router/system terminology, already the top-level container should
> probably be "system" rather than "router".

The top-level container is currently called "routing", and that seems
to me to be appropriate both for hosts and routers.

The next level "list router" is maybe less obvious for a host, but I
have already commented on that one ;-)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 May 2012 17:45:29 +0200

> have already commented on that one ;-)

Oh yes, I meant this one, and I do remember your comments. ;-) Apart from finding a better name for the "router" list, I think two other options were discussed:

1. Create some kind of top-level logical/virtual system, perhaps a la SNMP context;

2. Duplicate the contents of the "router" list (with certain modifications) outside of it, i.e., under "routing".

From these two, I'd prefer #1. Could it be implemented e.g. as an optional NETCONF capability?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 09 May 2012 19:37:14 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Oh yes, I meant this one, and I do remember your comments. ;-) Apart from
> finding a better name for the "router" list, I think two other options were
> discussed:
> 

Yes, see
http://www.ietf.org/mail-archive/web/netmod/current/msg06568.html.

But we don't have to solve that now.

IMO, wrt the current data models, we should design them for one
"system".  If we somehow add system virtualization in the future, it
would be an orthogonal thing, like what I outline in the msg cited
above, which is not reflected in the data models.

So I don't think your options above solve the same problem.

The current question is "should the routing model support logical
routers in the data model", and I beleive the answer on the ML is
"yes".

Then the next question is how we do this.  Two alternatives have been
mentioned:

  1)  a single "router" list
      - pro: simple
      - con: weird on systems that don't support logical routers, and
             hon simple hosts.

  2)  /routing/<base-stuff>
               logical-router/<subset of base-stuff>

      (see
      http://www.ietf.org/mail-archive/web/netmod/current/msg06519.html)

      - pro: works well on systems w/o logical-routers
      - con: data-model duplication

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 9 May 2012 21:34:33 +0200

> So I don't think your options above solve the same problem.

Certain use cases for logical routers could be handled via full system virtualization but yes, a more light-weight mechanism for partly coupled logical routers (e.g. for MPLS/BGP VPNs) is probably needed as well.
 
> routers in the data model", and I beleive the answer on the ML is

Indeed.

>               logical-router/<subset of base-stuff>

A variant of this would be to put host and router stuff in separate modules. I proposed a possible organization earlier:

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

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 May 2012 12:45:45 +0200

> A variant of this would be to put host and router stuff in separate modules. I proposed a possible organization earlier:

So how about the following two modules:

------------------------------------------------------
module: ietf-host-routing
   +--rw routing
      +--rw ipv4
      |  +--ro routing-table
      |  +--rw static-routes
      |     +--rw route [seqno]
      |        +--rw seqno    uint32
      |        +--  ...
      +--rw ipv6
         +--ro routing-table
         +--rw static-routes
            +--rw route [seqno]
               +--rw seqno    uint32
               +--  ...
 rpcs:
   +---x active-route    
      +--ro input     
      |  +--ro destination-address?   inet:ip-address
      +--ro output    
         +--ro route
------------------------------------------------------

------------------------------------------------------
module: ietf-router
   +--rw router [name]
      +--rw name                 string
      +--rw enabled?             boolean
      +--rw interfaces
         ...
      +--rw routing-protocols
         ...
      +--rw route-filters
         ...
      +--rw routing-tables
         ...
 rpcs:
   +---x active-route    
      +--ro input     
      |  +--ro router                 router-ref
      |  +--ro destination-address
      +--ro output    
         +--ro route
------------------------------------------------------

The "host-routing" module provides very simple routing data for hosts (only one routing table for IPv4 and one for IPv6) and its organization is analogical to "ip-cfg".

The "router" module would be only for routers and compared to the current "routing" module the top-level "routing" container is removed, otherwise everything remains essentially the same.

In both cases, the "active-route" RPC simply queries the FIB, which could be implemented as a forwarding table or a route cache.

What do you folks think about this?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 May 2012 13:14:03 +0200

> What do you folks think about this?

Which problem does this solve? A generic Linux/BSD box does not know
whether it is used as a host or router. So would generic stuff then
not end up supporting both, potentially increasing costs?

/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: Fri, 11 May 2012 13:50:09 +0200

> not end up supporting both, potentially increasing costs?

What do you mean by "generic stuff"? Every implementation can and should choose one of them, so a web camera would use "host-routing" while a box running a routing daemon would use "router".

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 May 2012 14:08:46 +0200

On Fri, May 11, 2012 at 01:50:09PM +0200, Ladislav Lhotka wrote:
> 
> What do you mean by "generic stuff"? Every implementation can and
> should choose one of them, so a web camera would use "host-routing"
> while a box running a routing daemon would use "router".

A web camera is pretty clearly not "generic stuff". But...

- Is a Debian box a router?

- Is a Debian box a router if it has routing software installed, even
  if it is not configured?

- Is a Debian box a router if it has routing software enabled but not
  configured?

- Is a Debian box which has routing enabled becoming a host if I
  shutdown the routing software? And what about different run levels?

This gets me back to the question which problem we are solving (or
whether we are creating one ;-).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 May 2012 14:21:33 +0200

>  shutdown the routing software? And what about different run levels?

This all depends on the modules advertised by its NETCONF server. If the box could potentially be used as a router, then the "router" module should be used.

> whether we are creating one ;-).

The problem we are solving is that even simple hosts need some routing configuration and data. Currently the only option is to use the "routing" module (as the "ip-cfg" draft suggests), which is an overkill, and also it is really weird for a host to have the "router" list in its configuration even if it doesn't forward packets.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 May 2012 14:30:37 +0200

On Fri, May 11, 2012 at 02:21:33PM +0200, Ladislav Lhotka wrote:
> 
> The problem we are solving is that even simple hosts need some
> routing configuration and data. Currently the only option is to use
> the "routing" module (as the "ip-cfg" draft suggests), which is an
> overkill, and also it is really weird for a host to have the
> "router" list in its configuration even if it doesn't forward
> packets.

Can I find somewhere an example detailing what would be visible in the
config of a host if we use the "routing" module (as the "ip-cfg" draft
suggests)?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 11 May 2012 15:07:53 +0200

> config of a host if we use the "routing" module (as the "ip-cfg" draft

A minimum configuration could be something like

    <routing>
     <router>
      <name>rtr0</name>
      <interfaces>
       <interface>
        <name>eth0</name>
       </interface>
      </interfaces>
      <routing-protocols>
       <routing-protocol>
        <name>direct</name>
        <type>direct</type>
       </routing-protocol>
       <routing-protocol>
        <name>st0</name>
        <type>static</type>
        <static-routes>
         <v4ur:ipv4>
          <v4ur:route>
           <v4ur:seqno>1</v4ur:seqno>
           <v4ur:dest-prefix>0.0.0.0/0</v4ur:dest-prefix>
           <v4ur:next-hop>192.0.2.2</v4ur:next-hop>
          </v4ur:route>
         </v4ur:ipv4>
        <connected-routing-tables>
         <routing-table>
          <name>ipv4-unicast-main</name>
         </routing-table>
        </connected-routing-tables>
       </routing-protocol>
      </routing-protocols>
      <routing-tables>
       <routing-table>
        <name>ipv4-unicast-main</name>
       </routing-table>
      </routing-tables>
     </router>
    </routing>

Using the proposed "host-routing" module, the same configuration would be represented as

    <routing>
      <ipv4>
        <static-routes>
          <route>
            <seqno>1</seqno>
            <dest-prefix>0.0.0.0/0</dest-prefix>
            <next-hop>192.0.2.2</next-hop>
          </route>
        </static-routes>
      </ipv4>
    </routing>

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 May 2012 18:09:19 +0200

>             <next-hop>192.0.2.2</next-hop>

Could be worse. ;-)

It seems we face a reoccurring pattern here, namely how to make simple
configs simple while allowing for more complex configs at the same
time. We see this here and we have seen this in the context of SNMP
configuration models (and we will see it in other spaces like NTP
configs or resolver configs etc.). Has anybody some great ideas how to
address such issues in general?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 15 May 2012 11:33:45 +0200

>>            <next-hop>192.0.2.2</next-hop>

Sure.

> address such issues in general?

In this case, the extra stuff results mainly from the fact that the complex model allows for having multiple instances (a list) of certain objects such as routing tables, protocols etc., whilst the simple model only needs one.

It would help if YANG could specify default contents beyond leaf values, and in particular default (or even fixed) entries of lists. Here it could be e.g. the mandatory main "routing-table". 

Lada