Feature #4572
open
nfdc route add: support local+remote FaceUri matching to identify nexthop face
0%
Description
Currently, if NFD is running on a machine with a NIC using ethernet multicast, routes can be added to that Face in the ordinary way, by using the ether:// address. However, if that machine has more than one NIC, then more than one device is using that ethernet multicast address, and trying to add routes as before will cause nfdc to tell you that you have to use Face ID instead, and list the Faces you can use.
This is a fine approach for interactive, user sessions, but this means that in a script you have to do something like:
nfdc face list | grep 'ether://' | grep 'eth0' | cut -d' ' -f 1 | cut -d'=' -f 2
in order to get the Face ID of eth0. This works now, but relying on the output of nfdc as being parseable is brittle. It would be preferrable if the device you want to add the route to could be specified in the invocation somehow.
Updated by
Updated by Davide Pesavento about 6 years ago
- Subject changed from Routes should be addable to multiple ethernet multicast Faces through `nfdc` by a URI scheme, not just Face ID to nfdc route add: support local+remote FaceUri matching to identify nexthop face
Updated by Junxiao Shi about 6 years ago
nfdc face list | grep 'ether://' | grep 'eth0' | cut -d' ' -f 1 | cut -d'=' -f 2
Those grep are unnecessary. nfdc face list local dev://eth0 gives the same result.
relying on the output of
nfdcas being parseable is brittle.
nfdc output is not meant for script consumption, as its format may change in the future. Scripts should interface with NFD Management protocol directly.
PyNDN, for example, can encode and decode FaceMgmt and RibMgmt structs when provided with correct protobuf definition (see examples/ directory in PyNDN2 repository).
Updated by Davide Pesavento almost 3 years ago
Nicholas Gordon wrote:
It would be preferrable if the device you want to add the route to could be specified in the invocation somehow.
This sounds sensible to me.
nfdc output is not meant for script consumption, as its format may change in the future
Agree, but that's not what this issue is about. OTOH, we do have XML output for nfdc status, so in addition to this issue we could consider adding machine-readable output to other commands as well (xml or json).