[{"author": "Junxiao Shi", "text": "

Prefix aggregation in IP is dying.
\nMost BGP announcements today are /24 prefixes.
\nIf you own a /24, you can change providers without renumbering your network.

", "time": "2026-07-22T14:48:33.000Z"}, {"author": "David Oran", "text": "

yes - good point.

", "time": "2026-07-22T14:52:19.000Z"}, {"author": "Stuart Card", "text": "

Host Identity Protocol is also map-encap but does not require Internet wide change: it can be adopted incrementally & immediately brings benefits to adopters.

", "time": "2026-07-22T14:52:28.000Z"}, {"author": "David Oran", "text": "

The motivation for MPLS wasn't routing scalability but rather traffic engineering

", "time": "2026-07-22T14:52:41.000Z"}, {"author": "Ryo Yanagida", "text": "

I classified HIP as uh SHIM layer approach in my thesis if I remember correctly

", "time": "2026-07-22T14:53:08.000Z"}, {"author": "David Oran", "text": "

@Stuart - yes, another good example which also tried to solve the host authenticity problem by using key hashes as the identifiers

", "time": "2026-07-22T14:53:42.000Z"}, {"author": "David Oran", "text": "

Of course the question remain of why use OP multicast in the first place rathe than a layer 4 or 7 approach like MOQ

", "time": "2026-07-22T14:56:46.000Z"}, {"author": "Stuart Card", "text": "

@Ryo I just found your thesis, thanks!

", "time": "2026-07-22T14:58:47.000Z"}, {"author": "Roland Bless", "text": "

There are scalable routing schemes that do not require a mapping system. KIRA is a scalable routing system that even does not need an ID->LOC mapping system.

", "time": "2026-07-22T14:59:01.000Z"}, {"author": "David Oran", "text": "

forside 13 - it seems SCION nails spoliations to most of the problems for interdomain scalability across AS's

", "time": "2026-07-22T14:59:12.000Z"}, {"author": "Ryo Yanagida", "text": "

@Stuart Card hmm i think it should still be not public... (and perhaps not so relevant in this context :sweat_smile: )

", "time": "2026-07-22T14:59:55.000Z"}, {"author": "Stuart Card", "text": "

We are seeing adoption & deployment of Drone Remote Identification Protocol (DRIP) based on Hierarchical Host Identity Tags (HHITs) adapted from HIP. I am still working to generalize it to multicast & CIDR.

", "time": "2026-07-22T15:02:49.000Z"}, {"author": "David Oran", "text": "

Q: Do consumers as well as producers need to register with the mapping system? if so, how does that square with the (desirable) consumer anonymity property of NDN?

", "time": "2026-07-22T15:12:12.000Z"}, {"author": "Junxiao Shi", "text": "

Only the producers need to register with the mapping system.
\nHowever, it's unclear how this interacts with Reflexive Forwarding.

", "time": "2026-07-22T15:13:44.000Z"}, {"author": "David Oran", "text": "

@Junxiao - thanks

", "time": "2026-07-22T15:14:05.000Z"}, {"author": "David Oran", "text": "

@Junxiao - I suspect one could construct PIT tokens for the reverse tunnel to get to the right ingress router without the consumers to have public identities.

", "time": "2026-07-22T15:16:06.000Z"}, {"author": "Tianyuan Yu", "text": "

Yes consumers do not need to register prefix. The prefixes are for the producers.

", "time": "2026-07-22T15:29:03.000Z"}, {"author": "Kenneth Calvert", "text": "

@Tianyuan Yu, does there need to be a PET entry for every sync application instance (i.e., multicast group)?

", "time": "2026-07-22T15:33:03.000Z"}, {"author": "Tianyuan Yu", "text": "

@Ken, Yes you need to by design. We are working on some on-demand mechanisms so that routers dynamically write popular prefixes into the PET.

", "time": "2026-07-22T15:38:48.000Z"}, {"author": "Kenneth Calvert", "text": "

@Tianyuan, thanks.

", "time": "2026-07-22T15:41:22.000Z"}, {"author": "Junxiao Shi", "text": "

The risk of ABE and ABAC is the lack of well-maintained libraries.

\n", "time": "2026-07-22T15:42:20.000Z"}, {"author": "Lixia Zhang", "text": "

this NDN TR seems relevant to this talk (regarading a layer between app and net, see https://named-data.net/wp-content/uploads/2021/01/NDN-TR-0071-ndn-lite-pubsub.pdf

", "time": "2026-07-22T15:43:58.000Z"}, {"author": "Lixia Zhang", "text": "

the issue of prodiucer and consumer belonging to different trust domains is resolved by inter-domain trust management, see an early poster at ICN 2022, https://dl.acm.org/doi/pdf/10.1145/3517212.3559489

", "time": "2026-07-22T15:49:31.000Z"}, {"author": "Lixia Zhang", "text": "

Ownly adopted IETF standard MLS in the latest Ownly release

", "time": "2026-07-22T15:50:38.000Z"}, {"author": "Tianyuan Yu", "text": "

dev.ownly.work

", "time": "2026-07-22T15:51:08.000Z"}, {"author": "Tianyuan Yu", "text": "

https://datatracker.ietf.org/doc/rfc9420/

", "time": "2026-07-22T15:51:43.000Z"}, {"author": "Lixia Zhang", "text": "

As I said earlier, let's keep the communication channel open and update each other on the latest work. We still run weekly NDN coordination calls that are open to everyone, where we discuss/debate new changes (just join nfd-dev mailing list to receive call agenda every Thursday).
\nBut it is our fault for not reporting NDN updates to the ndn-interest mailing list. We will fix that.

", "time": "2026-07-22T15:55:55.000Z"}, {"author": "David Oran", "text": "

@lixia - it may be valuable for a subset of things that may have wider interest to occasionally post to th eICNRG list as the membership only partially overlaps

", "time": "2026-07-22T15:57:27.000Z"}, {"author": "Lixia Zhang", "text": "

yes we can do that.

", "time": "2026-07-22T15:58:02.000Z"}]