Re: [GSoC 2017] Support for fsysopts and multiple interfaces

[Joan Lledó]

Hello Brent,

Thanks for your interest in my GSoC. I didn't know the tools you
propose and think that everything that moves us towards using
standards is good. What I believe is that probably such a development
should be done by another developer more experienced than me, besides,
until the proper libraries are created it'd suppose a big effort that
mightn't be worth the gain, but it's always fine to know about new
technologies.

Regards!

2017-06-29 4:45 GMT+02:00 Brent W. Baccala <cosine@freesoft.org>:
> Joan -
>
> Thank you for your work on this.  I haven't commented on it until now,
> partly because of some email problems, and partly because I haven't been
> working on Hurd for the last six months or so.
>
> On Mon, Jun 26, 2017 at 7:28 AM, Joan Lledó <joanlluislledo@gmail.com>
> wrote:
>>
>> I've advanced in several fronts during the last two weeks, like the
>> initial configuration of the stack from the command line, by using
>> libargp, or reading and writing a new configuration in run time,
>> through fsysopts. The aim is to support exactly the same options
>> pfinet does, so we'll be able to replace pfinet by the LwIP translator
>> transparently for the rest of the system.
>
>
> That's good!  As far as I know, using command line style options is the only
> way to change configuration in the current pfinet translator.
>
> Leaving that for backwards compatibility is fine, but I think that we also
> want to have more of an API to interface with software.
>
> The current state of the art seems to be YANG data models (RFC 6020)
> manipulated by either NETCONF (RFC 6241) or RESTCONF (RFC 8040).
>
> NETCONF is transported over an SSH encrypted session and uses an XML-encoded
> request/reply format.  RESTCONF is transported over SSL and uses HTTP verbs
> with JSON encoded data.  Also, NETCONF supports transactions, allowing
> complex configuration changes to be made atomically.
>
> For example, here's a NETCONF request that simultaneously sets an IP address
> on an interface and sets the default route to point out that interface.  The
> changes are supposed to be atomic, so there's no point at which an old
> default route points to an address that's no longer reachable because the
> interface has been reconfigured.
>
> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>    <edit-config>
>       <config>
>          <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
>             <interface>
>             <name>eth</name>
>             <ipv4>
>                <address operation="replace">
>                   <ip>10.1.1.1</ip>
>                   <netmask>255.255.255.0</netmask>
>                </address>
>             </ipv4>
>          </interfaces>
>          <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
>             <control-plane-protocols>
>                <control-plane-protocol>
>                   <type>rt:static</type>
>                   <name/>
>                   <static-routes>
>                      <ipv4>
>                         <route operation="replace">
>                            <destination-prefix>0.0.0.0/0<destination-prefix>
>                            <next-hop>
>
> <next-hop-address>10.1.1.254</next-hop-address>
>                            </next-hop>
>                         </route>
>                      </ipv4>
>                   </static-route>
>                </control-plane-protocol>
>             </control-plane-protocols>
>          </routing>
>       </config>
>    </edit-config>
> </rpc>
>
> My example is probably not quite right, and obviously complex enough to
> relegate to a library, several actually, at least one for the XML and
> another for the YANG.  It's something that could be contributed back to
> LwIP.
>
> For our purposes, I envision dropping TCP/SSH and sending XML configuration
> snippets (like the one above) over a Mach RPC with a string argument, and
> getting the XML encoded response back in return.  Encoding and decoding
> large XML strings would obviously present performance issues, but I don't
> expect these operations to be run often enough for that to be an issue.
>
> NETCONF also supports retrieving operational data, so you could retrieve a
> list of TCP sessions, to implement something like netstat.  A YANG model
> hasn't been published for TCP, but there's a TCP MIB and a procedure to
> convert MIBs to YANG.  [1]  Something like this would retrieve the TCP
> session data needed for a basic netstat:
>
> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>    <get>
>       <filter type="subtree">
>          <tcp xmlns="urn:ietf:params:xml:ns:yang:smiv2:TCP-MIB">
>             <tcpConnectionEntry/>
>          </tcp>
>       </filter>
>    </get>
> </rpc>
>
> Implementing this is a lot of work, and I'm not suggesting it for part of
> this GSoC project, but I want to document and discuss what kind of API our
> network translators should ultimately support.  Our options, as I see it,
> are:
>
> 1. some kind of non-standard, Hurd-specific API to set configurations and
> retrieve statistics
>
> 2. MIBs with Mach RPCs to implement SNMP operations.  Outdated and
> non-atomic.
>
> 3. YANG models with RESTCONF-like operations.  Would practically require
> embedding an http server in the translator.
>
> 4. YANG models with NETCONF operations, as described above.
>
> [1] http://www.netconfcentral.org/database_docs
>
>     agape
>     brent
>
>