Adds the possibility of ethernet neighbor

[pedosb]

The face-uri in the configuration file can now be a local face URI indicating the local ethernet device that should reach the neighbor.

[MurphyMc]

Just a note that I think MurphyMc/NLSR@38fb779 achieves the same effect on current NLSR.

[gorgonical]

I am closing this pull request. Please see Redmine issue #4310 for a more detailed explanation, but in short this is outside the scope of NLSR. If this Face exists in NFD and you have specified it in the configuration file using a supported URI schema, that neighbor will be usable.

[MurphyMc]

Thanks. The explanation makes sense, but the reason this seemed reasonable to me is because there are cases when different faces have the same remote URI (e.g., multiple Ethernet multicast faces). In such cases, it seems like NLSR will just grab on to the first one. Maybe that works anyway.

[gorgonical]

Small update: this doesn't exactly cover Ethernet neighbors very well because that would broadcast packets. This breaks a lot of assumptions that NLSR has to make. What I said earlier is still correct, but in most cases NLSR on direct Ethernet Faces would not function very well.

NLSR is not currently well-equipped to deal with broadcast Faces: how do you know every host reachable on that broadcast face that's running an NLSR instance has been reached? Is "neighbor" still defined the same way? For WLAN Faces, maybe only reachable hosts within a certain range are "neighbors." In general, much more work needs to be done on NLSR to achieve functionality in broadcast environments.

[MurphyMc]

That makes sense too.

I think my particular use case (which I imagine might not be entirely unique) is that my Ethernet links are actually point to point. In theory, I could configure them as unicast Ethernet faces in NFD, in which case they'd all have unique remote URIs and they could be configured that way in NLSR.

In practice...

1. This requires an extra configuration/discovery step in order to set/get the remote Ethernet address. This isn't a huge issue, but it might be nice to avoid it since it seems to gain nothing in some use cases. The use of a multicast address to skip it seems to be part of what Junxiao Shi was articulating in this mailing list post.
2. IIRC, unicast Ethernet faces are a relatively new feature in NFD, and the version of NFD suggested for use with NLSR in the README predates them? (Obviously, even if this reason is valid now, it shouldn't be forever.)

For the record, I'm not arguing strongly for the addition of local face URIs in NLSR. Just wanted to put out there the reasons (good or not) that led me here.

[gorgonical]

I agree that it's a bit of a rub. The decision that we made to divorce the network autoconfiguration components from NLSR was informed a lot by the "do one thing" policy. We were noticing that the evolution of Face management in NFD was making our lives hard, then we realized we didn't even have to do it.

As for the second point, it may or may not be recent, but I do perceive that it took a while to get off the ground. My understanding right now is that a new release of NLSR should be imminent to the tune of a week, so you'll be getting those unicast ethernet Faces. I am sorry that this got in your way, but broadcast ethernet is still a ways off for us.