Re: RFC: nexthop cache separation

[David Young <dyoung%pobox.com@localhost>]

On Fri, Mar 25, 2016 at 07:41:18PM +0900, Ryota Ozaki wrote:
> [after]
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use
> Mtu Interface
> default            10.0.1.1           UGS         -        -
>  -  shmif0
> 10.0.1/24          link#2             UC          -        -
>  -  shmif0
> 10.0.1.2           link#2             UHl         -        -      -  lo0
> 127.0.0.1          lo0                UHl         -        -  33648  lo0

Previous to the change you've proposed, 'route show' provided a more
comprehensive view of the routing state.  Now, it is missing several
useful items.  Where has the 10.0.1.1 route gone?  Where are the
MAC addresses?  Previously, you could issue one command and within
an eyespan have all of the information that you needed to diagnose
connectivity problems on routers.  Now, to first appearances, every
routing state looks suspect, and it's necessary to dig in with arp/ndp
to see if things are ok.

Please, if your changes materially change the user interface, provide
mockups.  Mockups are powerful communication tools that help to build
consensus and provide strong implementation guidance.  Design oversights
that are obvious in mockups may be invisible in patches.  It's easy
to mockup command-line displays like route(8)'s using $EDITOR.  I
cannot recommend strongly enough that developers add mockups to their
engineering-communications repertoire.

Dave

[*] It was bad enough that networking in NetBSD contains many potential
    switchbacks and blackholes once a firewall is active.  I don't think
    we're worse than any other system in that regard, but ISTM we should
    strive to be *better*.

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981