NFD » NDN Specifications

Some comments/thoughts from others (taken from the agenda/issue list on NDN workspace):

1. trust schema works on a given system model
2. we still need to answer the question of how the local host and local hub find each other
3. with that, local hub fetches prefix announcement from the app
4. local forwarder is not in the business of verifying all the data forwarded, why prefix announcement (a data packet) should be different?

I wanted to share some work I’ve been doing on the Prefix Injection idea (allowing data producers to communicate their routes directly to a routing entity rather than the forwarder). I’ve written out a spec and am ready to start by implementing it in ndnd.

Here are the slides by Lixia giving a bit of background context:
https://docs.google.com/presentation/d/1Ni4Gdx49RJyNjnVjKPMXoKu7ez7l3hPO/edit

And here is a verbose spec (with motivation) — wire format is at the end
https://gist.github.com/jaczhi/5408716346761de953bec18444b9daf4

(note: I updated the spec with some of the feedback on Slack from 4/14. some remaining points of discussion: name of the overall protocol (inject), how to wrap/staple certificates, using existing Prefix Announcement block, how to know there is a routing entity running locally)

Please feel free to share any thoughts and feedback you have!

Some updates on the points of discussion:

1. How does a data producer know if there is a "routing entity" running locally? -> No easy way to do this, we should recommend implementers or users to also send a rib/register to the connected forwarder.

2. How to staple certs -> I followed Junxiao's suggestion to move stapling outside of the Data TLV (see the gist link above)

3. Should we reuse the existing Prefix Announcement object (https://redmine.named-data.net/projects/nfd/wiki/PrefixAnnouncement/) -> Prefix Announcement does not have cost as its semantics are different, thus we use a similar object but not the same.

4. How do /routing/inject interests reach the routing entity? What if there are 2+ routing entities connected to the same producer? -> open question

5. Overall naming / negative connotation for the word "inject" -> Davide proposes prefix registration v2 or prefix announcement v2, any other proposals?

Jacob Zhi wrote in #note-4:

1. How to staple certs -> I followed Junxiao's suggestion to move stapling outside of the Data TLV (see the gist link above)

Seems reasonable, and likely simpler from an implementation perspective. However, why is each certificate individually wrapped in a StapledCertificate TLV? And what's the TLV type number of StapledCertificate?

1. Should we reuse the existing Prefix Announcement object (https://redmine.named-data.net/projects/nfd/wiki/PrefixAnnouncement/) -> Prefix Announcement does not have cost as its semantics are different, thus we use a similar object but not the same.

Adding a Cost field to the Prefix Announcement is trivial, so not a very strong reason to create a different type of object. Can you elaborate on "its semantics are different"? On the surface, they look pretty similar to me.

1. Overall naming / negative connotation for the word "inject" -> Davide proposes prefix registration v2 or prefix announcement v2, any other proposals?

Right, basically any one of "prefix registration/announcement/advertisement v2" sounds better than "injection" to me.

Apologies for the late response.

However, why is each certificate individually wrapped in a StapledCertificate TLV

We want to make it very explicit which data is the prefix injection object and which one is the stapled certificate without ordering or name parsing.

And what's the TLV type number of StapledCertificate?

I was thinking of a random even number in the non-reserved range, what about 534 (0x216)? (This was advice from Varun).

Can you elaborate on "its semantics are different"?

Prefix Injection is an application protocol for exchanging routes for a specific application, ndnd-dv. I can make the wire format the exact same, but I don't see why we should use the same keyword and content type as for the NFD management protocol.

While "the shoe fits", the way the shoe is being used is completely different.

Right, basically any one of "prefix registration/announcement/advertisement v2" sounds better than "injection" to me.

The voiced concern from Lixia and Varun is that we have to be careful with our naming, and that prefix injection is not a registration or announcement. Registration and announcement are used to describe managing the forwarder in certain way. Meanwhile Ndnd dv is another application.

Jacob Zhi wrote in #note-6:

We want to make it very explicit which data is the prefix injection object and which one is the stapled certificate without ordering or name parsing.

Sorry, my question wasn't clear. I understand why you want a different TLV type (hence the "wrapping") and I have no issue with that. But why is each certificate wrapped in a separate StapledCertificate, instead of having a single StapledCertificates TLV that contains a list of certificates?

I was thinking of a random even number in the non-reserved range, what about 534 (0x216)? (This was advice from Varun).

The specific number doesn't matter to me. My point is that it needs to be written in the spec.

Prefix Injection is an application protocol for exchanging routes for a specific application, ndnd-dv. I can make the wire format the exact same, but I don't see why we should use the same keyword and content type as for the NFD management protocol.

The Prefix Announcement object is supposed to be a generic mechanism (or building block). It can be used with the forwarder for local prefix registration and now also with the routing daemon for prefix propagation/injection/whatever. It was always designed to be used in multiple scenarios (a third one is self learning).

My position is "let's not reinvent the wheel" unless someone comes up with an actual valid argument against (re)using the Prefix Announcement object.

The voiced concern from Lixia and Varun is that we have to be careful with our naming, and that prefix injection is not a registration or announcement. Registration and announcement are used to describe managing the forwarder in certain way. Meanwhile Ndnd dv is another application.

That may be a good reason to avoid "registration", since it has been used for a long time to refer to the (local) prefix registration in NFD. So let's take that one off the list. But I don't think the same argument applies to the other candidates. Sure, we recently started using rib/announce for the redesigned local prefix registration protocol that replaces rib/register, but 1) that's very recent, 2) it's not even fully implemented and not used yet (as far as I know), 3) arguably that redesign should have been called registration v2 or whatever. So it's not too late to use "announcement" for your protocol instead.

And what's the argument against "advertisement" or "propagation"?

But why is each certificate wrapped in a separate StapledCertificate, instead of having a single StapledCertificates TLV that contains a list of certificates?

Hm, after some thinking I believe that choice was arbitrary. Since your proposal is a little cleaner, I'll update the spec and the implementation.

needs to be written in the spec.

Done

My position is "let's not reinvent the wheel" unless someone comes up with an actual valid argument against (re)using the Prefix Announcement object.

Understood. I'll add the segment number back to the name, and check with some people Thursday on whether they're ok with using the same keyword and content type as PA, will reply as soon as I hear back.

I'll also get back to you about the naming.

Jacob Zhi wrote in #note-8:

My position is "let's not reinvent the wheel" unless someone comes up with an actual valid argument against (re)using the Prefix Announcement object.

Understood. I'll add the segment number back to the name, and check with some people Thursday on whether they're ok with using the same keyword and content type as PA, will reply as soon as I hear back.

Sure, thanks. We can also discuss more at the Friday call if needed.

And I suppose we could make the segment number optional in the PA object/data as well. I don't think we have a use for it at the moment.

PrefixAnnouncement has a segment number to accommodate large payloads that require segmentation.
For example, embedded trust schemas could enlarge the payload to exceed practical limit of NDN packet size.

Benefit of making the segment number component optional:

• You can save 3 octets in encoding.

Drawback of making the segment number component optional:

• The recipient implementation still has to support both formats.
• The unit tests still have to cover both formats.
• The trust schema rules still have to cover both formats.

Hence, I am against making the segment number component optional.

Summary of discussion at NDN weekly call:

1. Confirmed approach to have a single StapledCertificates TLV that contains a list of certificates. Will take some implementation work to fix parsing e.g. in NDNd.

2. Regarding whether to use the Prefix Announcement object inside the prefix injection interest:
   No disagreement that the format of the object is generally no different than the Prefix Announcement object.
   As to whether to use the Prefix Announcement object content type and and keyword (32=PA), Prefix Announcement object is supposed to be a "building block" to describe a prefix.
   It might be confusing to use the prefix announcement object because it is used by the prefix announcement protocol.
   However, if we separate prefix announcement protocol (since it is not widely used anyways) from the object, then we assert we should use the Prefix Announcement object in prefix injection.
   Thus we use the same content type and keyword.

3. Naming of "Prefix Injection" generally--not discussed today.