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ó <joanlluisll...@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
