[Qirg] Re: Interest in Advertising Entanglement Capabilities in Quantum Networks Draft

[Rod Van Meter <[e-mail]>]

Hi Melchior (and Kireeti, Stephanie and Cristian),

Speaking personally, for the network architecture we are defining in my 
research group we hope to reuse existing ideas and protocols as much as 
possible, so exploring how to achieve this is valuable.

To be clear, you are proposing using OSPF and/or IS-IS to discover the 
physical topology of the quantum network itself, correct?  You're not 
proposing this as a unified classical+quantum discovery for a shared 
network, right?

Still speaking as an individual, I see a few issues:

1. Naming & addressing: we haven't committed to using IP addresses as 
node identifiers; we are considering node names that are e.g. URNs, 
rather than network interface identifiers that are IP addresses or 
similar.  (Someone smarter than me can hopefully weigh in here, without 
starting a religious war.)

2. Multiplexing: actual selection of path to use for a particular 
connection needs to be tied to some sort of resource allocation 
mechanism, so SPF-calculated nexthop may or may not be appropriate.

3. Multidrop: We are building an optically switched network that can 
connect arbitrary pairs of end nodes within a single Photonic 
Synchronization Domain (PSD), rather like a classical multidrop LAN. We 
might need separate pairwise costs for different pairs, which is 
different from e.g. a shared bus like an Olde Timey Coaxial Thicknet.

There are probably others.

But then, making this *concrete* helps us define these issues and forces 
us to confront them.

So I'd say go for it, but expect it to be a deeper conversation than you 
might be anticipating.

In work done back in the Middle Ages, we proposed "seconds per Bell pair 
of a threshold fidelity" as the link metric for an SPF-derived protocol. 
We only did the theory, not really a protocol.
https://arxiv.org/abs/0705.4128

Sara and Marcello will have a different opinion, since their 
architecture is looking to do dynamic routing on top of individually 
created entangled states, so their view of the topology must be dynamic 
at the level of an RTT (whether link or E2E I'm not sure).

I'm curious what the Delft team is actually using these days, if 
anything. Ditto Argonne, LBNL, Qunnect, etc.

All that said, our own motivation for this is a little lower right now, 
since we are currently building a data center-scale, centrally-scheduled 
system. But of course I want wide-area. capable, truly distributed 
systems, as well.

--Rod

P.S. Likewise, I have considered reviving 
https://datatracker.ietf.org/doc/html/draft-van-meter-qirg-quantum-connection-setup-01, 
but it's relatively lower priority for us right now, compared to the 
documents we are currently working on.

On 2026/03/30 21:56, Melchior Aelmans wrote:
>
> Hi QIRG,
>
>
> Given the momentum and growing interest around quantum network 
> architectures within the QIRG WG, I wanted to briefly gauge whether 
> there would be interest in revisiting and potentially advancing the 
> draft below:
>
>
> https://datatracker.ietf.org/doc/html/draft-kaws-qirg-advent-02
>
>
> While the draft is now roughly six years old—and likely contains 
> outdated terminology, references, and assumptions—the core idea may 
> still be relevant. In particular, it explores the use of link-state 
> routing protocols over classical links in quantum networks, including 
> proposed extensions to IS-IS and OSPF to transport quantum-relevant 
> information (e.g., for the creation and management of entangled pairs).
>
>
> Before considering any concrete updates or revisions, I wanted to ask 
> whether there is interest in the group in further exploring this 
> direction. If so, it could be worth revisiting the draft with a fresh 
> perspective and aligning it with current architectural thinking and 
> terminology.
>
>
> Happy to help drive or contribute to a potential refresh if there is 
> sufficient interest.
>
>
> Best,
>
> Melchior
>
>
> _______________________________________________
> Qirg mailing list [e-mail]
> To unsubscribe send an email [e-mail]