[Ndn-interest] Current state of NDN?
jdd at wustl.edu
Wed Jul 1 08:13:05 PDT 2020
> On Jul 1, 2020, at 3:26 AM, Michael Weiß <mixis at filts.net> wrote:
> Hi Junxiao,
>> On Jul 1, 2020, at 05:25, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
>> As I understand, one of the "unfit" policies is that every NDN testbed node must be controlled by "the NDN testbed management institution".
> Yes, that is an issue.
Actually, we have been working with a site for a few months now where we, NDN Testbed management, do not control their node.
So far it seems to be working well. We should be able to officially loosen this restriction.
>> The reason is that the current testbed is technically an intra-domain network. In IP terms, it's a single Autonomous System (AS). Naturally, a single entity should be managing this network.
>> To have an "open testnet" without centralized control, we would need an inter-domain network.
>> What we already have:
>> • High speed forwarding.
>> • Inter-domain hyperbolic routing.
>> What are still unresolved:
>> • Name assignment policy, as you already mentioned. One of the ideas is to derive NDN names from DNSSEC, but this would create a dependency on IP infrastructure.
> I have mixed feelings about this. As I understand it, this proposal uses DNS right at the top level instead of behind a prefix, like /dns/? I hope this is just for presentation.
>> • Producer mobility. On the current testbed, producer mobility is supported through prefix readvertisement. When a mobile producer connects to any of the testbed nodes, its prefix is announced into the global routing system. This would not scale in an inter-domain network. The solution is forwarding hint, but it's neither fully specified nor adopted by applications.
> The web has come a long way without producer mobility. I don’t think this is required to get started.
>> • Trust of routing messages. Although we have hyperbolic routing, the trust schema in the routing protocol still depends on a single trust anchor, which does not work in an inter-domain network.
>> I wonder what other policies are deemed "unfit for everybody else"?
> "13. We strongly discourage and will not accept requests to join the NDN testbed if there is no intention to use it for productive research. Connecting to the testbed for the sake of being connected is a violation of the current policies.”
> Maybe there is room for interpretation in “productive research”, but I think this excludes everybody who is not part of a research group. Sure, I can start tinkering without the testbed by setting up my own network, but that’s missing the magic of networking.
> As the NDNSSEC-paper says, there are many non-technical challenges and I wonder if it’s time to start experimenting by starting a testbed that is not managed centrally.
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
More information about the Ndn-interest