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