https://redmine.named-data.net/https://redmine.named-data.net/favicon.ico?14759811232016-03-08T15:08:44ZNDN project issue tracking systemNFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=149002016-03-08T15:08:44ZDavide Pesavento
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/3353">Feature #3353</a>: NetworkMonitor: emit fine-grained signals when the state of a network interface changes</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=149012016-03-08T15:09:19ZDavide Pesavento
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-2 priority-2 priority-default" href="/issues/3352">Feature #3352</a>: Set transport state UP/DOWN based on the state of the underlying network interface</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=149042016-03-08T15:10:17ZJunxiao Shi
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/3522">Feature #3522</a>: FaceUri syntax for netdev-bound faces</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=157472016-05-31T11:06:08ZDavide Pesavento
<ul><li><strong>Assignee</strong> deleted (<del><i>Andrea Tosatto</i></del>)</li><li><strong>Start date</strong> deleted (<del><i>03/08/2016</i></del>)</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=169212016-09-06T13:30:01ZJeff Burkejaburke@gmail.com
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul><p>This feature will be really valuable for demonstrating robust use of multiple interfaces. Can it be assigned?</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=172452016-10-11T21:43:24ZJunxiao Shi
<ul><li><strong>Assignee</strong> set to <i>Weiwei Liu</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul><p>Some implementation can be found in <a href="https://github.com/andreatosatto90/NFD/tree/interfaceFace">https://github.com/andreatosatto90/NFD/tree/interfaceFace</a>, although I don't know the correctness or quality of that implementation.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=172832016-10-16T15:50:59ZJeff Burkejaburke@gmail.com
<ul></ul><p>Why did the priority for this issue get lowered? It remains important to the application team for trying to make field deployments of NDN more resilient to connectivity changes. Also, this appears to be targeted for v0.5 while its dependencies (<a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a> and <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: FaceUri syntax for netdev-bound faces (Closed)" href="https://redmine.named-data.net/issues/3522">#3522</a>) are targeted for v0.6. Please revise the target version for the dependencies to match. </p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=172862016-10-16T15:56:51ZDavide Pesavento
<ul><li><strong>Target version</strong> changed from <i>v0.5</i> to <i>v0.6</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=172892016-10-16T16:03:19ZJeff Burkejaburke@gmail.com
<ul></ul><p>I was suggesting this target v0.5, not the other way around. </p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=172992016-10-18T10:03:00ZJunxiao Shi
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17299/diff?detail_id=15150">diff</a>)</li><li><strong>Estimated time</strong> set to <i>18.00 h</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=173092016-10-18T13:04:59ZJunxiao Shi
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li><li><strong>Estimated time</strong> changed from <i>18.00 h</i> to <i>12.00 h</i></li></ul><p>I explained to Weiwei that this implementation would involve changes in <code>FaceManager</code> and <code>UnicastUdpTransport</code> (or a new subclass of <code>Transport</code>).</p>
<p>Estimated time is 12 hours because this likely needs a lot of testing.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=174132016-10-28T09:51:47ZJunxiao Shi
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-2 priority-default" href="/issues/3831">Feature #3831</a>: Add RIB routes for automatically created permanent faces</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=176202016-11-21T14:52:29ZJunxiao Shi
<ul></ul><blockquote>
<p>When the configuration file is loaded or reloaded</p>
</blockquote>
<p>As of NFD 0.5.0, NIC addition/removal triggers a partial configuration reload of <code>face_system</code> section. When we have <code>NetworkMonitor</code> (<a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a>), do we need to change anything in this part?</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=176212016-11-21T15:53:08ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>As of NFD 0.5.0, NIC addition/removal triggers a partial configuration reload of <code>face_system</code> section. When we have <code>NetworkMonitor</code> (<a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a>), do we need to change anything in this part?</p>
</blockquote>
<p>I believe we should stop doing that. It's rather <em>non</em>-standard behavior and could be unexpected/confusing to some. The config file should be reloaded <em>only</em> upon an explicit user action (e.g. SIGHUP or SIGUSR).</p>
<p>The new <code>NetworkMonitor</code> should be wired up to NFD, so that addition and removal of network interfaces result in the creation and destruction of the corresponding multicast and NIC-associated faces, when needed and allowed by the config file.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=177242016-11-28T21:19:28ZWeiwei Liusummerwing10@gmail.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>I added an option "nicfaces" into the NFD configuration file and as well as the corresponding code that parses it in face-manager.cpp. Please take a look if it makes sense to you. Thanks!</p>
<p><a href="https://gerrit.named-data.net/#/c/3363/1">https://gerrit.named-data.net/#/c/3363/1</a></p>
<pre><code> ; The nicfaces section contains settings of NIC-associated permanent faces.
@IF_HAVE_LIBPCAP@nicfaces
@IF_HAVE_LIBPCAP@{
@IF_HAVE_LIBPCAP@ ;Whitelist and blacklist can contain, in no particular order,
@IF_HAVE_LIBPCAP@ ;interface names (e.g., ifname eth0),
@IF_HAVE_LIBPCAP@ ;mac addresses (e.g., ether 85:3b:4d:d3:5f:c2),
@IF_HAVE_LIBPCAP@ ;subnets (e.g., subnet 192.0.2.0/24, note that only IPv4 is supported here),
@IF_HAVE_LIBPCAP@ ;or a wildcard (*) that matches all interfaces.
@IF_HAVE_LIBPCAP@
@IF_HAVE_LIBPCAP@ whitelist
@IF_HAVE_LIBPCAP@ {
@IF_HAVE_LIBPCAP@ *
@IF_HAVE_LIBPCAP@ }
@IF_HAVE_LIBPCAP@ blacklist
@IF_HAVE_LIBPCAP@ {
@IF_HAVE_LIBPCAP@ }
@IF_HAVE_LIBPCAP@ ; remotes can contain the remote FaceUris to which the NIC-associated permanent
@IF_HAVE_LIBPCAP@ ; faces will be created. These FaceUris must be in canonical form. Only UDP is
@IF_HAVE_LIBPCAP@ ; supported for now.
@IF_HAVE_LIBPCAP@ remotes
@IF_HAVE_LIBPCAP@ {
@IF_HAVE_LIBPCAP@ }
@IF_HAVE_LIBPCAP@}
</code></pre> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=177262016-11-29T02:17:00ZDavide Pesavento
<ul></ul><blockquote>
<p>In NFD configuration file, add an option that specifies zero or more remote FaceUris to which NIC-associated permanent faces will be created<br>
[...]<br>
NFD creates and destroys NIC-associated permanent faces as necessary to maintain one NIC-associated permanent face per NIC per remote FaceUri.</p>
</blockquote>
<p>Does this mean that if I have two NICs and configure two remote URIs, I get <em>four</em> NIC-associated faces? What's the rationale? I doubt that's the expected behavior in the vast majority of the cases.</p>
<p>What we want to be able to do, at least for our V2I use cases, is: specify one remote URI (<code>udp4:</code> or <code>udp6:</code>) for each network interface available on the system, or a subset of them, and have NIC-associated face created on it.<br>
A network interface would be identified by its name, or optionally by its hardware address if you want. We don't currently need an IP/subnet match like in the multicast faces whitelist, but I can see a scenario where one wants to use different remote URIs depending on the IP address assigned by the network, in other words, a different remote URI for each upstream provider/ISP (although identifying that via the assigned IP would not be 100% reliable).<br>
We also don't need more than one remote URI per NIC at the moment, but I would include multiple remotes in the design, at least to make sure the config file syntax is sufficiently extensible to eventually support that. In any case each network interface should have its own independent set of remote URIs, i.e. no cartesian product.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=177302016-11-29T06:10:10ZJunxiao Shi
<ul></ul><blockquote>
<p>each network interface should have its own independent set of remote URIs</p>
</blockquote>
<p>I agree. There should be multiple (whitelist,blacklist,remotes) tuples to support this use case. Cartesian product is used within each tuple.</p>
<p>The existing design (a single cartesian product) can also work, although it creates more faces than necessary. Those excessive faces simply don't get used by the strategy due to their bad performance. The overhead is the maintenance cost of those faces, such as keep-alives.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=177322016-11-29T09:13:25ZWeiwei Liusummerwing10@gmail.com
<ul></ul><blockquote>
<p>I agree. There should be multiple (whitelist,blacklist,remotes) tuples to support this use case. Cartesian product is used within each tuple.</p>
</blockquote>
<p>Just to make sure I understand what you are saying. In this case, the config file could look like this, right? </p>
<pre><code>nicfaces
{
whitelist
{
ifname eth0
}
blacklist
{
}
remotes
{
udp4://192.168.1.2:6363
}
whitelist
{
ether 85:3b:4d:d3:5f:c2
}
blacklist
{
}
remotes
{
udp4://192.168.3.4:6363
}
}
</code></pre>
<p>Or alternatively, can we just use (interface, remotes) pairs like the following? Since multiple whitelists and blacklists seem a little bit confusing to me.</p>
<pre><code>nicfaces
{
ifname eth0
remotes
{
udp4://192.168.1.2:6363
}
ether 85:3b:4d:d3:5f:c2
remotes
{
udp4://192.168.3.4:6363
}
}
</code></pre> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178662016-12-15T13:15:16ZWeiwei Liusummerwing10@gmail.com
<ul></ul><p><a href="https://gerrit.named-data.net/#/c/3363/2">https://gerrit.named-data.net/#/c/3363/2</a><br>
I added a field 'tuple' to explicitly group each (whitelist, blacklist, remotes) tuple. So the nicfaces section now has the following form. </p>
<pre><code>nicfaces
{
tuple
{
whitelist
{
ifname eth0
}
blacklist
{
}
remotes
{
udp4://192.168.1.2:6363
}
}
}
</code></pre> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178672016-12-15T13:54:41ZJunxiao Shi
<ul></ul><p>Reply to note-19:</p>
<p><code>tuple</code> doesn't reflect semantics. <code>remotes</code> key is unnecessary.</p>
<p>I suggest the following:</p>
<pre><code>nicfaces
{
nicface
{
remote udp4://192.0.2.1:6363
remote udp4://192.0.2.2:6363
whitelist
{
ifname eth0
}
blacklist
{
}
}
nicface
{
remote udp4://192.0.2.3:6363
whitelist
{
ether 85:3b:4d:d3:5f:c2
}
blacklist
{
}
}
}
</code></pre>
<ul>
<li><code>nicfaces</code> has zero or more <code>nicface</code> keys</li>
<li><code>nicface</code> has one or more <code>remote</code> keys</li>
<li><code>nicface</code> has zero or one <code>whitelist</code> key</li>
<li><code>nicface</code> has zero or one <code>blacklist</code> key</li>
<li>If the same <code>remote</code> value appears under multiple <code>nicface</code> keys and a NIC matches multiple whitelist+blacklist combinations, only one face should be created between this NIC and this remote FaceUri.</li>
</ul>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178692016-12-15T20:10:43ZDavide Pesavento
<ul></ul><p>Is the <code>nicfaces</code> "wrapper element" really needed? can we just have a bunch of <code>nicface</code> specifications?</p>
<p>Also, I would be ok with the simplified syntax of the 2nd proposal in note-18, i.e. without using <code>whitelist</code> and <code>blacklist</code> keys. So for instance:</p>
<pre><code>nicface
{
ifname eth0
remote udp4://192.168.1.2:6363
}
nicface
{
ether 85:3b:4d:d3:5f:c2
ether 85:3b:4d:a4:5b:f8
remote udp6://[...]:6363
}
nicface
{
; applies to all interfaces (or all interfaces not matched by a previous 'nicface'?)
remote udp4://192.168.100.1:6363
}
</code></pre> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178752016-12-18T04:55:52ZJunxiao Shi
<ul></ul><blockquote>
<p>Is the <code>nicfaces</code> "wrapper element" really needed? can we just have a bunch of <code>nicface</code> specifications?</p>
</blockquote>
<p>Having a <code>nicfaces</code> wrapper keeps the section more organized.<br>
But I have no objection eliminating it.</p>
<blockquote>
<p>the simplified syntax without using <code>whitelist</code> and <code>blacklist</code> keys</p>
</blockquote>
<p>No. You lose the capability of blacklist, and cannot easily reuse code for whitelist.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178762016-12-18T14:21:41ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<blockquote>
<p>the simplified syntax without using <code>whitelist</code> and <code>blacklist</code> keys</p>
</blockquote>
<p>No. You lose the capability of blacklist, and cannot easily reuse code for whitelist.</p>
</blockquote>
<p>I'm aware of that. It's just an alternative proposal that is slightly less powerful, but also much more succinct and intuitive.</p>
<p>As for code reuse, it's a very minor concern in my opinion. I'm sure we can easily do a small refactoring in <code>NetworkInterfacePredicate</code> in order to maximize code reuse.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=178972016-12-21T22:34:39ZAlex Afanasyev
<ul></ul><p>Let's go with the proposal in note 20. Agree with Davide that it is a bit more cumbersome syntax, but it should be ok.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179002016-12-22T23:11:52ZWeiwei Liusummerwing10@gmail.com
<ul></ul><p>As suggested by Alex, I updated the code according to node 20.<br>
<a href="https://gerrit.named-data.net/#/c/3363/3/">https://gerrit.named-data.net/#/c/3363/3/</a></p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179052016-12-23T16:58:46ZDavide Pesavento
<ul></ul><p>I just realized there's a (IMHO serious) flaw with the syntax in note-20. The <code>nicface</code> stanza seems to imply from its name that it defines <em>one</em> NIC-associated face. However, it can in fact create <em>any</em> number of faces, zero, one, or more than one. There isn't a 1-to-1 relationship between a <code>nicface</code> stanza and a NIC-associated face. But the syntax seems to imply that there is one, which is confusing.</p>
<p>So I'm now against the syntax in note-20, and I'd like to propose the alternative in note-21 again.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179062016-12-23T19:25:55ZJunxiao Shi
<ul></ul><p>note-21 is no better than note-20 because each <code>nicface</code> key also corresponds to zero or more NIC-associated faces.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179072016-12-23T19:47:07ZDavide Pesavento
<ul></ul><p>err sorry, completely forgot an important piece in my previous comment... I meant to say: note-21 syntax with <code>nicface</code> renamed to <code>nicfaces</code>.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179092016-12-23T20:16:43ZJunxiao Shi
<ul></ul><p>I still disagree with note-21 and its amendment in note-28.<br>
I acknowledge the issue pointed out in note-26, and my proposal is:</p>
<pre><code>nicfaces
{
rule
{
remote udp4://192.0.2.1:6363
remote udp4://192.0.2.2:6363
whitelist
{
ifname eth0
}
blacklist
{
}
}
rule
{
remote udp4://192.0.2.3:6363
whitelist
{
ether 85:3b:4d:d3:5f:c2
}
blacklist
{
}
}
}
</code></pre>
<p>The whole section defines all NIC-associated permanent faces, while each <code>rule</code> causes the creation of zero or more faces.<br>
I'd like to preserve whitelist+blacklist and be able to reuse existing whitelist+blacklist code with minimal changes.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179382016-12-26T16:10:36ZWeiwei Liusummerwing10@gmail.com
<ul></ul><p>I changed the design to note-29 since I didn't see any objections. <a href="https://gerrit.named-data.net/#/c/3363/4">https://gerrit.named-data.net/#/c/3363/4</a></p>
<p>Besides, for the next step, we need to actually create NIC-associated permanent UDP unicast face. I plan to create a new transport class "NicAssociatedUnicastUdpTransport" as a subclass of DatagramTransport instead of reusing UnicastUdpTransport.. Any suggestions?</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179492016-12-27T04:06:02ZDavide Pesavento
<ul></ul><p>Weiwei Liu wrote:</p>
<blockquote>
<p>I plan to create a new transport class "NicAssociatedUnicastUdpTransport" as a subclass of DatagramTransport instead of reusing UnicastUdpTransport.. Any suggestions?</p>
</blockquote>
<p>What are the advantages and disadvantages of doing so?</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179522016-12-27T09:50:24ZWeiwei Liusummerwing10@gmail.com
<ul></ul><blockquote>
<p>What are the advantages and disadvantages of doing so?</p>
</blockquote>
<p>What I can see for now is just if reusing UnicastUdpTransport we'll need to add a new constructor and the beforeChangePersistency() also needs to be changed to handle the NIC-associated case (Just to make sure, in this case we wouldn't allow the persistency to be changed to anything other than FACE_PERSISTENCY_PERMANENT, right?). I just think putting them into an independent class may make the code clearer and easier to understand.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179552016-12-27T15:13:31ZJunxiao Shi
<ul></ul><p>Before talking about what <code>Transport</code> type to use, we should first understand how to manage the lifetime of <code>Face</code>:</p>
<ul>
<li>When a NIC is added or removed, or becomes matching / non-matching the whitelist+blacklist filter due to addition or removal of a particular IP address, which component is responsible for creating and destroying the <code>Face</code> objects?</li>
<li>When a NIC gains its first IP address or loses its last IP address but does not affect its matching status (such as a whitelist matching by MAC address), should we create/destroy the <code>Face</code> object, or should we simply set the transport up / down? Which component is responsible for do so?</li>
</ul>
<p>I think the logical answer in current structure would be <code>FaceManager</code>, however I don't think it's the right answer: <code>FaceManager</code> is taking way too many responsibilities, and it's getting more and more complicated.</p>
<p>My proposal is to split <code>FaceManager</code> into three components:</p>
<ul>
<li><code>FaceSystem</code> owns all <code>ProtocolFactory</code> objects; it belongs in <code>face/</code> rather than <code>mgmt/</code>. It directly processes the configuration section, but delegates <code>nicfaces</code> and multicast sections to <code>NicManager</code>.</li>
<li><code>NicManager</code>, also a part of <code>face/</code>, listens to signals from <code>NetworkMonitor</code> and takes proper reactions. It controls the creation and destroying of NIC-associated permanent faces and multicast faces.</li>
<li><code>FaceManager</code> is an interface to the management system. Its responsibility is to serve <a class="wiki-page" href="https://redmine.named-data.net/projects/nfd/wiki/FaceMgmt">FaceMgmt</a> commands and datasets. It calls into <code>FaceSystem</code> for those functions.</li>
</ul>
<p>I know these sound like drastic changes, but I believe they lead to a cleaner architecture.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179642016-12-28T07:45:00ZDavide Pesavento
<ul></ul><p>Weiwei Liu wrote:</p>
<blockquote>
<p>What I can see for now is just if reusing UnicastUdpTransport we'll need to add a new constructor and the beforeChangePersistency() also needs to be changed to handle the NIC-associated case (Just to make sure, in this case we wouldn't allow the persistency to be changed to anything other than FACE_PERSISTENCY_PERMANENT, right?). I just think putting them into an independent class may make the code clearer and easier to understand.</p>
</blockquote>
<p>Sorry, I think I misunderstood note-30. I thought you were comparing subclassing <code>DatagramTransport</code> vs subclassing <code>UnicastUdpTransport</code>. Modifying <code>UnicastUdpTransport</code> itself to support NIC-associated faces is obviously out of the question. <code>NicAssociatedUdpTransport</code> is a separate transport type, hence it needs a separate class. Another question is whether you want to inherit from <code>UnicastUdpTransport</code> or <code>DatagramTransport</code>. I think you can start from the latter, and see how much duplication you end up having in the new class.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179652016-12-28T09:29:51ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>Before talking about what <code>Transport</code> type to use, we should first understand how to manage the lifetime of <code>Face</code>:<br>
[...]<br>
I think the logical answer in current structure would be <code>FaceManager</code>, however I don't think it's the right answer: <code>FaceManager</code> is taking way too many responsibilities, and it's getting more and more complicated.</p>
</blockquote>
<p>While I agree with the above sentiment, and had the same thoughts when I was helping Andrea with his quick 'n' dirty implementation of this feature, I don't think doing this refactoring now is a good idea. This is an important feature and several applications would benefit from it. It should be implemented asap. Requiring such a large refactoring to be completed before this feature can be merged could delay the latter for weeks/months.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179702016-12-28T15:02:01ZJunxiao Shi
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/3904">Feature #3904</a>: FaceManager refactoring</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=179712016-12-28T15:03:18ZJunxiao Shi
<ul></ul><blockquote>
<p>Requiring such a large refactoring to be completed before this feature can be merged could delay the latter for weeks/months.</p>
</blockquote>
<p>I see no difficulty in this refactoring. It's just moving code around, and can be done in one week if review turnaround is fast enough.<br>
Without the refactoring, it would be difficult doing note-14 changes.</p>
<p>In the meanwhile, Weiwei should finish up <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a> which blocks this issue, and also work on <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor fine-grained signals for macOS (Closed)" href="https://redmine.named-data.net/issues/3817">#3817</a> which is necessary in Jeff's scenario.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=182262017-01-27T12:19:48ZJunxiao Shi
<ul></ul><p>In <a href="https://gerrit.named-data.net/#/c/3551/6/tests/daemon/face/ethernet-fixture.hpp@38">https://gerrit.named-data.net/#/c/3551/6/tests/daemon/face/ethernet-fixture.hpp@38</a> Davide pointed out:</p>
<blockquote>
<p>I'm insisting on <em>not</em> using "NIC". The "C" in NIC stands for Card or Controller... a NIC represents a piece of hardware. The "interfaces" we normally use do not necessarily correspond to a real hardware controller. Think about tun/tap, virtual ethernet pairs, or virtual bridges, etc... even the loopback interface is not a real hw device.<br>
So NIC is incorrect, it's better to use "network interface" or one of its abbreviations.</p>
</blockquote>
<p>Does the same argument apply to "NIC-associated permanent faces"? They can be associated with hardware interfaces, but can also be associated with virtual interfaces.<br>
If so, is there a better name?</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=182292017-01-27T16:17:57ZDavide Pesavento
<ul></ul><p>Junxiao Shi wrote:</p>
<blockquote>
<p>Does the same argument apply to "NIC-associated permanent faces"? They can be associated with hardware interfaces, but can also be associated with virtual interfaces.</p>
</blockquote>
<p>Yep.</p>
<blockquote>
<p>If so, is there a better name?</p>
</blockquote>
<p>I tried to come up with a better (and possibly shorter) name but I failed.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=182392017-01-29T20:00:17ZJunxiao Shi
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>I have provided an API design in <a href="https://gerrit.named-data.net/3363">https://gerrit.named-data.net/3363</a> patchset8. It depends on the completion of <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a>. Weiwei should refine this design and implement TODO items after <a class="issue tracker-2 status-5 priority-2 priority-default closed" title="Feature: NetworkMonitor: emit fine-grained signals when the state of a network interface changes (Closed)" href="https://redmine.named-data.net/issues/3353">#3353</a> has been merged.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=186172017-03-25T10:07:34ZDavide Pesavento
<ul><li><strong>Assignee</strong> deleted (<del><i>Weiwei Liu</i></del>)</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=187012017-03-27T22:25:35ZJunxiao Shi
<ul><li><strong>Blocked by</strong> deleted (<i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/3353">Feature #3353</a>: NetworkMonitor: emit fine-grained signals when the state of a network interface changes</i>)</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=187052017-03-27T22:25:52ZJunxiao Shi
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/4021">Feature #4021</a>: FaceSystem: use NetworkMonitor::listNetworkInterfaces()</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=190072017-05-12T13:56:09ZDavide Pesavento
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=208422017-10-17T13:18:59ZDavide Pesavento
<ul><li><strong>Target version</strong> changed from <i>v0.6</i> to <i>v0.7</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=237992018-08-07T14:41:06ZJunxiao Shi
<ul><li><strong>Assignee</strong> set to <i>Junxiao Shi</i></li></ul><p>I'll attempt to resurrect Change 3363.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=238722018-08-20T13:58:18ZDavide Pesavento
<ul></ul><p>Davide Pesavento wrote:</p>
<blockquote>
<p>Junxiao Shi wrote:</p>
<blockquote>
<p>Does the same argument apply to "NIC-associated permanent faces"? They can be associated with hardware interfaces, but can also be associated with virtual interfaces.</p>
</blockquote>
<p>Yep.</p>
<blockquote>
<p>If so, is there a better name?</p>
</blockquote>
<p>I tried to come up with a better (and possibly shorter) name but I failed.</p>
</blockquote>
<p>As a (better) alternative to "NIC", I suggest the terms "<strong>netdev</strong>" or "<strong>netdevice</strong>", which are used in the Linux kernel networking stack.</p>
<p>I also suggest "bound" rather than "associated", the former is shorter and already used in the Linux networking stack (e.g., SO_BINDTODEVICE socket option). However, I don't think we need to include "bound" (or "associated" or any other alternative) in the name of the feature or related classes that implement the feature; it can be used in documentation and code comments that talk about the feature, e.g., "...a face bound to a netdev/netdevice...".</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=238732018-08-20T15:29:41ZDavide Pesavento
<ul><li><strong>Related to</strong> <i><a class="issue tracker-3 status-5 priority-2 priority-default closed" href="/issues/4717">Task #4717</a>: Clarify FacePersistency semantics</i> added</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=240922018-09-26T08:02:05ZJunxiao Shi
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>In Progress</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=241872018-10-22T07:25:21ZJunxiao Shi
<ul><li><strong>Subject</strong> changed from <i>NIC-associated permanent faces</i> to <i>Netdev-bound faces</i></li><li><strong>Description</strong> updated (<a title="View differences" href="/journals/24187/diff?detail_id=21212">diff</a>)</li></ul><p>After two years, config parsing code is finally done <a href="https://gerrit.named-data.net/3363">https://gerrit.named-data.net/3363</a>.<br>
Test coverage is incomplete for every possible config file error, but I think it's unimportant.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=243252018-11-19T18:05:31ZDavide Pesavento
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/24325/diff?detail_id=21348">diff</a>)</li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=257332019-08-27T20:41:22ZDavide Pesavento
<ul><li><strong>Target version</strong> changed from <i>v0.7</i> to <i>22.02</i></li></ul> NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=263352020-02-07T06:29:58ZJunxiao Shi
<ul><li><strong>Assignee</strong> deleted (<del><i>Junxiao Shi</i></del>)</li></ul><p>I will no longer work on this issue because I'm no longer interested in this feature.</p>
NFD - Feature #3521: Netdev-bound faceshttps://redmine.named-data.net/issues/3521?journal_id=272572021-04-03T01:17:15ZDavide Pesavento
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li><li><strong>Target version</strong> deleted (<del><i>22.02</i></del>)</li></ul>