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

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.

<edit-config>

<ipv4>

</address>

</ipv4>

</interfaces>

<control-plane-protocols>

<control-plane-protocol>

<type>rt:static</type>

<name/>

<static-routes>

<ipv4>

<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:

<get>

</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

From:	Brent W. Baccala
Subject:	Re: [GSoC 2017] Support for fsysopts and multiple interfaces
Date:	Wed, 28 Jun 2017 22:45:21 -0400