<div dir="ltr"><div><div>Hi Mahyuddin<br><br></div>Teng (CC'd) is still designing the solution. You may join an upcoming NFD call (see invitation on this mailing list) to discuss.</div><div><br></div>Yours, Junxiao<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 8:56 AM, Mahyuddin Husairi <span dir="ltr"><<a href="mailto:mahyuddin@gmail.com" target="_blank">mahyuddin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If the suggested feature on issue <a href="https://redmine.named-data.net/issues/4283" target="_blank">#4283</a> is not accepted, what is the way that self learning strategy switch the forwarding mode from multicast to unicast after discovery? <div>We just assume the relevant unicast face exist? and if not exist how?</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Nov 27, 2017 at 9:11 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Mahyuddin<div class="gmail_extra"><br><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">I need your opinion about enabling forwarding strategy to create face. At least unicast face (raw ethernet or udp) for dynamic unicast face features in my NDN based MANET solution.</span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><div style="font-size:12.8px"><span style="font-size:12.8px">1. What is the possible dirty hack way to enable it?</span></div></div></div></blockquote></span><div>Do not look for or use "dirty hack way". The harm of doing so is described on <a href="https://yoursunny.com/t/2017/academic-papers/" target="_blank">https://yoursunny.com/t/201<wbr>7/academic-papers/</a> "program quality" section.<br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-size:12.8px"><span style="font-size:12.8px">AFAIK, to create face, it is part of NFD management protocol API. Is that possible to access that API just like face-module.cpp in NFD tools?</span></div></div></div></blockquote></span><div>No, because forwarding plane is not an application. It cannot send packets to itself.</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"><span style="font-size:12.8px">2. Or is there any better way to implement it?</span></div></div></blockquote></span><div><div>The better way is to avoid the program in the first place.</div><div>A face is a generalization of an interface. Therefore, an Ethernet face shall support both multicast and unicast on the same physical interface. NFD currently implements Ethernet unicast like tunnel, which is wrong.</div></div><div>You may achieve unicasting by implementing <a href="https://redmine.named-data.net/issues/4283" target="_blank">https://redmine.n<wbr>amed-data.net/issues/4283</a> . I heard from last NFD call that NFD team is planning to reject this issue, but I believe this is the right way to go. </div><div><br></div><div>Yours, Junxiao</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <br><div class="m_-6963253180538049132gmail_signature" data-smartmail="gmail_signature">Human knowledge Belongs to The World</div>
</span></div>
</blockquote></div><br></div></div></div></div></div>