From: Angela Sara Cacciapuoti <angelasara.cacciapuoti@unina.it>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_5B93045B-E2E0-45E9-9BD5-DF31CC3D6F0E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\))
Date: Mon, 28 Sep 2026 14:36:13 +0200
References: <BD32C749-7063-48FC-AEBE-D402773DE433@unina.it>
To: Rod Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>,
        Wojciech Kozlowski <wojciech.kozlowski@surf.nl>
Message-Id: <770C8BF7-F874-47EE-A7D9-E3DB391E2470@unina.it>
Message-ID-Hash: BS4GP7REGFSN2LYAQVDGYSJNS372RLUB
CC: "qirg@irtf.org" <qirg@irtf.org>
Precedence: list
Subject: [Qirg] Re: draft-cacciapuoti-qirg-quantum-native-architecture-01 & Napoli
 architecture in general
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/qirg/xFxA-ePXn_-ZgCtEWwVtSEr7jVA>


--Apple-Mail=_5B93045B-E2E0-45E9-9BD5-DF31CC3D6F0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dear Rod, Dear Wojtek,

Thank you so much for all the time and thought you put into this. We =
really appreciate it.=20

It has helped us clarify several important points and identify a number =
of places where the draft needs to be more precise and revised.

As you (Rod) mentioned, you and Wojtek are broadly aligned on the main =
points, so I thought it would be easier to reply to both of you in a =
single email.

I hope neither of you minds.

This will be a long email too. Sorry about that.

Let me start with the TL;DR and then go through the individual points.

One framing point before the details: the I-D defines architectural =
principles; [5] explores one particular routing realization; and [6] =
proposes a protocol-organization model. Classical mechanisms and =
signaling remain necessary in all three. I will try to keep these levels =
separate below.

>=20
> Da: Rod Van Meter <rdv=3D40sfc.wide.ad.jp@dmarc.ietf.org>
>=20
> Oggetto: [Qirg] draft-cacciapuoti-qirg-quantum-native-architecture-01 =
& Napoli architecture in general
>=20
> Data: 11 agosto 2026 alle ore 11:18:06 CEST
>=20
> A: "qirg@irtf.org" <qirg@irtf.org>
>=20
>=20
>=20
> Hi folks,
>=20
>=20
>=20
> All of this is personal opinions, except for the bit on the use of the
>=20
> word "forwarding".
>=20
>=20
>=20
> I'm going to jump in here with some comments on this draft as
>=20
> well. Sara and Marcello are probably still on vacation and so probably
>=20
> can't reply soon, but I'm heading out on about six weeks of travel
>=20
> myself (starting with a visit to my mother), and wanted to get this
>=20
> out before I go.  Jessica, Caterina, Joaquin and Amar may have
>=20
> independent responses to my comments here, of course.  (Minor
>=20
> editorial note: this was mostly written with "they" rather than "you",
>=20
> as if the authors aren't listening or responding.  My apologies if
>=20
> that bothers you, but this is mostly addressed to a) myself and b) the
>=20
> original authors.)
>=20
>=20
>=20
> I mostly agree with Wojtek's comments on the I-D; I had written about
>=20
> half of this before seeing his comments, and I think we're pretty well
>=20
> aligned.  I especially agree with his comments on justification of
>=20
> scalability, which I think will show up in my comments here.
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmailar=
chive.ietf.org%2Farch%2Fmsg%2Fqirg%2FPpx5rAawj_cUAoVRQ6e0Co6A4MY%2F&data=3D=
05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def789=
80b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874352260%7CUnk=
nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4=
zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DMLTreD7FKcZ2M54=
76xJg77jak0xbTqwbLccclZo4mpc%3D&reserved=3D0
>=20
>=20
>=20
> I went deeper into the associated research papers because I wanted to
>=20
> understand better where the ideas in the draft come from and where the
>=20
> overall effort to create a specification might be going.  Of course
>=20
> ideas and opinions change over time, so just because they wrote
>=20
> something in a paper several years ago doesn't necessarily mean they
>=20
> still think it's the best way to go.  (Or even a fresh paper may
>=20
> represent an exploration of an alternative instead of a fleshing out
>=20
> of a direct part of the architecture.)
>=20
>=20
>=20
> With apologies, this is going to be VERY long (over 5,000 words). It
>=20
> has taken me a lot of work, so I hope that in the end it helps push
>=20
> forward the conversation on Quantum Network and Internet
>=20
> architectures, including helping to identify what's common among some
>=20
> of the candidates and what the differences are, based on differences
>=20
> in assumptions about technological development as well as goals for
>=20
> the system.
>=20
>=20
>=20
>=20
>=20
> TL;DR:
>=20
>=20
>=20
> * I think the main Napoli architecture is a 4G architecture, well =
beyond
>=20
> where the technology will take us for the foreseeable future. (The
>=20
> very latest major paper does have some 1G-like characteristics
> discussed more below.)

Some aspects of the design could indeed have this =E2=80=9C4G=E2=80=9D =
flavor and require technologically demanding capabilities. However, I do =
not think that this characterization applies to the architecture as a =
whole.
Furthermore, the 1G-3G taxonomy describes repeater technologies and =
their error-management capabilities rather than complete network =
architectures. This is also why I think we need to be careful and agree =
on the terminology.

Also, part of the Dynamic-Kernel execution model (Executor and part of =
the Engine) has now been implemented on our deployed, multi-vendor =
quantum internet testbed in Naples. These experimental results are =
currently under review and are not yet public, so we cannot point you to =
a public paper at this stage. Once they become publicly available, we =
will follow up on the mailing list and share them with the members, so =
that we can eventually move forward the discussion in light of the =
experimental evidences.=20

More generally =E2=80=94 and this is perhaps a philosophical difference =
between us =E2=80=94 I do not think that an architecture should be =
constrained only by what the technology can do today. Rather, it should =
try to capture the invariants of the problem: in our case, the =
non-local, consumable, stateful, and dynamically-evolving nature of =
entanglement, together with no-cloning, decoherence, and the unavoidable =
role of classical signaling. Those properties will remain even as =
memories, gates, entanglement rates, and error correction improve.

This does not mean ignoring implementability. Specific mechanisms must =
be assessed against realistic technological assumptions, and the =
architecture should admit progressively deployable realizations. But I =
would distinguish the lifetime of an architectural abstraction from the =
maturity of one particular implementation.
The Internet itself was =E2=80=94 or at least was in part =E2=80=94 =
designed with this ambition: its basic abstractions survived while link =
capacities, processing power, memory, and access technologies changed by =
orders of magnitude over the following decades.
I am not claiming here that we necessarily got the architecture right. I =
am only saying that I would evaluate separately whether the architecture =
captures the enduring properties of the problem and whether each =
proposed realization is feasible within a particular technological =
generation.


>=20
> * The many-long-lived-tunnels method is interesting and bears a lot
>=20
> more research.  It could be a good choice for working around the
> "edges" of a dense core.

I see the analogy =E2=80=94 and we briefly discuss it in the paper you =
label as [4] =E2=80=94 and I agree that this is an interesting direction =
worth investigating further.

There is one distinction worth making, though. A classical tunnel =
creates a virtual adjacency, but packets still traverse the underlying =
multi-hop path whenever data is transmitted. By contrast, once an =
entanglement-enabled link has been established and remains available, it =
provides a directly usable =E2=80=94 and consumable =E2=80=94 =
connectivity resource between remote nodes. So, although the two may =
look similar as overlay abstractions, they are operationally different. =
We return to this distinction later in the email.

>=20
> * Overall, I'm skeptical of packet-based quantum network
>=20
> architectures, but they bear further research and matching to
>=20
> projected technology development.  Lots of smart people disagree
> with me here.

Fair enough, we know this is a fundamental point on which reasonable =
positions differ. The packet abstraction is a deliberate architectural =
choice in our draft. =46rom an architectural viewpoint, a classical =
packet is a structured bit string comprising a header and a payload, =
independently of how those bits are physically encoded. Likewise, we =
view a quantum packet as a structured quantum state =E2=80=94 possibly =
describing a composite system =E2=80=94 organized into a quantum header =
and a quantum payload. In our suite [6], the meta-header has an =
explicitly sequential structure: it contains the service intent followed =
by an ordered, append-only sequence of stamps. Whether these logical =
fields are encoded using one or multiple carriers, one or multiple =
quantum systems, or different degrees of freedom of the same carrier =
lies below the architectural abstraction boundary. The architecture =
specifies their logical decomposition and semantics without committing =
to a particular physical encoding or carrier-level realization. More on =
this below.

>=20
> * Personally, even if you accept the idea of packets for quantum
>=20
> networks, I don't think the in-band, all-quantum packet structure
>=20
> will be a good choice; I don't see any reason for the headers not to
>=20
> be carried over a coordinated classical channel, and carrying them
> in the quantum channel comes with a high cost.

This is probably where we disagree most. I can agree that a coordinated =
classical header may work in controlled environments. My main concern is =
whether a separately maintained classical control field can remain =
consistently aligned with an evolving quantum-resource state in a =
general, dynamic network. Specifically, my concern has two distinct =
parts. First, a control field maintained on a separate classical channel =
requires an explicit mechanism to bind it to the corresponding =
quantum-resource instance and preserve causal alignment as that resource =
is transformed, consumed, lost, or replaced. So association and =
reconciliation semantics have to be provided. Second, a classical field =
may describe a quantum control state, but it cannot itself carry or be =
coherently operated on as that quantum state. This distinction matters =
for abstractions such as Quantum Addressing. More on this below.

>=20
> * The dynamic kernel approach I like; I find it similar to our
>=20
> approach.  It's event-driven, and actions are compiled to physically
>=20
> appropriate actions locally and executed as independently as
> possible.

Thank you! I like it a lot too :) To me, the closest similarity lies in =
the recursive nature. At the same time, there are important differences =
in the state and coordination semantics, which we discuss below.

>=20
> * The active-packet approach (either stamps or superposed addresses),
>=20
> which differs from our RuleSets in that they are carried in the
>=20
> quantum packets rather than stored as connection state at the
>=20
> routers, seems to me to be solving a non-problem, and the cost of the
>=20
> complexity and performance demands introduced are will be the wrong
> tradeoff.

This is closely related to the previous disagreement. I do not see =
resource-state reconciliation as a non-problem.=20
On the contrary, I believe that, beyond controlled environments, =
continuously reconciling a separate classical control representation =
with a distributed and evolving quantum-resource state will itself =
become a barrier to scalability.
More later in the email.

>=20
> * At the end of this tome, there is a little bit of a comparison to
> our architecture.

Detailed response below.

>=20
>=20
>=20
>=20
>=20
> References I worked from to understand the Napoli architecture:
>=20
>=20
>=20
> 1. Angela Sara Cacciapuoti, Marcello Caleffi, Jessica Illiano, C. De
>=20
>  Risi, A. Abane, Joaquin Chung
>=20
>  Quantum-Native Architectural Tenets and Philosophy for the Quantum=20
>=20
> Internet
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr=
acker.ietf.org%2Fdoc%2Fdraft-cacciapuoti-qirg-quantum-native-architecture%=
2F&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b8=
2e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C63922036787437=
6637%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI=
lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Dltoir=
W3Qtb5R7hNOFkEujs1dXLheLLaT99lS64JI7lM%3D&reserved=3D0
>=20
> 2. Marcello's slides covering the -00 version of that draft
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr=
acker.ietf.org%2Fmeeting%2F124%2Fmaterials%2Fslides-124-qirg-design-princi=
ples-for-the-quantum-internet-quantum-control-plane-caleffi-00&data=3D05%7=
C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9=
%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874391482%7CUnknown=
%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI=
sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3D087Ebs7b%2B2oQ0BlDc=
itDEAM2faI5BUUiFgmU5cybU%2BM%3D&reserved=3D0
>=20
> 3. Sara's slides covering the -01 version of that draft
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatr=
acker.ietf.org%2Fmeeting%2F126%2Fmaterials%2Fslides-126-qirg-draft-cacciap=
uoti-qirg-quantum-native-architecture-01&data=3D05%7C02%7Cangelasara.cacci=
apuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e=
328f9da0c45fd%7C0%7C0%7C639220367874405869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB=
0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI=
joyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DlnbjiJANeH2ovvbkg6d4fOTyCOdAqjlUr%2Fo4s%2=
FxrUjo%3D&reserved=3D0
>=20
> 4. Angela Sara Cacciapuoti, Jessica Illiano, Marcello Caleffi
>=20
>  Quantum Internet Addressing
>=20
>  IEEE Network
>=20
>  =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2306.05982&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367874420234%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DbZ5elrq8YO0oC4DQa0MS6BHC%2FmxXQwM2QTBNOS6hrQM%3D&reserved=3D=
0
>=20
> 5. Marcello Caleffi, Angela Sara Cacciapuoti
>=20
>  Quantum Internet Architecture: Unlocking Quantum-Native Routing via
>=20
>  Quantum Addressing
>=20
>  IEEE Trans. Communications
>=20
>  =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fieeexp=
lore.ieee.org%2Fdocument%2F11322738&data=3D05%7C02%7Cangelasara.cacciapuot=
i%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9=
da0c45fd%7C0%7C0%7C639220367874434729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h=
cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ=
%3D%3D%7C0%7C%7C%7C&sdata=3Ddhi3q0sNlcVIKn4W2Y80nHK3cTx%2F3kChUoBwAPNP6i8%=
3D&reserved=3D0
>=20
> 6. Angela Sara Cacciapuoti, Marcello Caleffi
>=20
>  A Quantum Internet Protocol Suite Beyond Layering
>=20
>  IEEE Transactions on Network Science and Engineering
>=20
>  =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdoi.or=
g%2F10.1109%2FTNSE.2026.3679795&data=3D05%7C02%7Cangelasara.cacciapuoti%40=
unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c=
45fd%7C0%7C0%7C639220367874448869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki=
OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%=
3D%7C0%7C%7C%7C&sdata=3DiFT5yJXo6OlNLNtEp%2FQ%2F18HPmIffwjWTlxzF3SRmWp8%3D=
&reserved=3D0
>=20
> 7. Jessica Illiano, Marcello Caleffi, Antonio Manzalini, Angela Sara=20=

>=20
> Cacciapuoti
>=20
>  Quantum Internet Protocol Stack: a Comprehensive Survey
>=20
>  =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2202.10894&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367874463503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DzcDDbecqr%2FEoRFV%2Bz6LSzAbRs24UN5H9F690qjKKpmQ%3D&reserved=
=3D0
>=20
>  (n.b.: this survey doesn't cover their own architecture, and it's
>=20
>  good but now rapidly becoming dated as a lot of work has come out
>=20
>  in the last four years.  But if you need to get oriented, it's
>=20
>  solid place to start.)
>=20
>=20
>=20
> (I also skimmed a couple of others but didn't keep good notes on =
them.)
>=20
>=20
>=20
> Let me oversimplify the assumptions, problem and architectural
> decisions down to about six points:

Your simplification is useful, but I think it combines architectural =
assumptions of the I-D with specific mechanisms explored in [5] and [6]. =
Let me try to separate them.
>=20
>=20
>=20
>=20
>=20
> -1. The key assumptions are that
>=20
> -1.1 high-fidelity entanglement itself is plentiful; and
>=20
> -1.2 execution of quantum programs at quantum nodes
>=20
>  (including routers in the quantum network) is cheap, reliable
>  and low latency.

No, I would not characterize these as assumptions of our architecture. =
The I-D defines architectural principles and abstractions; it does not =
prescribe specific protocols, algorithms, hardware realizations, or =
performance thresholds. Indeed, it is explicitly agnostic to both the =
routing model and the repeater generation. Specific mechanisms explored =
in the related papers =E2=80=94 notably the Grover-based realization in =
[5] =E2=80=94 may require advanced quantum-processing capabilities, but =
those requirements should not be transferred to the architecture as a =
whole.
Of course, every operational quantum-network realization has some =
minimum physical-feasibility conditions: the quantum resources must =
retain sufficient quality for long enough to complete the required =
operations. In a memory-based realization, for example, the available =
memories and coherence times must be adequate for the relevant protocol =
timescales. If they are not, that realization cannot work =E2=80=94 but =
this is true for any quantum-network architecture. It is not equivalent =
to assuming that high-fidelity entanglement is plentiful or that quantum =
computation at every router is cheap, reliable, and low latency. We will =
revise the wording of the draft wherever it may suggest otherwise.

>=20
> 0. The key challenge in designing quantum networks is achieving
>  scalability in managing quantum entanglement.

Yes, agree.

>=20
>=20
>=20
> 0.1. Excessive per-connection state passing through central routers
>  doesn't scale.

Not quite. Our concern is not primarily the amount of per-connection =
state or the processing capabilities of classical routers.=20
It is the association and causal-consistency problem introduced when a =
classical control representation is maintained separately from a =
non-local and dynamically evolving quantum-resource state, across both =
the nodes sharing the resource and the functions acting on it.

>=20
> 0.2. Path length has higher impact in quantum networks than in =
classical
>=20
>  networks, so it is crucial to minimize the use of "stretched" paths
>=20
>  that are longer than the minimal path between two nodes.
>=20

I would not state this as an assumption or requirement of the =
architecture. The routing mechanism you discuss later belongs to [5], =
not to the I-D. That paper provides one constructive example showing =
that a control plane grounded in quantum abstractions =E2=80=94 such as =
quantum addressing =E2=80=94 can support a routing mechanism with =
constant entangling stretch and sublinear routing-table size. Neither =
this routing mechanism nor stretch minimization is mandated by the I-D.

More generally, [5] is intended as one concrete example of what becomes =
possible when the control plane can represent and manipulate network =
information natively as quantum states, rather than being restricted to =
classical representations. It demonstrates one capability enabled by =
this design choice. Iit does not prescribe that capability as an =
architectural requirement. Let me also clarify why we chose compact =
routing as the case study. We were not trying to argue that =
routing-table growth or path stretch is necessarily the most pressing =
problem for a future Quantum Internet =E2=80=94 or, for that matter, for =
today's classical Internet.

Rather, compact routing provides a particularly useful benchmark because =
it exposes a fundamental and extensively studied trade-off in classical =
routing: reducing routing state while controlling the resulting path =
stretch. Starting from such a well-characterized classical problem =
allows us to ask a sharper question: does changing the nature of the =
information that the control plane can represent and manipulate change =
what can be achieved?

This is particularly relevant to [5]. To the best of our knowledge, [5] =
provides the first compact-routing construction achieving fully =
name-independent routing without relying on an underlying name-dependent =
scheme. Hence, node identifiers remain topology-agnostic: compactness is =
not obtained by embedding topological information into the addresses. =
Instead, Quantum Addressing enables sets of node identities to be =
represented and manipulated natively as quantum states, and the routing =
construction exploits this additional capability.

This was also very much in the spirit of a question that arose =
repeatedly in the early QIRG discussions, particularly from participants =
coming from the classical networking community: what can a quantum =
network actually do that cannot be done by a classical network? Our =
formulation of this question is whether the =E2=80=9Cquantumness=E2=80=9D =
can enable network functions or control abstractions that are =
unavailable when the network is restricted to classical information and =
operations. [5] was intended to provide one concrete, constructive =
example in this direction. We deliberately chose a classical networking =
problem with a long research history so that the distinction could be =
made explicit and evaluated against a well-established theoretical =
baseline.

So I think we actually agree that compact routing need not be a pressing =
operational concern for today's Internet, nor necessarily the dominant =
routing concern for a future Quantum Internet. That is not the point [5] =
was intended to establish. Its role is to demonstrate that, once =
=E2=80=9Cquantumness=E2=80=9D is admitted into the control plane, the =
resulting design space need not be limited to classical control =
mechanisms.


>=20
> 1. The unit of communication is the quantum packet, which is
>=20
>  "forwarded" across entangled tunnels, although the stated goal is to
>=20
>  create E2E entanglement for end nodes; I don't quite understand yet
>=20
>  how forwarding and entanglement swapping interact in this
>  architecture.

Entanglement swapping is one of the operations included in our =
generalized forwarding semantics. This is also consistent with the =
routing/forwarding decomposition adopted in the survey by Amar et al. =
that you cite later. There, quantum forwarding is explicitly =
distinguished from classical hop-by-hop packet forwarding: it comprises =
elementary-entanglement generation and entanglement swapping =E2=80=94 =
and, where needed, purification and robustness mechanisms =E2=80=94 to =
establish end-to-end entanglement. In our terminology, swapping consumes =
existing entanglement resources to extend or reconfigure entanglement =
connectivity. A quantum packet may therefore progress through local =
transformations and, when required, inter-node transfers. In this sense, =
swapping and forwarding are not alternative mechanisms: swapping is one =
of the mechanisms through which generalized quantum forwarding can be =
realized.
Hence, the term generalized forwarding should not be understood as an =
unchanged object transported across classical-like paths.

>=20
> 2a. Routers should maintain large numbers of long-lived virtual
>=20
>  tunnels, which are multihop router-to-router connections that they
>=20
>  continually restock with Bell pairs.  (n.b.: The authors don't
>=20
>  usually use the term "tunnel", but I think it's helpful here, and
>  they usually use the term EPR rather than Bell pair.)

This is close, but I would make two clarifications. The two-tier =
organization described in the I-D does allow ESPs proactively =
maintaining entanglement resources among one another. However, what they =
maintain should not be understood as a set of long-lived classical-like =
tunnels that are continuously stocked with guaranteed Bell pairs. The =
maintained object is an entanglement-enabled connectivity relation, not =
a guarantee that a fixed number of Bell pairs is continuously available =
between ESPs. The individual entanglement resources realizing that =
relation are volatile, consumable, may decohere, and are not guaranteed =
to be continuously available. Thus, =E2=80=9Cmaintenance=E2=80=9D here =
should be understood as maintaining the capability to provide that =
entanglement-enabled connectivity, rather than continuously restocking a =
persistent tunnel to some guaranteed level.
There is also a second, architectural point. Section 8.1 makes the =
broader architectural abstractions compatible with both proactive and =
reactive entanglement-generation regimes. Proactive maintenance is =
therefore one realization described in the draft, not a requirement =
imposed by the architecture on every implementation.


> 2b. E2E connections are routed through these tunnels, minimizing the
>  number of virtual hops and possibly applying other cost metrics.

This describes the specific routing mechanism in [5], not an =
architectural requirement of the I-D. The draft deliberately does not =
prescribe a routing algorithm, a cost metric, or the minimization of =
virtual hops. Even in [5], I would not say that connections are routed =
through tunnels in the classical sense. Routing operates over an =
entanglement graph by selecting e-hops and manipulating the associated =
entanglement resources according to the adopted entangling-cost metrics.

>=20
> 3. The normal per-packet processing of headers, including selecting
>  the nexthop, should all be done utilizing quantum computation.

In the specific routing mechanism in [5], yes

>=20
> 4. Each quantum packet should carry "stamps", which are state for the
>=20
>  processing of the packet itself.  The stamps essentially represent
>=20
>  program fragments, processed via a Plan of Action constructed
>  independently at each node along the path from the set of stamps.

Partly. Stamps belong to the mechanism described in [6], not to the =
architectural principles defined by the I-D. They are appended to the =
packet=E2=80=99s meta-header, but I would not describe them as program =
fragments. A stamp is an append-only record certifying the outcome of an =
action at an action-commit boundary: it records what has already =
happened; it does not prescribe what should happen next.

At each node, the node-local Dynamic Kernel constructs a speculative =
local Plan of Actions from the service intent, the accumulated stamps, =
and the node=E2=80=99s current internal state. The PoA contains the =
candidate node actions, whereas the stamps provide the minimal =
authoritative execution history that subsequent nodes will exploit. The =
PoA itself is never carried in the packet: each node constructs it =
locally according to its capabilities and currently available resources.

We have now implemented and simulated an executable specialization of =
this behavior in our open-source Q2NS/ns-3 simulator, over repeater =
chains with up to 1000 nodes (https://zenodo.org/records/22092701). The =
results confirm that the meta-header growth is bounded by the number and =
granularity of the logical actions that actually reach an action-commit =
boundary during service fulfillment.

More precisely, the required committed-action sequence is determined =
jointly by the service intent, the adopted policy, the capabilities of =
the participating nodes, and the resources already available in the =
network. Once the service semantics, policy, and admissible actions are =
fixed, an upper bound on the meta-header growth can therefore be derived =
before execution; the actual size reached at runtime depends on which =
actions are required under the encountered resource and capability =
conditions.
Therefore, =E2=80=9Cbounded=E2=80=9D does not mean constant with network =
size. It means that the meta-header contains only the finite execution =
history logically required to bring that service instance to success or =
failure, rather than an ever-growing record of retries, speculative =
plans, or transient state.

>=20
>=20
>=20
> There's a lot more to it than just this, but I think those capture the
>=20
> essential ideas.  I wish I could better articulate this in terms of =
the
>=20
> problems being solved, but I'm not sure I really can yet.
>=20
>=20
>=20
> Let's set aside the <-1> assumptions for the moment, but they underlie
>=20
> a lot of the following work, and represent probably the biggest
>=20
> divergence from my own thinking.
>=20
>=20
>=20
> The challenges in <0> above are reasonable concerns. Let's look at =
them:
>=20
>=20
>=20
> <0.1> As it happens, I worry a lot less about the amount of classical =
state
>=20
> needed to support a quantum connection (even in our rather active,
>=20
> distributed computation-oriented architecture) than I do about the
>=20
> availability of entanglement to be shared among a set of E2E
>=20
> connections passing through a node, regardless of whether the
>=20
> connection is designed to use classical state at routers or not. That
>=20
> is, personally I think <-1.1> won't be a valid technological point for
>=20
> a long time yet.
>=20
>=20
>=20
> I did just a little asking around, and while the people I asked didn't
>=20
> have published numbers yet, it seems that a router at an IXP can
>=20
> expect to see several million IP flows passing through over the course
>=20
> of a minute.  That's a lot, but the memory for connection state
>=20
> wouldn't be a problem; the challenges would be doing the per-packet
>=20
> processing at line rate, and managing buffer space properly if it is
>=20
> anything other than FCFS.  With quantum event rates FAR lower (six
>=20
> orders of magnitude? more?), the processing isn't the problem, but
>=20
> buffer space management is indeed a big deal and an open area of
>=20
> research.
>=20

I think your argument addresses a different scalability problem from the =
one we mean in I-D.=20

I agree with you that storing classical per-connection state is unlikely =
to be the main technological bottleneck, particularly when quantum-event =
rates are so much lower than classical packet rates. I also agree that =
quantum-memory availability, coherence constraints, and the allocation =
of scarce entanglement among competing connections are major open =
problems. We are not assuming those problems away.

But that is not the scalability problem we mean. Our concern is neither =
the number of bits needed to describe a connection nor the computational =
capacity of a router to process those bits.=20
It is the additional binding and causal-consistency obligation =
(reconciliation) introduced when a classical control representation is =
maintained separately from the quantum-resource state to which it =
refers.

The comparison with the number of IP flows through an IXP does not quite =
capture this distinction.=20
An IP flow does not normally require every router along its path =E2=80=94=
 and potentially additional remote nodes =E2=80=94 to maintain =
synchronized copies of the descriptors of an evolving, non-local =
resource state. Classical forwarding state is locally readable, =
copyable, and independently updateable. Entanglement is different: it is =
shared across nodes, cannot be locally inspected as an ordinary state =
variable, and can be consumed or reconfigured by operations performed at =
one of the participating nodes.

Take a simple swapping operation. Before the swap, the relevant =
resources may be the (A!-!B) and (B!-!C) entanglement relations. After =
the operation at (B), those resources have been consumed and a new =
(A!-!C) relation has been created, subject to the measurement outcome, =
corrections, fidelity, and remaining coherence budget. Any separately =
maintained classical representation must now reconcile (record and =
causally associate) that transition across the affected nodes and any =
controller or protocol function relying on it. Until that reconciliation =
completes, different entities may reason from different views of =
resource availability, ownership, or partner identity. With multipartite =
entanglement and concurrent operations, the number of affected =
dependencies becomes even larger.=20

Lower quantum-event rates certainly reduce the absolute processing load, =
but they do not remove this reconciliation problem. The relevant =
quantity is not simply events per second; it is whether the classical =
representation can be updated and disseminated before it becomes stale =
relative to resource consumption, decoherence, and subsequent control =
decisions. In fact, when entanglement is scarce, an inconsistent =
reservation or a decision based on a resource that has already been =
consumed is more=E2=80=94not less=E2=80=94costly. So entanglement =
scarcity and state reconciliation are distinct problems, but they =
interact.

In particular, I think that a classical representation can be reconciled =
in a small, controlled environment with bounded concurrency, known =
participants, and tightly managed timing. My concern is whether the same =
approach remains viable in a general, dynamic, heterogeneous, and =
eventually multi-domain network, where local quantum operations =
continuously alter shared resource relations. I do not see router memory =
capacity or per-event processing speed as answering that question.

This is also why our proposal does not try to eliminate classical =
signaling =E2=80=94 measurement outcomes, acknowledgments, and =
synchronization messages are obviously still required. The aim is =
instead to reduce the scope over which correctness depends on =
reconciling a separately maintained classical description with evolving =
quantum-resource states.=20

In the Dynamic-Kernel approach, each node plans from its local resource =
state together with the minimal, authoritative procedural commit history =
carried by the packet. Distributed operations may still use classical =
signaling internally, but their partial outcomes remain local; only =
terminally committed outcomes become visible to subsequent processing.

So I completely agree that quantum-buffer management and entanglement =
availability deserve substantial research. I would just keep them =
separate from the issue raised in I-D: even if router memory and =
processing were effectively free, a separately maintained description of =
a non-local quantum resource would still introduce a distinct =
consistency and timeliness requirement.

As said, the issue we are targeting becomes even more apparent when we =
move beyond bipartite entanglement. Consider, as an architectural stress =
case, two distributed multipartite states =E2=80=94 for example, graph =
states =E2=80=94 each shared among remote nodes, that are manipulated =
and hence transformed through an operation involving only a subset of =
their participating nodes.

The operation may involve only a few nodes, but its consequences need =
not remain confined to those nodes. It can change the structure and =
identity of a quantum resource shared across tens or, eventually, =
hundreds of participants=E2=80=94or, recalling Kleinrock's seminal 1975 =
vision of computer networks at scale, perhaps even thousands.

A separately maintained classical representation would then have to =
capture considerably more than the equivalent of "a swap succeeded." It =
would have to identify which distributed resource instances were =
consumed or transformed, what new resource resulted, which nodes =
participate in it, and which subsequent operations are causally =
permitted to act on that resource. At the same time, other operations =
may be taking place concurrently on different parts of the same =
distributed state or on resources that overlap with it.

None of this means that maintaining such a classical description is =
impossible in principle. The architectural question is different: over =
what scope, with what consistency guarantees, and within what time =
bounds must that description be reconciled before other nodes or =
protocol functions can safely make decisions based on the resulting =
resource? Or, putting the question more simply: as the network scales in =
the number of nodes, distributed resources, concurrent operations, and =
administrative domains, is maintaining and reconciling a separate =
classical description of those evolving non-local quantum resources the =
abstraction on which we want the scalability of a general-purpose =
Quantum Internet to depend?

This is why we view the issue as more fundamental than classical memory =
capacity or per-event processing rate. In a network built primarily =
around independently managed Bell pairs, the reconciliation problem can =
look like bookkeeping among a small number of endpoints and intermediate =
nodes. Multipartite entanglement makes the distributed nature of the =
problem much more explicit: an operation involving only a subset of the =
participating nodes can alter the semantics of a quantum resource whose =
identity and operational relevance extend across the distributed system.

This is precisely the kind of architectural scaling question that the =
I-D is intended to expose. We are not claiming that classical =
descriptions cannot be maintained, nor that classical signaling can or =
should disappear. We are asking whether correctness should continue to =
depend on maintaining only a separate classical representation that must =
track, with sufficient timeliness and causal consistency, an =
increasingly dynamic set of non-local quantum resources as the network =
scales.


>=20
> <0.2> I agree, we should be working to minimize the amount of "work"
>=20
> needed for each E2E connection.  That's one of the key metrics we
>=20
> looked at back in our path selection paper
>=20
> =
[https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv=
.org%2Fabs%2F1206.5655&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367874484564%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DXWUr8ssyQdrHO3Fbd7%2Fr2Fxzu14dL2I%2FIuThFsppmEg%3D&reserved=
=3D0].  But I don't think that the
>=20
> "stretching" of paths due to shortcomings in the addressing and
>=20
> routing architecture are as big a concern as the Napoli team does.
>=20
>=20
>=20
> One key reference they keep coming back to is
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F0708.2309&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7=
Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7=
C0%7C639220367874504653%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl=
YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%=
7C%7C&sdata=3DIUBnHX3vukgE1cbXsHphE9fa5trIwHg0Hy3yUCFiXlU%3D&reserved=3D0.=
  That particular paper is
>=20
> interesting, but doesn't seem to me to be very mainstream; it has some
>=20
> 2007 opinions about how the Internet was evolving that in the end seem
>=20
> not to have happened over the last 20 years.
>=20
>=20
>=20
> One of the authors of that is kc claffy, who is one of the most
>=20
> important people in Internet measurement and (interesting side note to
>=20
> me, at least!)  got her start during an extended visit to Japan and
>=20
> whose first paper was with T. Asaba, Jun Murai and Osamu Nakamura.
>=20
>=20
>=20
> Anyway, the Krioukov paper is on "compact routing", which is not a
>=20
> term you will hear from Internet people much. What it appears to mean
>=20
> is worrying about routing table growth and address aggregation for
>=20
> routing purposes.  The canonical place to learn about that these days
>=20
> is probably Geoff Huston's annual blog entries for APNIC, most
>=20
> recently =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fblog.a=
pnic.net%2F2026%2F01%2F08%2Fbgp-in-2025%2F&data=3D05%7C02%7Cangelasara.cac=
ciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b=
1e328f9da0c45fd%7C0%7C0%7C639220367874520568%7CUnknown%7CTWFpbGZsb3d8eyJFb=
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld=
UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DyRG%2BEFc3fLjPohRGFZRj2F3Effv9BYrGJnGnU=
lVLiw0%3D&reserved=3D0
>=20
> The IPv4 table is now a little over a million entries, which is a lot
>=20
> but not the disaster it was feared to be twenty years ago.
>=20
>=20
>=20
> The "compact routing" folks fear that keeping the routing table size
>=20
> manageable means selecting suboptimal routes that result in
>=20
> "stretching" a path.  AFAICT, this is in truth a non-issue in today's
>=20
> Internet, but the Napoli team worries about it in their quantum
>=20
> network design.
>=20
>=20
>=20
> So, I think it's reasonable to expect that quantum networks can select
>=20
> a "best" path for the foreseeable future.  The survey by Amar &
>=20
> friends is great =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fieeexp=
lore.ieee.org%2Fdocument%2F10882978&data=3D05%7C02%7Cangelasara.cacciapuot=
i%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9=
da0c45fd%7C0%7C0%7C639220367874536843%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h=
cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ=
%3D%3D%7C0%7C%7C%7C&sdata=3DIHmjx5HmZVEkENbPOrJvqPTUd1UL5AST2LI3dISWVJA%3D=
&reserved=3D0.  I
>=20
> think the big question right now is not the abstract, graph-theoretic
>=20
> problem of path selection, but instead how to integrate path selection
>=20
> and resource management/access multiplexing.  We did some preliminary
>=20
> work on that long ago
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Faqua.s=
fc.wide.ad.jp%2Fpublications%2FAparicio-master-thesis.pdf&data=3D05%7C02%7=
Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2f=
cfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874856572%7CUnknown%7CTW=
FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO=
IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DrV9kYpxzNxpju45NFqQQCOPi=
cZdIsPoH5QmlbNjEbJY%3D&reserved=3D0
>=20
> and some in the restricted environment of a data center network/LAN
>=20
> just recently in =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2605.07295&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367874874482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DgRKrbJI6gncOLY%2Fq2Y2dPR%2BgASBqwILGTN5lh6b6djY%3D&reserved=
=3D0 (which will be
>=20
> presented next month at IEEE QCE).  There are some other people out
>=20
> there working on this, as well, and I'm falling behind on the
>=20
> literature here; both the Napoli team and a couple of other things
>=20
> I've read recently have references I hadn't seen before, such as
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fieeexp=
lore.ieee.org%2Fdocument%2F10575563%2F&data=3D05%7C02%7Cangelasara.cacciap=
uoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e32=
8f9da0c45fd%7C0%7C0%7C639220367874890130%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e=
U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo=
yfQ%3D%3D%7C0%7C%7C%7C&sdata=3DvEktV4tDhYubpQA0lkj04xVwVIK4GjHLmfixe03eic8=
%3D&reserved=3D0.
>=20
>=20
>=20

I think this is another point where our motivations may have become =
crossed. Path stretch is not what motivates the I-D.

In [5], we use compact routing as a concrete case study: once the =
control plane is grounded not only in classical abstractions but also in =
quantum ones, such as Quantum Addressing, we can construct a routing =
protocol with sublinear quantum routing-table size and entangling =
stretch bounded by a constant. To be clear, we are not claiming that =
classical abstractions are unnecessary. Our claim is that they need to =
be augmented with quantum abstractions.
These routing properties are results of the specific mechanism developed =
in [5], not architectural requirements of the I-D. The mechanism is =
therefore discussed in [5], while the I-D deliberately stops at =
architectural principles and does not prescribe a routing protocol.

But the more fundamental point is neither table size nor routing itself. =
The confusion may come from our own wording in the I-D, which still =
presents Quantum Addressing mainly through routing and forwarding =
examples. We should make its broader role clearer in the next revision.

The departure we propose is semantic. A conventional control plane =E2=80=94=
 which is concerned with routing, configuration, management, policy =
enforcement, and resource coordination =E2=80=94 performs these =
functions through classical representations. Our Quantum Control Plane =
retains those classical mechanisms while augmenting them with =
quantum-native abstractions that can be encoded and operated on as =
quantum states. Classical abstractions and classical signaling remain =
necessary: they are complemented, not replaced.
Quantum Addressing is one such abstraction, but it is neither restricted =
to routing nor intended to represent the entire quantum control =
structure. It can represent and support operations on sets (via =
superposition) of candidate nodes, paths, or domains and can therefore =
contribute to resource selection, distributed coordination, and service =
fulfillment =E2=80=94 not only to next-hop computation. We still need =
both the physical-network view and the dynamically evolving entanglement =
view.

Recent work on quantum-enabled clock synchronization and networked =
quantum metrology provides a useful precedent. Quantum states and =
nonclassical correlations =E2=80=94 and, depending on the protocol, =
entanglement =E2=80=94 are used as operational resources for a =
network-relevant coordination function. Some experimental protocols =
combine photon correlations with classical communication and =
post-processing, which is actually close to the point we are making: =
quantum resources augment rather than eliminate classical mechanisms. =
The narrower analogy is that quantum resources need not merely be =
represented and managed by a control mechanism; they can participate in =
performing the coordination function.

[6] provides an example at a different architectural level. It is a =
protocol suite organized around dynamic composition that allows the =
network to complete a requested service through distributed, node-local =
execution. Its meta-header contains the service intent =E2=80=94 =
including the participating nodes expressed through Quantum Addresses =
=E2=80=94 and the accumulated action-commit stamps. Each Dynamic Kernel =
uses this information, together with its local state, to construct and =
execute a local Plan of Action. As these local actions commit, the =
service progresses toward completion.

Quantum Addressing is therefore one component of the meta-header, not =
the whole control structure. The stamps serve a different purpose: they =
provide the authoritative procedural execution history that allows =
subsequent nodes to determine what remains to be done. Also, this =
packet-carried procedural control should not be confused with external =
QCP/EDC orchestration, which may provide optional policies or hints but =
is not required for the correctness of service completion in [6]. The =
structural gain here is that no continuously refreshed global execution =
plan is required: only committed outcomes cross node boundaries through =
the packet-carried history.

A separately maintained classical control field (classical header) could =
certainly be considered, but it would still need an explicit association =
and reconciliation mechanism to remain aligned with the evolving quantum =
resource to which it refers. This implies that the alignment problem =
still has to be solved.

Seen in this way, [5] and [6] illustrate quantum-native abstractions at =
two different levels. [5] uses Quantum Addressing within a control-plane =
routing mechanism operating over the entanglement graph. [6] embeds =
Quantum Addressing within a richer in-band control structure used by a =
dynamically composed protocol suite to complete a requested service.

So yes, I agree that integrating path selection with resource management =
and access multiplexing is an important problem, and your earlier metric =
could be instantiated within the more general entangling-cost =
formulation used in [5]. It is simply not the motivation for the draft. =
Our architectural thesis is broader: limiting control semantics to =
classical representations introduces an additional association and =
reconciliation requirement and prevents quantum states and operations =
from being used natively as control abstractions.=20

Saying with different words, separating procedural control from an =
evolving quantum resource introduces an additional association and =
causal-consistency requirement that could become a scalability =
bottleneck. And, restricting the control plane to classical =
representations prevents it from natively preserving and coherently =
operating on genuinely quantum control variables. This semantic =
capability motivates augmenting =E2=80=94 not replacing =E2=80=94 =
classical control with quantum-native abstractions. [5] and [6] provide =
two concrete examples of the resulting design space.

>=20
> ** Quantum Packets **
>=20
>=20
>=20
> <1> Quantum packets: here's where I get stuck most on understanding
>=20
> the architecture.  With apologies to the authors, even after reading
>=20
> the above, I'm not quite sure what constitutes a packet and how it
>=20
> moves through the network.  Maybe my brain is working from too
>=20
> different a point of view.  But the most up-to-date reference [6] is
>=20
> also, happily, the most concrete on processing.  It provides some
>=20
> information on how the metadata in the packet is created and updated,
>=20
> how a packet is processed and how it moves through the network.
>=20
>=20
>=20
> I am unclear on whether a packet is believed to be reliably delivered.
>=20
> Some of the papers pay a lot of tribute to early datagram work from
>=20
> the 1970s, so I think maybe the packets are assumed to be unreliable.
>=20
> Moreover, somewhere they mentioned that since we are building E2E
>=20
> entanglement, it's okay to drop some things because they aren't
>=20
> carrying valuable data.  However, given how much work goes into each
>=20
> packet, this might be a poor choice.
>=20
>=20
>=20
> The figure from Sec. 5 of [1]:
>=20
>=20
>=20
>=20
>=20
> +---------------------------------+----------------------------------+
>=20
> |       Quantum Header            |     Quantum Payload     |
>=20
> +---------------------------------+----------------------------------+
>=20
> |   - Quantum Address |A>         |  - Entangled qubits |e_i>        |
>=20
> |   - Optional metadata           |   (bipartite or multipartite)    |
>=20
> +---------------------------------+----------------------------------+
>=20
>=20
>=20
> (Here's hoping the ASCII art figure survives modern mail writers &
>=20
> readers.)
>=20
>=20
>=20
> This is simplified and a little different from Fig. 3 in [5], which
>=20
> includes:
>=20
>=20
>=20
> header:
>=20
> - src addr: x_i
>=20
> - dst addr: x_j
>=20
> - an array of address structures, |A> =3D |A_j^1>,|A_j^2>,|A_j^3>...
>=20
> **each of which is a weighted superposition of node addresses**
>=20
> payload:
>=20
> - an array of qubits: |e_1>,|e_2>,|e_3>...
>=20
>=20
>=20
> Note that x_i and x_j are *classical*, single-valued addresses; any
>=20
> given packet has exactly one source and one destination address.
>=20
> However, these addresses are encoded in qubits, such that the entire
>=20
> packet can all be viewed as a single block of qubits.
>=20
>=20
>=20
> However, the next set of header fields (which I think is what is
>=20
> called "metadata headers" or "meta-headers" in some of the papers and
>=20
> in the figure above?) *is* in a weighted superposition.  This is very
>=20
> likely the source of the confusion over whether or not the Napoli
>=20
> architecture is proposing that destination addresses be in
>=20
> superposition in a way that "splits" quantum amplitude over a set of
>=20
> destinations, as at least some of the Innsbruck papers propose
>=20
> =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.n=
ature.com%2Farticles%2Fs41534-021-00472-5&data=3D05%7C02%7Cangelasara.cacc=
iapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1=
e328f9da0c45fd%7C0%7C0%7C639220367874909588%7CUnknown%7CTWFpbGZsb3d8eyJFbX=
B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU=
IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3Dp0KZF%2B2h1EbccO51AFYA9Q2Vlv8ui68tr1luZ4=
49HAc%3D&reserved=3D0).
>=20
>=20
>=20
> [Edit: I now think Fig. 3 of [5] is incorrect.  See more on this
>=20
> below, but I'm keeping the description here just in case I'm wrong
>=20
> about it being wrong, and to help others understand where I went wrong
>=20
> if I'm right about it being wrong. (Confused yet?  So am I.)]
>=20
>=20
>=20
> I'm a little unclear on whether |A> in the I-D figure above [1] is
>=20
> supposed to be the same as |A> in [5].  I think not.
>=20
>=20
>=20
> Focusing on the |A> from [5], it appears to be a *complete routing
>=20
> table for the network*, carried *in the packet itself*.  This is a
>=20
> striking design choice, with implications that echo through all of the
>=20
> architecture.  I'm also not entirely certain I've understood it right.
>=20
>=20
>=20
> Note that |A> is *not* a source route header, a la RFCs 5095
>=20
> (deprecating part of RFC 2640), 6275, or 6554, or like SRv6 (described
>=20
> in a whole plethora of RFCs including 8754).  I actually don't see why
>=20
> this couldn't be a source route, which would simplify all of the
>=20
> processing and allow this meta-header to be carried in the classical
>=20
> channel.  If you don't like stateful connections and are worried about
>=20
> path selection overhead, this can help, but it doesn't solve the
>=20
> scalability problem of having most of the network nodes know a LOT
>=20
> about the network topology; in fact in might make it worse.
>=20
>=20
>=20
> But sticking with the proposed structure, here's what I understand
>=20
> (which might be wrong).  (This idea is also tied up with the
>=20
> many-tunnels notion, which we'll defer for a bit, so part of this is
>=20
> oversimplified.)
>=20
>=20
>=20
> Sec. II-D of [5] says, "[F]orwarding decisions...[are]...enabled by a
>=20
> quantum header in the packet, as illustrated in Fig. 3, which carries
>=20
> the quantum equivalent of source-destination addresses. This approach
>=20
> generalizes 'next-hop' selection in the quantum realm by applying
>=20
> appropriate quantum operations to quantum addresses in routing tables,
>=20
> thereby eliminating classical header parsing."  Then the caption to
>=20
> Fig. 3 says, "Quantum packet structure. The header carries quantum
>=20
> information for the quantum routing logic, such as source-destination
>=20
> quantum network address |x_i>, |x_j>, and quantum superpositions
>=20
> |A_j>, representing set of quantum nodes introduced in Sec. IV-B,
>=20
> while the payload carries entangled qubits (ebits) to be shared among
>=20
> network nodes."
>=20
>=20
>=20
> I now think that that description surrounding the packet structure in
>=20
> Fig. 3 is wrong, that |A_j> is *held at the router nodes*, not
>=20
> included in the packet.  Also note that the packet figure in the I-D
>=20
> (the ASCII figure reproduced above) is simpler and does not appear to
>=20
> include the routing information.
>=20
>=20
>=20
> Assuming those qubits labeled ebits are locally buffered at the router
>=20
> (as discussed next), I'm now back to not understanding what a "packet"
> is in this architecture.


Rod, no apologies needed: these are very useful comments. I think, =
however, that three different levels are being mixed here: the =
architectural packet abstraction in the I-D, the specific routing packet =
used in [5], and the packet realization used by the protocol suite in =
[6].

The packet structure in the I-D is deliberately more general than the =
one in [5]. The I-D defines only the architectural boundary: a quantum =
packet has a quantum header carrying addressing and other control =
information, and a quantum payload carrying the quantum resources on =
which the network operates. It does not prescribe the fields required by =
a particular routing mechanism, protocol suite, or service. The =
structure can therefore be specialized according to the network function =
being implemented.

[5] provides one such specialization for its quantum-routing mechanism. =
There, =E2=88=A3xi=E2=9F=A9 and =E2=88=A3xj=E2=9F=A9 are quantum =
addresses represented by computational-basis states.They are perfectly =
distinguishable quantum states that encode one source and one =
destination in that particular realization.

The =E2=88=A3Ajl=E2=9F=A9 fields have a different role. Each of them =
represents one partition of the e-neighborhood of a particular ESP vj. =
They are announced by vj as routing-control information and therefore =
belong in the quantum header rather than in the payload. Once received, =
this information can be retained in the corresponding local =
routing-table entry. Thus, being carried in a packet when announced and =
being stored at a router for subsequent queries are not mutually =
exclusive.

They are also not a complete routing table carried inside every packet, =
and they do not encode the complete entanglement graph. They describe =
scoped e-neighborhood information associated with a particular e-hop. =
The complete local routing table contains multiple entries and remains =
at the ESP.
So I do not think Fig. 3 of [5] is wrong in the sense you suggested.

Also, =E2=88=A3A=E2=9F=A9 in the I-D should not be identified one-to-one =
with the complete field structure used in [5]. In the I-D, it denotes =
the more general Quantum Addressing abstraction. In [5], that =
abstraction is specialized into source and destination address fields =
and superposed e-neighborhood fields for a particular (compact) routing =
mechanism. In [6], it is embedded in an even broader meta-header: =
Quantum Addresses identify the participants in the service intent, while =
the meta-header also carries the other intent parameters and the =
accumulated action-commit stamps.

The superposed e-neighborhood fields in [5] should also not be =
interpreted as splitting the packet payload across several destinations, =
as in the Innsbruck proposal. In [5], the superposition is used as a =
control structure: the routing logic queries whether the target address =
belongs to one of the represented e-neighborhoods and selects the =
corresponding e-hop. The payload does not enter a superposition of =
destinations merely because a header field contains a superposition of =
node identifiers.
For the same reason, =E2=88=A3Ajl=E2=9F=A9 is not a source route. A =
source route carries an ordered sequence of nodes through which a packet =
should pass. A classical source route could certainly be studied as =
another routing mechanism=E2=80=94the I-D does not exclude it=E2=80=94but =
it would not be a different encoding of the same mechanism in [5]. It =
would replace local quantum-address processing with a precomputed path =
that would still have to remain valid with respect to the evolving =
entanglement graph.

As to what it means for a quantum packet to =E2=80=9Cmove,=E2=80=9D =
Generalized Quantum Forwarding should be understood as a forwarding =
abstraction, rather than as a single primitive operation or merely the =
physical transmission of a carrier from one node to another. It captures =
the overall semantics by which a packet is processed and advanced: the =
relevant header or meta-header information is processed to determine the =
applicable actions; the payload and its associated entanglement =
resources may be transformed, consumed, or left unchanged; and, when =
required, the resulting packet is transferred to the selected next node. =
A quantum packet therefore progresses logically through a combination of =
local transformations and inter-node transfers. This does not imply that =
the same immutable block of qubits=E2=80=94or even the same physical =
carriers=E2=80=94traverses every physical link.

The protocol suite in [6] makes the above distinction concrete. =
Processing at a node may update the meta-header through action-commit =
stamps and manipulate the payload as service fulfillment progresses. =
ACT_FORWARD(nh) is the specific action that transfers the resulting =
packet=E2=80=94and the authority over its meta-header=E2=80=94to the =
selected next node. The actual sending of the packet is therefore one =
action within generalized forwarding, not its complete definition. This =
is consistent with [5], where packets carrying locally held members of =
EPR pairs are propagated through sequences of quantum operations rather =
than merely through transmission over physical links.

On reliability, the I-D does not prescribe either a reliable-delivery or =
a best-effort packet service. That is a protocol-level property. In [6], =
retries and backoffs can occur within the selected protocols, and an =
action reaches a terminal outcome as either success or explicit failure. =
ACT_DROP is also a possible terminal action. The relevant reliability =
question is therefore whether the requested quantum service is completed =
under its specified requirements, rather than whether every individual =
packet is guaranteed to reach a destination unchanged.

>=20
>=20
>=20
>=20
>=20
> ** Routing and Next Hop Selection **
>=20
>=20
>=20
> So, proceeding from this point forward as if the routing info is held
>=20
> at the router...
>=20
>=20
>=20
> A router has a "quantum routing table", illustrated in Fig. 5 of
>=20
> [5].  (They use "entanglement service provider", or "ESP", but as far
>=20
> as I can tell an ESP is just a router, so I'll stick with the term
>=20
> router here.)  This is Sec. IV-B, mentioned above as being where |A_j>
>=20
> is defined.
>=20
>=20
>=20
> They define a routing table entry (Fig. 5) as (I'm reordering fields
>=20
> in a way that makes sense to me, not their order):
>=20
>=20
>=20
> * the nexthop address (|v_j> in the figure; I am going to write it
>=20
> without the ket as v_j since it's effectively classical info)
>=20
> * the matching condition, which is not simply a longest prefix, as
>=20
> in a UNIX-like or Internet-like FIB; it's a *SUPERPOSITION* of the
>=20
> addresses of the *NEIGHBORS* of v_j.  (recall v_j is our
>=20
> neighbor, so this is the neighbors of that neighbor)
>=20
> * some "ebits": I believe these are the *actual* qubits that are
>=20
> entangled with the neighbor v_j!  The result of the routing lookup
>=20
> is not just "you should send to v_j", it's "here's a qubit entangled
>=20
> with v_j for you to use."  (Or, presumably, "here are enough qubits
>=20
> to send the entire packet to v_j.")  Thus, this isn't really a
>=20
> _routing_ table, it's a combined FIB and buffer management table!
>=20
> This is an important distinction.
>=20
>=20
>=20
> I put "routing table" in quotes because it's not a RIB (routing
>=20
> information base), and in fact I don't think it's exactly a FIB
>=20
> (forwarding information base) either.  What I *think* it actually is,
>=20
> is a combined FIB and buffer management subsystem.  This is also a bit
>=20
> of a departure from other proposed architectures.
>=20
>=20
>=20
> For every virtual neighbor a router has, there is an independent
>=20
> routing table entry.  It's a little bit like an inverted FIB in a UNIX
>=20
> system, where the lookup key is the dst addr, and the result is an
>=20
> interface index or a neighbor's address, except that we have to scan
>=20
> the entire table and query the node address superposition in order to
>=20
> figure out if this particular neighbor is the right match.
>=20
>=20
>=20
> The addresses being matched are *not* labeled |A_j> in Fig. 5, but in
>=20
> Fig. 7 and Eqs. 36 & 37 they are.  So I guess we're on solid ground
>=20
> here saying that the we're *NOT* doing source routing with the routing
>=20
> table carried in the packet itself.
>=20
>=20
>=20
> The next hop is selected from this table using Grover's quantum search
>=20
> algorithm =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fen.wik=
ipedia.org%2Fwiki%2FGrover%2527s_algorithm&data=3D05%7C02%7Cangelasara.cac=
ciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b=
1e328f9da0c45fd%7C0%7C0%7C639220367874928871%7CUnknown%7CTWFpbGZsb3d8eyJFb=
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld=
UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DqKh8MkLrfaDx4ChlVShuum2n1swQ0wxsfu7DowP=
lny8%3D&reserved=3D0. Sec. IV
>=20
> of [5] covers this in detail.  I don't believe this is an effective
>=20
> design choice, but I also don't think it's actually crucial to the
>=20
> architecture so this isn't a showstopper criticism.  (It is, however,
>=20
> one of the key points related to their claim that classical control
>=20
> doesn't scale, which, as Wojtek pointed out, is claimed frequently but
>=20
> not supported by any data or quantitative analysis I have seen in any
>=20
> of the papers I have read.)
>=20
>=20
>=20
> The proposed implementation of Grover will require hundreds of
>=20
> long-lived, high-fidelity qubits and thousands or tens of thousands of
>=20
> high-fidelity gates.  This essentially implies that each quantum
>=20
> router is a full-fledged quantum computer, with a lot of memory and
>=20
> quantum error correction.  This is one of the primary reasons I say
>=20
> this is a 4G architecture.  It assumes an even stronger
>=20
> repeater/router node than the 3G architecture.
>=20
>=20
>=20
> I spent a long time studying the circuit they propose, but in the end
>=20
> the key point for our purposes is that it selects a virtual neighbor
> and a buffered qubit or qubits that are entangled with that neighbor.

I think we are mostly aligned here, now that the packet-structure issue =
discussed above has been cleared up. A few qualifications, though.

First, an ESP is not quite =E2=80=9Cjust a router.=E2=80=9D In [5], it =
is a tier-2 Quantum Data Plane entity implementing Generalized Quantum =
Forwarding. This includes next-e-hop selection, but also the generation, =
purification, swapping, transformation, and consumption of entanglement =
resources. Routing and next-e-hop selection are therefore only part of =
its role.

Your reading of the table is otherwise broadly correct. Each entry =
couples the e-hop address and its matching information with the actual =
locally stored halves of EPR pairs shared with that e-hop. This coupling =
is deliberate: unlike a classical forwarding decision, a =
quantum-forwarding decision cannot be executed independently of the =
consumable quantum resource required to realize it. I agree, however, =
that simply calling this a =E2=80=9Crouting table=E2=80=9D may invite an =
overly classical RIB/FIB interpretation, and we should make the =
terminology clearer.

The FIB analogy is useful, but I would stop short of calling the table a =
complete buffer-management subsystem. [5] does not specify generic =
buffer-management functions such as scheduling, admission control, or =
replacement policies. I would describe it more precisely as an =
entanglement-aware forwarding table. The associated entanglement =
resources are also not necessarily =E2=80=9Cenough qubits to send the =
entire packet=E2=80=9D to vj. They are pre-established entanglement =
resources that generalized-forwarding operations, such as swapping or =
purification, can manipulate or consume to extend the requested =
entanglement connectivity. More precisely, the lookup identifies a =
matching table entry and hence the corresponding e-hop. That entry =
stores a certain number of locally held halves of EPR pairs shared with =
the e-hop, which constitute locally available entanglement resources for =
the subsequent generalized-forwarding operations. The lookup therefore =
identifies the entry and it does not itself =E2=80=9Creturn=E2=80=9D the =
stored entangled qubit. Nor does [5] assume that their number is =
determined by the size of the quantum packet: the number of entanglement =
resources maintained per entry is explicitly left as a design parameter.

One further clarification: the mechanism does not sequentially scan the =
entire table. The entry labels are prepared in superposition, and the =
Schr=C3=B6dinger oracle queries the associated superposed e-neighborhood =
information coherently and non-destructively. If the target address is =
absent from a given e-neighborhood field, the oracle acts trivially on =
that field: it is neither measured nor modified, and its superposition =
remains available for subsequent queries. If the target is present, the =
oracle coherently couples the corresponding entry label to the hitting =
component of the address field and induces the conditional phase =
inversion used to mark that entry; the address field is still not =
measured. If no address field contains the target, no stored superposed =
address is measured, collapsed, or otherwise altered. Whether this is =
the right technological tradeoff is, of course, a separate and fair =
question.

On =E2=88=A3Ajl=E2=9F=A9, why this is not source routing, why the table =
is held locally rather than carried in every packet, I think we have =
already covered the relevant distinctions above.

The same applies to the architectural status of Grover-based lookup: as =
discussed above, it is one specific mechanism explored in [5], not a =
requirement of the I-D. Likewise, our concern about the scalability of =
purely classical control is not derived from Grover=E2=80=99s speedup or =
from routing-table size; it concerns the reconciliation of a separately =
maintained classical representation with an evolving non-local =
quantum-resource state.

Finally, I would distinguish the resource requirements you mention from =
the results reported in [5]. Figure 7 illustrates a straightforward, =
explicitly unoptimized circuit for a small address size; it is not =
intended as a fault-tolerant resource estimate.
The figures you mention =E2=80=94 hundreds of long-lived qubits and =
thousands or tens of thousands of gates =E2=80=94 do not appear to be =
results reported in [5], so I assume they derive from a separate =
resource model or implementation analysis you conducted (I=E2=80=99m =
genuinely interested in it). I agree that such estimates may well =
indicate that this particular realization is technologically demanding, =
but they necessarily depend on assumptions such as the oracle =
decomposition, native gate set, error model, and error-correction =
overhead.
In any case, these costs pertain to that particular realization in [5], =
not to the architectural assumptions of the I-D.


>=20
>=20
>=20
> Addressing point <2a> & <2b>:
>=20
>=20
>=20
> The "virtual neighbors" are what I am calling tunnel endpoints. As
>=20
> best I can tell, the set of neighbors for each node is intended to be
>=20
> long-lived.  Although other researchers have proposed dynamic
>=20
> entanglement swapping with set of perpetually-changing neighbors that
>=20
> must be tracked (which I think is impractical), I think in the Napoli
>=20
> architecture tunnels are perpetually "recharged" with entanglement so
>=20
> that there are always Bell pairs available.
>=20
>=20
>=20
> What I have called tunnels, they call virtual neighbors with
>=20
> "activated entanglement-proximity", and the topology on top of that
>=20
> they call the "artificial topology".  In [5] II-D, they refer to
>=20
> "artificial topology maintenance" which requires them to "continuously
>=20
> regenerate virtual links" as they are depleted by forwarding.
>=20
>=20
>=20
> Under the assumption that entanglement is readily made, this seems
>=20
> like a potentially good choice.  It can be used to simplify routing
>=20
> around/across a dense network core.  It's trying to solve the problem
>=20
> of potentially needing to understand the entire Internet topology,
>=20
> which is a crucial issue.
>=20
Thanks!
>=20
>=20
>=20
> As I understand it, if the network consists of n_e routers, each
>=20
> router has O(sqrt{n_e}) neighbors.  Although they use O(.) notation, I
>=20
> believe the intended constant factor is 1, so if you have 100 routers,
>=20
> each has ten neighbors; if you have 100,000,000 routers, each has
>=20
> 10,000 neighbors.  10K tunnels/neighbors sounds like a lot, but in
>=20
> classical terms it's really not; when I was at Network Alchemy around
>=20
> the year 2000, we built a VPN gateway that used a single Pentium CPU
>=20
> and was designed to handle 30,000 IPsec tunnels.  Sufficient
>=20
> production of entanglement, availability of buffer memory, and
>=20
> multiplexing across the tunnels instead are the challenges, which
>=20
> aren't really addressed by the Grover routing table lookup.
>=20
>=20
>=20
> The key idea behind this particular number is to make every
>=20
> router-router pair be one or two virtual hops away as often as
>=20
> possible, and effectively never more than three.  This is especially
>=20
> crucial for the Grover lookup, which they have designed to search
>=20
> across the set of neighbors-of-neighbors.  If each router has
>=20
> 0(sqrt{n_e}) neighbors, then the set of neighbors-of-neighbors is
>=20
> O(sqrt{n_e}^2) =3D O(n_e).
>=20
>=20
>=20
> However, intelligent selection of the set of neighbors is tricky. If
>=20
> they are selected so that each added tunnel adds a new node to the
>=20
> topology, of course it will be cycle-free, and you will end up with a
>=20
> tree that is exactly n_e - 1 links.
>=20
>=20
>=20
> If instead they are selected at random (with replacement), then the
>=20
> topology graph will contain triangles and larger cycles.  A little
>=20
> calculation shows that as n_e --> infinity, P(distance > 2) --> 1/e =3D
>=20
> ~36%.  That would be a problematically large probability in their
>=20
> scheme.
>=20

Thanks! This is very useful, because I think the probability calculation =
assumes a different construction from the one in [5].

First, we do not set the number of e-neighbors to sqrt{n_e} with a =
constant factor of one. In the construction, k=3D(1+m)sqrt{n_e} =
log=E2=81=A1(n_e), which we abbreviate as O(sqrt{n_e}). Therefore, the =
examples of 10 neighbors for 100 nodes and 10,000 for 100 million nodes =
do not follow from the parameterization used in the paper. This is also =
an asymptotic sufficient construction, rather than a claim about the =
operationally optimal number of neighbors.

More importantly, e-neighbors are not selected uniformly at random with =
replacement. For an ESP vi, N(vi) is the set of the k ESPs closest to vi =
according to the selected entangling-cost metric w. We deliberately =
leave the specific metric open: it may capture fidelity, =
entanglement-generation cost, delay, or another performance criterion, =
while requiring it to satisfy the metric and isotonicity properties =
stated in the paper. Overlapping neighborhoods are therefore allowed; =
the construction does not assume that every new virtual link reaches a =
previously uncovered node, nor that the neighbors-of-neighbors are =
disjoint.

The randomized component is instead the baseline covering construction. =
Using known covering results, the partial-anchor construction guarantees =
Property 1 with high probability: every e-neighborhood contains at least =
one anchor. The full-anchor construction guarantees Property 2 with high =
probability: for any destination, an ESP has an e-neighbor tracking that =
destination. These properties give paths of at most three and two =
entanglement hops, respectively, with high probability. For additive =
metrics, the corresponding entangling-stretch bounds are five and three. =
So your calculation about asymptotic probability is not the model =
analyzed in [5].

I do agree with your broader resource point: entanglement generation, =
quantum-memory availability, and multiplexing among concurrent demands =
are major challenges, and the Grover lookup does not solve them. That =
was not its intended role. The narrower question addressed in [5] is =
whether, once the entanglement overlay is constructed according to the =
stated model, quantum-native addressing can provide sublinear routing =
state and bounded entangling stretch.

>=20
> [5] III invests a lot of effort in discussing path cost and proving
>=20
> various constraints on a couple of variants in selection, but TBH I
>=20
> get lost in how the path cost is used to select neighbors.  Every node
>=20
> creates a tunnel/virtual link with every node with an entanglement
>=20
> cost (deliberately left undefined here, but could be e.g. time to make
>=20
> a Bell pair) below a certain threshold, plus some set of other nodes
>=20
> in the network that I think are randomly chosen.  To me, this scheme
>=20
> seems to require a LOT of classical knowledge about the complete
>=20
> network topology, including the ability to efficiently determine the
>=20
> set of nodes below that threshold and the ability to select other
>=20
> nodes in the network at random.
>=20
>=20
>=20
> Moreover, this results in network-wide total work to create and
>=20
> maintain sqrt{n_e} tunnels * n_e nodes =3D n_e^{3/2} total virtual
>=20
> links.  If n_e =3D 10^8, then this is 10^12 total tunnels in the
>=20
> network, the vast majority of which will never be used.
>=20
>=20
>=20
> Instead, it seems crucial to *design* the physical and virtual
>=20
> topology to match physical constraints, traffic demands and
>=20
> organizational needs.
>=20
>=20
>=20
> Which is, in fact, what the Internet's three-tier scheme of LAN
>=20
> (spanning tree), IGP (OSPF, ISIS, or iBGP), and EGP (eBGP) does. It's
>=20
> known to be imperfect, but as an existence proof for a network
>=20
> consisting of a lot of routers acting autonomously, it's hard to beat.
>=20
>=20
>=20
> Our QRNA =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.n=
ii.ac.jp%2Fpi%2Fn8%2F8_65.pdf&data=3D05%7C02%7Cangelasara.cacciapuoti%40un=
ina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45=
fd%7C0%7C0%7C639220367874947901%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn=
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D=
%7C0%7C%7C%7C&sdata=3DcwcrVcxQx6kM8HvRkry8ZWe3BokvJrww%2FxFwGqSP2MM%3D&res=
erved=3D0,
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdoi.or=
g%2F10.1145%2F3610251.3610556&data=3D05%7C02%7Cangelasara.cacciapuoti%40un=
ina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45=
fd%7C0%7C0%7C639220367874973353%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn=
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D=
%7C0%7C%7C%7C&sdata=3DnRRKsXGNqkqT9ZX6VEeV8aMZNbsBJ8z5crnsyudKnmA%3D&reser=
ved=3D0,
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2112.07092&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367874991624%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DH3TTil%2BvySBpEzbtxWMzrram5kuomz8GikNDYv2IMJ8%3D&reserved=3D=
0) attempts to provide similar
>=20
> recursive isolation of topology by creating connection-based tunnels
>=20
> across individual networks (ASes or equivalent).
>=20
>=20
>=20
> And with all of this I'm once again lost as to the expected semantics
>=20
> of a "packet".  Sometimes it feels like a locally-held data structure
>=20
> that is guiding the development of E2E Bell pairs, sometimes it feels
>=20
> like a datagram that does get transferred (teleported, most likely)
>=20
> hop to hop along the path.  In either case, I'm unclear on how the
>=20
> "packet" gets from the end node to the router (where our discussion
>=20
> has been centered), how many qubits of payload it contains, and lots
>=20
> of details about the supporting classical signalling (which still
> seems to be necessary).

I think the first part is already largely covered by the clarification =
above, but let me make the construction in [5] explicit. An =
e-neighborhood is not formed by taking all nodes below a cost threshold =
and then adding randomly selected nodes. For each ESP v_i, N(v_i) =
contains the  k ESPs closest to v_i according to the selected =
entangling-cost metric w. As you noted, the specific metric is =
deliberately left open, so that it can reflect generation time, =
fidelity, physical constraints, or other specific criteria.

The randomized component concerns instead the covering strategy, not the =
selection of low-cost e-neighbors. In the partial-anchor scheme, the =
anchor set is constructed using the randomized distributed covering =
algorithm of Awerbuch, Bar-Noy, Linial, and Peleg, =E2=80=9CCompact =
Distributed Data Structures for Adaptive Routing,=E2=80=9D STOC 1989. As =
discussed in Remark 7, this construction requires no a priori knowledge =
of the complete topology and guarantees Property 1 with high =
probability. In the full-anchor scheme, the tier-2 nodes are partitioned =
into tracked sets and each ESP randomly selects one of those sets, =
yielding Property 2 with high probability. As we state in [5], these are =
deliberately unoptimized baseline constructions. Our purpose was to =
isolate what quantum addressing can enable and to derive worst-case =
guarantees without assuming a topology-tailored construction. A =
clustering or covering strategy optimized for the physical topology, =
traffic, or administrative structure could provide better practical =
performance

There is, however, a fair implementation question here. [5] does not =
prescribe the discovery protocol through which an ESP identifies its k =
lowest-cost candidates. A naive centralized implementation could =
certainly use extensive topology knowledge, but complete topology =
knowledge is not a requirement of the construction: the paper explicitly =
allows neighborhoods to be formed independently and potentially from =
partial network views. So I would formulate the open question as how to =
implement scalable e-neighbor discovery =E2=80=94 especially across =
administrative domains =E2=80=94 rather than as an intrinsic requirement =
for every node to know the complete topology.

On the aggregate size, your qualitative concern about the cost to create =
and maintain the entanglement graph is fair, and we didn't address this =
cost in [5]. This brings us back to the distinction we have been making =
throughout the discussion. Your concern concerns the resource cost of =
one concrete realization, whereas our analysis asked what becomes =
possible when quantum-native abstractions are extended to the control =
plane. [5] proves sublinear routing-table size per ESP and bounded =
entangling stretch. Conversely, saying that the vast majority of the =
links would never be used would require a traffic model that is not part =
of the analysis. Did you have a particular traffic model or workload =
distribution in mind for that conclusion?
Saying differently, the aggregate scaling you point out is a legitimate =
consideration when assessing this baseline construction as a practical =
realization. It does not invalidate the result per se (scaling =
quantumness to the control plane), but it clearly motivates asking =
whether the same quantum-native capabilities can be exploited with more =
resource-efficient, topology- and traffic-aware constructions.

I also agree that a deployed physical and entanglement connectivity =
graph should reflect physical constraints, expected traffic, and =
organizational boundaries. The entangling-cost metric can incorporate =
some of these factors, but jointly optimizing e-neighborhoods, anchors =
or tracked sets, resource provisioning, and traffic demand is left open =
in [5]. This is also one reason why the I-D deliberately defines =
architectural principles without prescribing these mechanisms.

Thanks also for pointing us back to the QRNA work. It is clearly =
relevant to recursive topology abstraction, administrative isolation, =
and inter-domain organization, and we should cite it explicitly in the =
revised discussion. I see it as complementary rather than as addressing =
the same question: recursion can limit how much of a domain=E2=80=99s =
internal topology must be exposed, whereas our quantum-native control =
abstractions address how the control plane represents and operates on =
dynamically evolving entanglement resources. A recursive or federated =
organization would still need to define how resource representations are =
associated and reconciled across domain boundaries.

Finally, I think the packet-semantics questions in your last paragraph =
are the same ones addressed above, so I will not repeat the full =
explanation here. In [5], a tier-1 node is associated with a serving ESP =
and may delegate the richer inter-ESP forwarding decisions to it. =
However, the routing analysis in [5] focuses on the tier-2 ESP overlay. =
It does not prescribe the tier-1 access protocol, a fixed payload size, =
or the detailed classical-signaling procedures. Classical signaling =
remains necessary, we are not claiming otherwise. [6] provides a more =
concrete realization of how physical transfer, local packet =
transformations, and classical signaling interact. These are valid =
protocol-design questions, but they concern specific mechanisms that the =
I-D deliberately does not prescribe.

Anyway, the questions you raise are genuinely interesting. Several of =
them go beyond what we analyzed in [5] and require further investigation =
by the community=E2=80=94including us.

>=20
>=20
>=20
> The 1G, 2G, 3G taxonomy =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.n=
ature.com%2Farticles%2Fsrep20463&data=3D05%7C02%7Cangelasara.cacciapuoti%4=
0unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0=
c45fd%7C0%7C0%7C639220367875025533%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk=
iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D=
%3D%7C0%7C%7C%7C&sdata=3DPExozkOD2EWfoGn1l6uJdnU13xrxTKV7SYU%2Fmte5hZ0%3D&=
reserved=3D0) is
>=20
> about increasingly demanding management of errors (photon loss, state
>=20
> & gate errors, decoherence).  The Napoli architecture assumes:
>=20
>=20
>=20
> * high entanglement rate
>=20
> * high fidelity entanglement
>=20
> * high availability of quantum memory at routers
>=20
> * low-latency, high-speed quantum computation
>=20
>=20
>=20
> So while it's not fully accurate to classify this architecture in the
>=20
> same way, I think it's fair to call it a post-3G network.  I'll just
>=20
> settle for 4G for the moment.
>=20
>=20
>=20
> ...and the next extension to the architecture actually *DOES* deal
>=20
> with both errors and with classical messaging.  The newest paper,
>=20
> "Beyond Layering" [6], introduces "stamps" attached to packets. Each
>=20
> stamp represents a requested piece of functionality, such as
>=20
> purification.  These stamps seem to be about halfway in between our
>=20
> RuleSets and David Tennenhouse's IP Capsules from the 1990s (predating
>=20
> and in some ways heralding SDN),=20
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdl.acm=
.org%2Fdoi%2Fabs%2F10.1145%2F231699.231701&data=3D05%7C02%7Cangelasara.cac=
ciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b=
1e328f9da0c45fd%7C0%7C0%7C639220367875048930%7CUnknown%7CTWFpbGZsb3d8eyJFb=
XB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld=
UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DEIVbZvy2sA%2FxHoifJQpppuy8UHb6a%2BHRAjL=
gvnl%2BseE%3D&reserved=3D0.
>=20
>=20
>=20
> This one is such a departure from the others that it doesn't even
>=20
> mention virtual links or address superposition or routing, though its
>=20
> main example does talk about teleporting over a two-hop overlay. It's
>=20
> much more focused on the concrete tasks necessary for processing a
>=20
> single request.  It still doesn't really take up the issue of a
>=20
> connection, and doesn't discuss multiplexed use of entanglement
>=20
> resources.
>=20
>=20
>=20
> See [6] Fig. 4.  This is an incredibly helpful figure for
>=20
> understanding the lower-level architecture they propose.  The
>=20
> Initiator (I'm very happy to see the use of this term rather than
>=20
> "source") creates a Plan of Action (PoA) for the packet.  The PoA is
>=20
> only held locally, and is generated separately at each node for each
>=20
> packet, but its core is translated into a set of Stamps are requests
>=20
> for specific actions.  Stamps are carried in the packet itself, and
>=20
> can include things like:
>=20
>=20
>=20
> * LINK_PR
>=20
> (purification request? not sure)
>=20
> * ACT_FORWARD
>=20
> * ACT_HOLD
>=20
> * (local SWAP at the intermediate node isn't part of the plan decided
>=20
> by the Initiator?)
>=20
> * CONSUME_TP
>=20
> (complete the teleportation?)
>=20
>=20
>=20
> Classical messages can be emitted, and can trigger further actions at
>=20
> the receiving ends.
>=20
>=20
>=20
> There are some details here that can be quibbled about, but the basic
>=20
> structure of the PoA is good.  However, as noted above, I think this
>=20
> should be done using (classical) state at routers along the path,
>=20
> rather than being incorporated into the quantum packet.
>=20
>=20
>=20
> I still don't fully understand the packet format, including how many
>=20
> qubits are in the header and in the payload.  The payload seems to be
>=20
> intended to carry halves of Bell pairs from the Initiator, or possibly
>=20
> an intermediate node in the path, to the destination (what we would
>=20
> call "Responder" in connection setup, but they don't have that
>=20
> notion).
>=20
>=20
>=20
> One issue is that the Stamps are to be carried in the quantum packet,
>=20
> which means they are likely to consume a lot of quantum bandwidth and
>=20
> demand high-fidelity carriage, otherwise the Stamps will become
>=20
> corrupted.
>=20
>=20
>=20
> I would like this design a lot better if the quantum header were
>=20
> simply turned into a classical header.  Then we would have a simple
>=20
> argument about the locus of state, whether it should be distributed or
>=20
> localized to a single node.  I think this argument will come down to
>=20
> how much work turns out to be absolutely necessary in the middle of a
>=20
> path as the technology develops.  If we do wind up really needing
>=20
> purification and anything other than straight-up entanglement swapping
>=20
> in more than one or two places in the path, I think we will wind up
>=20
> with the distributed connection.  That's the way I think of our
> architecture.

Thanks, Rod. I am very glad that Fig. 4 helped clarify the =
Dynamic-Kernel structure and that you find the basic PoA organization =
convincing.=20

On the 1G=E2=80=933G taxonomy and the technological assumptions that you =
attribute to the architecture, I think we have already explained our =
position above, so I will not repeat it here. The same applies to the =
general packet abstraction and the distinction between the I-D, [5], and =
[6].

There is, however, one important clarification concerning Fig. 4. Stamps =
are not requests for actions, and the Initiator does not translate its =
PoA into a set of stamps for downstream execution. Each node =
independently constructs its own local PoA from the service intent, the =
accumulated stamps, and its current local state and capabilities. A =
stamp is appended only after an action has reached a terminal outcome. =
Thus, LINK_PREP, SWAP, CONSUME_TP, and ACT_FORWARD in the stamp trace =
certify actions that have already committed; they are not instructions =
for future execution. In the specific Fig.4 trace, ACT_HOLD, instead, is =
local soft state and deliberately produces no stamp. The SWAP in the =
example is planned and executed locally by the intermediate node Y, and =
its successful completion is then recorded in the meta-header.

I would describe [6] as a different architectural dimension. [5] =
develops one specific quantum-routing mechanism, whereas [6] proposes a =
protocol-suite organization that replaces fixed layering with the =
dynamic composition of network functionalities. For that reason, [6] =
deliberately does not prescribe one particular realization of routing =
for example. The wanted functionalities can be realized by suitable =
micro-protocols or meta-protocols and composed at runtime according to =
the service intent, the available node capabilities, and the current =
resource state. Quantum Addressing can likewise be used within the =
service intent and by the composed control and forwarding functions. The =
teleportation scenario is therefore an example of how the composition =
model operates, not a proposal that every service must use that =
particular overlay or sequence of mechanisms. The point of [6] is to =
avoid fixing their interaction through permanent layer boundaries before =
those mechanisms and technologies have matured.

On replacing the quantum meta-header with a classical header, this is =
probably still where we disagree most. I agree that a classical =
realization of part of the Dynamic-Kernel execution model is possible in =
a controlled environment. In fact, we have now experimentally realized =
the dynamic-composition principle through classical orchestration in =
NeQOS (https://github.com/QuantumInternet-it/NeQOS) and deployed it on =
the QuantumInternet.it multi-vendor testbed, coordinating up to 23 =
quantum-classical devices from four vendors over deployed fiber. That =
work is currently under review and is therefore not yet publicly =
available.

This implementation deliberately uses a controlled setting in which the =
participating devices, resource identifiers, topology, workflows, and =
coordination channels are known and bounded. It demonstrates that the =
Dynamic-Kernel principle can be realized with current technology.  It =
should be noted that the implementation is limited to the Executor and =
part of the Engine. In particular, a physical quantum meta-header is not =
implemented. Therefore it does not validate the complete suite proposed =
in [6].=20

In that more general setting, a classical header can certainly describe =
the requested operations, but an explicit mechanism is still needed to =
bind that header to the corresponding quantum resource and to keep the =
two aligned as the resource is generated, purified, swapped, forwarded, =
consumed, or lost. That association is not impossible, but it introduces =
an additional reconciliation problem. Our concern is that =E2=80=94 as =
said above =E2=80=94 beyond controlled environments, continuously =
maintaining that alignment across independently operated nodes and =
domains could become a scalability bottleneck.

The in-band quantum meta-header is intended to reduce the scope of this =
separation: it keeps the a service-scoped, append-only, single-writer =
procedural state=E2=80=94the service intent and immutable commit =
history=E2=80=94 operationally coupled to the evolution of the quantum =
packet and its resources. This localizes the context required by the =
next Dynamic Kernel and reduces reliance on separately replicated =
procedural history, It also preserves quantum-native control =
information, such as Quantum Addressing.

Your concern about quantum bandwidth and corruption is nevertheless =
completely fair. Quantum header fields consume physical resources and =
require suitable protection; [6] does not yet provide a quantitative =
comparison of that cost. But the corresponding cost of a classical =
solution is not zero either: it includes association, signaling, state =
replication, and reconciliation. So I do not think we can conclude a =
priori that turning the quantum header into a classical one is the =
better general solution. The comparison has to account for both costs =
under the same network, hardware, failure, and traffic assumptions.

So, in short: yes, classical control alone can work=E2=80=94and we have =
demonstrated a classical realization of the dynamic-composition =
principle on a real testbed. I just do not agree that this removes the =
architectural motivation for quantum-native in-band control outside =
controlled environments (which will augment classical control). The =
stronger motivation for quantum-native control concerns coherent control =
variables whose semantics cannot be preserved by an ordinary classical =
field. Our claim should therefore not be that classical control cannot =
operate a quantum network, but that it cannot be the only control =
representation.

>=20
>=20
>=20
> To extend the comparison a little more with our QRNA/RuleSet
>=20
> architecture =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv=
.org%2Fabs%2F2112.07092&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it=
%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0=
%7C0%7C639220367875071475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs=
IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7=
C%7C%7C&sdata=3DIDxA6Pjh4ArAorPGC0bP%2BxplM%2BzJCAffiLRv9QXwoY8%3D&reserve=
d=3D0
>=20
> =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2112.07093&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367875098972%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DBkeu6zL6jOtpVoLXsLOBHNSuXsCLsJjFtKnPyhjH00I%3D&reserved=3D0=
 =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F1904.08605&data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%=
7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%=
7C0%7C639220367875126357%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI=
lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C=
%7C%7C&sdata=3DyHH21ID4fYODRomddK9HWNALgfWeMb9eS77eEH9klLM%3D&reserved=3D0=
):
>=20
>=20
>=20
> * Plan of Action (PoA): like our RuleSet, describes a sequence of
>=20
> things that should happen.  Our RuleSets are stateful, defined by
>=20
> the Responder during connection setup, and live through the
>=20
> connection.  Napoli PoA is ephemeral, defined locally for a packet
>=20
> and lives only until that packet processing at the local node is
>=20
> complete (which could actually be until the E2E transaction is
>=20
> complete).
>=20
> * Dynamic Kernel: like our RuleSet Engine.
>=20
> * Stamps: like our Rules.  Each Rule of ours contains a Condition
>=20
> Clause and an Action Clause.  Stamps likewise wait for some
>=20
> condition to be fulfilled before they can be "committed".
>=20
> * The biggest difference is our full-path, fully distributed but
>=20
> asynchronous *computation* which results in creation of E2E
>=20
> entanglement, versus their emphasis on trying to be closer to
>=20
> hop-by-hop and to carry less state at intermediate nodes.  Given
>=20
> that an entire PoA can't be retired until the local resources can be
>=20
> reclaimed, this is maybe not as big a difference as it first seems.
>=20
>=20
>=20
> Overall, except for the need for high-fidelity bandwidth to carry the
>=20
> Stamps in-band, this is a 1G architecture, I think, and much more
>=20
> implementable than the 4G stuff in the first half of this message.
>=20
> One open agenda item, from my point of view, is improving the
>=20
> integration of those two sets, assuming that is indeed the Napoli
>=20
> plan.
>=20

Rod, I agree that there is certainly a family resemblance at the very =
general level of distributed local execution. However, I think the =
proposed one-to-one mapping obscures the distinctive contribution of =
[6]. Let me try to spell out the differences as I see them.
This is not a judgment that one model is universally better than the =
other. They make different architectural choices about where execution =
authority resides, when protocol logic is constructed, how long that =
logic persists, and how globally consistent progress is established. =
Precisely for these reasons, however, I would distinguish [6] quite =
clearly from QRNA/RuleSets.

In QRNA, recursion is organized through scoped connection layers: =
connection requests move between recursive levels, RuleSets may be =
rewritten at domain boundaries, and a two-pass setup installs =
connection-scoped programs at the nodes along the path. Indeed, in QRNA, =
connection establishment follows a two-pass procedure. First, a request =
travels from the Initiator to the Responder and collects information =
about the path and available resources. The Responder then constructs =
the RuleSets, which are distributed on the return path and installed at =
the participating nodes as state associated with that specific =
connection.

This is precisely where [6] takes a different architectural direction. =
It does not establish an end-to-end connection by constructing and =
distributing a path-wide program. No Initiator, Responder, controller, =
or intermediate domain determines the complete execution logic in =
advance. Instead, every node constructs a new local PoA at runtime from =
the service intent, the commit history, and its current state and =
capabilities. The network-wide execution structure emerges progressively =
from those local decisions.

The PoA is therefore not a short-lived RuleSet. A RuleSet is a program =
installed for a specific connection that prescribes which actions should =
be executed when the corresponding conditions are met, even when those =
actions occur asynchronously.
A PoA is a locally synthesized, speculative DAG that exists only to =
determine what can be executed in the current context of the node. Once =
the selected local actions have terminated and meta-header authority has =
been transferred, that PoA can be discarded. The PoA remains entirely =
local to the node that constructs it: it is never announced, =
transmitted, or installed at another node.

Likewise, the Dynamic Kernel is not simply another RuleSet Engine. A =
RuleSet Engine evaluates the conditions and executes the actions of a =
program installed during connection setup. A Dynamic Kernel runs at each =
node and constructs the local program itself: it plans candidate =
actions, evaluates resource and capability constraints, binds the =
selected actions to the micro-protocols currently available, dynamically =
composes those micro-protocols into meta-protocols, and executes the =
resulting schedule.

Stamps are also not analogous to Rules. A Rule is a conditional =
instruction waiting to be executed. A stamp is an immutable record =
generated only after an action has reached a terminal outcome. It =
contains no Action Clause for future execution and never waits for a =
Condition Clause to become true. It tells the next Dynamic Kernel what =
has already committed, thereby constraining=E2=80=94but not =
prescribing=E2=80=94the next locally generated PoA. Their temporal and =
operational semantics are therefore almost opposite.

The computation in [6] is also fully distributed, but it is distributed =
in a different sense. QRNA distributes a program across the connection =
path before execution. In [6], no global program is distributed: the =
network-wide service-fulfillment DAG emerges from independently =
generated local PoAs and their committed outcomes. Moreover, =
micro-protocols and dynamically composed meta-protocols may themselves =
coordinate operations across multiple nodes, using classical signaling =
whenever required, without relying on network-wide synchronization. This =
should therefore not be reduced to classical hop-by-hop processing.

The distinctive=E2=80=94and, to the best of our knowledge, =
unique=E2=80=94combination explored in [6] is the runtime construction =
of local PoAs, the dynamic composition of reusable micro-protocols as =
the organizational logic that replaces fixed layering while preserving =
modularity, commit-only in-band stamps, and the emergence of a =
network-wide execution DAG without distributing or maintaining a =
path-wide program.

Finally, I do not think that there are two Napoli architectural =
=E2=80=9Csets=E2=80=9D waiting to be integrated. [5] instantiates a =
particular routing mechanism enabled by Quantum Addressing. [6] defines =
a protocol-organization model within which routing and other functions =
can be dynamically composed. A routing mechanism such as the one in [5] =
can therefore be instantiated within this organization, but it is not =
required by it.

This separation is not only conceptual. In NeQOS=E2=80=94our =
experimental implementation =E2=80=94we realized the dynamic-composition =
principle, specifically the Executor and part of the Engine of the =
Dynamic Kernel, without implementing the routing mechanism proposed in =
[5]. We used it to operate entanglement-based network services and =
applications on a deployed, multi-vendor quantum-network testbed, =
including sustained polarization-drift characterization across quantum =
links. This provides concrete evidence that the protocol-organization =
model of [6] is not tied to the particular routing mechanism developed =
in [5]. At the same time, there is no incompatibility in the opposite =
direction: the mechanism proposed in [5] can be expressed within the =
compositional logic of [6], by realizing its routing and =
generalized-forwarding operations through dynamically composed =
micro-protocols.

>=20
> -----
>=20
>=20
>=20
> Okay, that's more than enough for now.  Just a few minor notes to
>=20
> close things out:
>=20
>=20
>=20
> * The "orthogonal subspace" of the address encoding seems to be
>=20
> unnecessary, and might even rest on some misunderstanding of
>=20
> encoding data in quantum states?
>=20
> * The term "ebit" is already defined with a different meaning, long
>=20
> ago.  See early Bennett papers.  Let's not run around redefining
>=20
> terms unless necessary.
>=20
> * As anybody hanging around QIRG can tell you, I dislike the use of
>=20
> the term "forwarding" unless you're really literally forwarding a
>=20
> packet to another node.
>=20
> * In Sec. 4 of the I-D, we have "This section extends Section 5 of
>=20
> [RFC9340].</par> The Quantum Internet is an entanglement-packet
>=20
> switching network,..." that wording gives the impression that 9340
>=20
> defines the Quantum Internet as a packet-based network, which it
>=20
> does not. I recommend you reword it to be clear that packet-based is
> your proposal (though I think not completely original).

On the =E2=80=9Corthogonal subspace,=E2=80=9D I am not sure which =
passage you are referring to, since this does not appear in the I-D. =
This concept appears in both [5] and [6], but in different senses. In =
[5], orthogonal computational-basis states encode perfectly =
distinguishable node addresses. In [6], orthogonality is used for =
meta-header/payload separation. What we actually require in [6] are =
independently addressable subsystems=E2=80=94or degrees of =
freedom=E2=80=94with header operations acting trivially on the payload. =
Orthogonality is one possible realization, but is not generally =
sufficient to guarantee non-perturbing access. So, fair point.

On =E2=80=9Cebit,=E2=80=9D agreed. We used the term to denote one =
locally held member of an EPR pair. This creates ambiguity with its =
alternative meaning as a unit of bipartite entanglement associated with =
the pair rather than with either constituent qubit.

On =E2=80=9Cforwarding,=E2=80=9D I know we disagree on the terminology =
:-) We use =E2=80=9Cgeneralized=E2=80=9D deliberately because the =
function includes operations such as swapping and purification, as well =
as physical transfer when required. We will make that broader meaning =
explicit and we will also revisit whether another term would avoid =
confusion.

Finally, agreed on the wording concerning RFC 9340. We will make it =
explicit that the entanglement-packet-switching model is our proposal, =
not something defined by RFC 9340. And yes, we are not claiming that the =
general idea of packet-based quantum networking originated with us. Our =
contribution concerns the particular architectural role and structure =
assigned to the quantum packet and its integration with quantum-native =
control and generalized forwarding.

> Whew!


Whew indeed=E2=80=94and thank you again for investing so much time in =
this. Your comments have made very clear where our wording allows the =
architectural principles of the I-D to become confused with the specific =
mechanisms explored in [5] and [6]. We have quite a bit to fix and =
clarify in the next revision.

>=20
> I think I now have a moderate understanding of the overall Napoli
>=20
> architecture.  I'm not sure yet how they overall want to move forward,
>=20
> but it's great to see the architectural ideas becoming more concrete.

We are revising the draft accordingly to the replies and your comments! =
Thanks a lot
>=20
>=20
>=20
> I'm off to West Virginia to see family, then Korea for a workshop,
>=20
> Indonesia for work, then back home, then I'll see Sara, Joaquin and
>=20
> others in Toronto!  So I'll likely be even worse than usual about
>=20
> responding to email, but I'll try to keep up.
>=20
>=20
>=20
> Happy August, y'all,
>=20
>=20
> --Rod

Sara=20

>=20
>>=20
>>=20
>> _______________________________________________
>> Qirg mailing list -- qirg@irtf.org
>> To unsubscribe send an email to qirg-leave@irtf.org
>>=20
>=20


--Apple-Mail=_5B93045B-E2E0-45E9-9BD5-DF31CC3D6F0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Dear Rod, Dear =
Wojtek,<br><div><div><br></div><div>Thank you so much for all the time =
and thought you put into this. We really appreciate =
it.&nbsp;</div><div><br></div><div>It has helped us clarify several =
important points and identify a number of places where the draft needs =
to be more precise and revised.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>As =
you (Rod) mentioned, you and Wojtek are broadly aligned on the main =
points, so I thought it would be easier to reply to both of you in a =
single email.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>I =
hope neither of you minds.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This will be a long email too. Sorry =
about that.</div><div><br></div><div>Let me start with the TL;DR and =
then go through the individual points.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>One framing point before the =
details: the I-D defines architectural principles; [5] explores one =
particular routing realization; and [6] proposes a protocol-organization =
model. Classical mechanisms and signaling remain necessary in all three. =
I will try to keep these levels separate =
below.</div><div><br></div><blockquote type=3D"cite"><div><div><blockquote=
 type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Da: Rod Van Meter =
&lt;rdv=3D40sfc.wide.ad.jp@dmarc.ietf.org&gt;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Oggetto: [Qirg] =
draft-cacciapuoti-qirg-quantum-native-architecture-01 &amp; Napoli =
architecture in general</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Data: 11 agosto 2026 alle ore 11:18:06 =
CEST</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>A: "qirg@irtf.org" =
&lt;qirg@irtf.org&gt;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Hi folks,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>All of this is personal opinions, except =
for the bit on the use of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>word "forwarding".</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I'm going to jump in here with some =
comments on this draft as</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>well. Sara and Marcello are probably =
still on vacation and so probably</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>can't reply soon, but I'm heading out on =
about six weeks of travel</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>myself (starting with a visit to my =
mother), and wanted to get this</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>out before I go. &nbsp;Jessica, =
Caterina, Joaquin and Amar may have</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>independent responses to my comments =
here, of course. &nbsp;(Minor</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>editorial note: this was mostly written =
with "they" rather than "you",</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>as if the authors aren't listening or =
responding. &nbsp;My apologies if</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>that bothers you, but this is mostly =
addressed to a) myself and b) the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>original authors.)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I mostly agree with Wojtek's comments on =
the I-D; I had written about</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>half of this before seeing his comments, =
and I think we're pretty well</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>aligned. &nbsp;I especially agree with =
his comments on justification of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>scalability, which I think will show up =
in my comments here.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fqirg%2FPpx5r=
Aawj_cUAoVRQ6e0Co6A4MY%2F&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40un=
ina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45=
fd%7C0%7C0%7C639220367874352260%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn=
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D=
%7C0%7C%7C%7C&amp;sdata=3DMLTreD7FKcZ2M5476xJg77jak0xbTqwbLccclZo4mpc%3D&a=
mp;reserved=3D0</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I went deeper into the associated =
research papers because I wanted to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>understand better where the ideas in the =
draft come from and where the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>overall effort to create a specification =
might be going. &nbsp;Of course</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>ideas and opinions change over time, so =
just because they wrote</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>something in a paper several years ago =
doesn't necessarily mean they</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>still think it's the best way to go. =
&nbsp;(Or even a fresh paper may</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>represent an exploration of an =
alternative instead of a fleshing out</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of a direct part of the =
architecture.)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>With apologies, this is going to be VERY =
long (over 5,000 words). It</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>has taken me a lot of work, so I hope =
that in the end it helps push</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>forward the conversation on Quantum =
Network and Internet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architectures, including helping to =
identify what's common among some</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of the candidates and what the =
differences are, based on differences</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in assumptions about technological =
development as well as goals for</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the system.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>TL;DR:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* I think the main Napoli architecture =
is a 4G architecture, well beyond</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>where the technology will take us for =
the foreseeable future. (The</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>very latest major paper does have some =
1G-like characteristics</div> discussed more =
below.)<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Some aspects of the design could =
indeed have this =E2=80=9C4G=E2=80=9D flavor and require technologically =
demanding capabilities. However, I do not think that this =
characterization applies to the architecture as a =
whole.</div><div>Furthermore, the 1G-3G taxonomy describes repeater =
technologies and their error-management capabilities rather than =
complete network architectures. This is also why I think we need to be =
careful and agree on the terminology.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Also, part of the Dynamic-Kernel =
execution model (Executor and part of the Engine) has now been =
implemented on our deployed, multi-vendor quantum internet testbed in =
Naples. These experimental results are currently under review and are =
not yet public, so we cannot point you to a public paper at this =
stage.&nbsp;Once they become publicly available, we will follow up on =
the mailing list and share them with the members, so that we can =
eventually move forward the discussion in light of the experimental =
evidences.&nbsp;</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>More generally =E2=80=94 and this is =
perhaps a philosophical difference between us =E2=80=94 I do not think =
that an architecture should be constrained only by what the technology =
can do today. Rather, it should try to capture the invariants of the =
problem: in our case, the non-local, consumable, stateful, and =
dynamically-evolving nature of entanglement, together with no-cloning, =
decoherence, and the unavoidable role of classical signaling. Those =
properties will remain even as memories, gates, entanglement rates, and =
error correction improve.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This does not mean ignoring =
implementability. Specific mechanisms must be assessed against realistic =
technological assumptions, and the architecture should admit =
progressively deployable realizations. But I would distinguish the =
lifetime of an architectural abstraction from the maturity of one =
particular implementation.</div><div>The Internet itself was =E2=80=94 =
or at least was in part =E2=80=94 designed with this ambition: its basic =
abstractions survived while link capacities, processing power, memory, =
and access technologies changed by orders of magnitude over the =
following decades.</div><div>I am not claiming here that we necessarily =
got the architecture right. I am only saying that I would evaluate =
separately whether the architecture captures the enduring properties of =
the problem and whether each proposed realization is feasible within a =
particular technological generation.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The many-long-lived-tunnels method is =
interesting and bears a lot</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>more research. &nbsp;It could be a good =
choice for working around the</div> "edges" of a dense =
core.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>I =
see the analogy =E2=80=94 and we briefly discuss it in the paper you =
label as [4] =E2=80=94 and I agree that this is an interesting direction =
worth investigating further.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>There is one distinction worth =
making, though. A classical tunnel creates a virtual adjacency, but =
packets still traverse the underlying multi-hop path whenever data is =
transmitted. By contrast, once an entanglement-enabled link has been =
established and remains available, it provides a directly usable =E2=80=94=
 and consumable =E2=80=94 connectivity resource between remote nodes. =
So, although the two may look similar as overlay abstractions, they are =
operationally different. We return to this distinction later in the =
email.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* Overall, I'm skeptical of packet-based =
quantum network</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architectures, but they bear further =
research and matching to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>projected technology development. =
&nbsp;Lots of smart people disagree</div> with me =
here.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Fair enough, we know this is a =
fundamental point on which reasonable positions differ. The packet =
abstraction is a deliberate architectural choice in our draft. =46rom an =
architectural viewpoint, a classical packet is a structured bit string =
comprising a header and a payload, independently of how those bits are =
physically encoded. Likewise, we view a quantum packet as a structured =
quantum state =E2=80=94 possibly describing a composite system =E2=80=94 =
organized into a quantum header and a quantum payload. In our suite [6], =
the meta-header has an explicitly sequential structure: it contains the =
service intent followed by an ordered, append-only sequence of stamps. =
Whether these logical fields are encoded using one or multiple carriers, =
one or multiple quantum systems, or different degrees of freedom of the =
same carrier lies below the architectural abstraction boundary. The =
architecture specifies their logical decomposition and semantics without =
committing to a particular physical encoding or carrier-level =
realization. More on this below.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* Personally, even if you accept the =
idea of packets for quantum</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>networks, I don't think the in-band, =
all-quantum packet structure</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>will be a good choice; I don't see any =
reason for the headers not to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>be carried over a coordinated classical =
channel, and carrying them</div> in the quantum channel comes with a =
high cost.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This is probably where we disagree =
most. I can agree that a coordinated classical header may work in =
controlled environments. My main concern is whether a separately =
maintained classical control field can remain consistently aligned with =
an evolving quantum-resource state in a general, dynamic network. =
Specifically, my concern has two distinct parts. First, a control field =
maintained on a separate classical channel requires an explicit =
mechanism to bind it to the corresponding quantum-resource instance and =
preserve causal alignment as that resource is transformed, consumed, =
lost, or replaced. So association and reconciliation semantics have to =
be provided. Second, a classical field may describe a quantum control =
state, but it cannot itself carry or be coherently operated on as that =
quantum state. This distinction matters for abstractions such as Quantum =
Addressing. More on this below.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The dynamic kernel approach I like; I =
find it similar to our</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>approach. &nbsp;It's event-driven, and =
actions are compiled to physically</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>appropriate actions locally and executed =
as independently as</div> =
possible.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Thank you! I like it a lot too :) To =
me, the closest similarity lies in the recursive nature. At the same =
time, there are important differences in the state and coordination =
semantics, which we discuss below.</div><div><font color=3D"#5856d6"><span=
 style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The active-packet approach (either =
stamps or superposed addresses),</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>which differs from our RuleSets in that =
they are carried in the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>quantum packets rather than stored as =
connection state at the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>routers, seems to me to be solving a =
non-problem, and the cost of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>complexity and performance demands =
introduced are will be the wrong</div> =
tradeoff.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This is closely related to the =
previous disagreement. I do not see resource-state reconciliation as a =
non-problem.&nbsp;</div><div>On the contrary, I believe that, beyond =
controlled environments, continuously reconciling a separate classical =
control representation with a distributed and evolving quantum-resource =
state will itself become a barrier to scalability.</div><div>More later =
in the email.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* At the end of this tome, there is a =
little bit of a comparison to</div> our =
architecture.<br></div></div></blockquote><div><br></div><div>Detailed =
response below.</div><div><br></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>References I worked from to understand =
the Napoli architecture:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>1. Angela Sara Cacciapuoti, Marcello =
Caleffi, Jessica Illiano, C. De</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Risi, A. Abane, Joaquin =
Chung</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Quantum-Native Architectural =
Tenets and Philosophy for the Quantum&nbsp;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Internet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cacciapuoti-q=
irg-quantum-native-architecture%2F&amp;data=3D05%7C02%7Cangelasara.cacciap=
uoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e32=
8f9da0c45fd%7C0%7C0%7C639220367874376637%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e=
U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo=
yfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DltoirW3Qtb5R7hNOFkEujs1dXLheLLaT99lS64J=
I7lM%3D&amp;reserved=3D0</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>2. Marcello's slides covering the -00 =
version of that draft</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F124%2Fmaterials=
%2Fslides-124-qirg-design-principles-for-the-quantum-internet-quantum-cont=
rol-plane-caleffi-00&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.i=
t%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C=
0%7C0%7C639220367874391482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU=
sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%=
7C%7C%7C&amp;sdata=3D087Ebs7b%2B2oQ0BlDcitDEAM2faI5BUUiFgmU5cybU%2BM%3D&am=
p;reserved=3D0</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>3. Sara's slides covering the -01 =
version of that draft</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F126%2Fmaterials=
%2Fslides-126-qirg-draft-cacciapuoti-qirg-quantum-native-architecture-01&a=
mp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b8=
2e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C63922036787440=
5869%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI=
lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3Dl=
nbjiJANeH2ovvbkg6d4fOTyCOdAqjlUr%2Fo4s%2FxrUjo%3D&amp;reserved=3D0</div><b=
lockquote type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>4. Angela Sara Cacciapuoti, Jessica =
Illiano, Marcello Caleffi</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Quantum Internet =
Addressing</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;IEEE Network</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;https://nam12.safelinks.protection.o=
utlook.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F2306.05982&amp;data=3D05=
%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980=
b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874420234%7CUnkno=
wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM=
iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DbZ5elrq8YO0oC=
4DQa0MS6BHC%2FmxXQwM2QTBNOS6hrQM%3D&amp;reserved=3D0</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>5. Marcello Caleffi, Angela Sara =
Cacciapuoti</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Quantum Internet Architecture: =
Unlocking Quantum-Native Routing via</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Quantum =
Addressing</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;IEEE Trans. =
Communications</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;https://nam12.safelinks.protection.o=
utlook.com/?url=3Dhttps%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F11322738&=
amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b=
82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C6392203678744=
34729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs=
IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3D=
dhi3q0sNlcVIKn4W2Y80nHK3cTx%2F3kChUoBwAPNP6i8%3D&amp;reserved=3D0</div><bl=
ockquote type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>6. Angela Sara Cacciapuoti, Marcello =
Caleffi</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;A Quantum Internet Protocol Suite =
Beyond Layering</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;IEEE Transactions on Network =
Science and Engineering</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;https://nam12.safelinks.protection.o=
utlook.com/?url=3Dhttps%3A%2F%2Fdoi.org%2F10.1109%2FTNSE.2026.3679795&amp;=
data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e0=
8def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C63922036787444886=
9%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi=
OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DiFT5=
yJXo6OlNLNtEp%2FQ%2F18HPmIffwjWTlxzF3SRmWp8%3D&amp;reserved=3D0</div><bloc=
kquote type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>7. Jessica Illiano, Marcello Caleffi, =
Antonio Manzalini, Angela Sara&nbsp;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Cacciapuoti</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;Quantum Internet Protocol Stack: a =
Comprehensive Survey</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;https://nam12.safelinks.protection.o=
utlook.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F2202.10894&amp;data=3D05=
%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980=
b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874463503%7CUnkno=
wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM=
iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DzcDDbecqr%2FE=
oRFV%2Bz6LSzAbRs24UN5H9F690qjKKpmQ%3D&amp;reserved=3D0</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;(n.b.: this survey doesn't cover =
their own architecture, and it's</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;good but now rapidly becoming =
dated as a lot of work has come out</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;in the last four years. &nbsp;But =
if you need to get oriented, it's</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;solid place to =
start.)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(I also skimmed a couple of others but =
didn't keep good notes on them.)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Let me oversimplify the assumptions, =
problem and architectural</div>decisions down to about six =
points:<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Your simplification is useful, but I =
think it combines architectural assumptions of the I-D with specific =
mechanisms explored in [5] and [6]. Let me try to separate =
them.</div><blockquote type=3D"cite"><div><div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>-1. The key assumptions are =
that</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>-1.1 high-fidelity entanglement itself =
is plentiful; and</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>-1.2 execution of quantum programs at =
quantum nodes</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;(including routers in the quantum =
network) is cheap, reliable</div> &nbsp;and low =
latency.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>No, I would not characterize these =
as assumptions of our architecture. The I-D defines architectural =
principles and abstractions; it does not prescribe specific protocols, =
algorithms, hardware realizations, or performance thresholds. Indeed, it =
is explicitly agnostic to both the routing model and the repeater =
generation. Specific mechanisms explored in the related papers =E2=80=94 =
notably the Grover-based realization in [5] =E2=80=94 may require =
advanced quantum-processing capabilities, but those requirements should =
not be transferred to the architecture as a whole.</div><div>Of course, =
every operational quantum-network realization has some minimum =
physical-feasibility conditions: the quantum resources must retain =
sufficient quality for long enough to complete the required operations. =
In a memory-based realization, for example, the available memories and =
coherence times must be adequate for the relevant protocol timescales. =
If they are not, that realization cannot work =E2=80=94 but this is true =
for any quantum-network architecture. It is not equivalent to assuming =
that high-fidelity entanglement is plentiful or that quantum computation =
at every router is cheap, reliable, and low latency. We will revise the =
wording of the draft wherever it may suggest otherwise.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>0. The key challenge in designing =
quantum networks is achieving</div> &nbsp;scalability in managing =
quantum =
entanglement.<br></div></div></blockquote><div><br></div><div>Yes, =
agree.</div><div><br></div><blockquote type=3D"cite"><div><div><blockquote=
 type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>0.1. Excessive per-connection state =
passing through central routers</div> &nbsp;doesn't =
scale.<br></div></div></blockquote><div><br></div><div>Not quite. Our =
concern is not primarily the amount of per-connection state or the =
processing capabilities of classical routers.&nbsp;</div><div>It is the =
association and causal-consistency problem introduced when a classical =
control representation is maintained separately from a non-local and =
dynamically evolving quantum-resource state, across both the nodes =
sharing the resource and the functions acting on it.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>0.2. Path length has higher impact in =
quantum networks than in classical</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;networks, so it is crucial to =
minimize the use of "stretched" paths</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;that are longer than the minimal =
path between two =
nodes.</div><br></div></div></blockquote><div><br></div><div>I would not =
state this as an assumption or requirement of the architecture. The =
routing mechanism you discuss later belongs to [5], not to the I-D. That =
paper provides one constructive example showing that a control plane =
grounded in quantum abstractions =E2=80=94 such as quantum addressing =
=E2=80=94 can support a routing mechanism with constant entangling =
stretch and sublinear routing-table size. Neither this routing mechanism =
nor stretch minimization is mandated by the =
I-D.</div><div><br></div><div><p data-pm-slice=3D"1 1 []">More =
generally, [5] is intended as one concrete example of what becomes =
possible when the control plane can represent and manipulate network =
information natively as quantum states, rather than being restricted to =
classical representations. It demonstrates one capability enabled by =
this design choice. Iit does not prescribe that capability as an =
architectural requirement. Let me also clarify why we chose compact =
routing as the case study. We were not trying to argue that =
routing-table growth or path stretch is necessarily the most pressing =
problem for a future Quantum Internet =E2=80=94 or, for that matter, for =
today's classical Internet.</p><p>Rather, compact routing provides a =
particularly useful benchmark because it exposes a fundamental and =
extensively studied trade-off in classical routing: reducing routing =
state while controlling the resulting path stretch. Starting from such a =
well-characterized classical problem allows us to ask a sharper =
question: does changing the nature of the information that the control =
plane can represent and manipulate change what can be =
achieved?</p><p>This is particularly relevant to [5]. To the best of our =
knowledge, [5] provides the first compact-routing construction achieving =
fully name-independent routing without relying on an underlying =
name-dependent scheme. Hence, node identifiers remain topology-agnostic: =
compactness is not obtained by embedding topological information into =
the addresses. Instead, Quantum Addressing enables sets of node =
identities to be represented and manipulated natively as quantum states, =
and the routing construction exploits this additional =
capability.</p><p>This was also very much in the spirit of a question =
that arose repeatedly in the early QIRG discussions, particularly from =
participants coming from the classical networking community: what can a =
quantum network actually do that cannot be done by a classical network? =
Our formulation of this question is whether the =E2=80=9Cquantumness=E2=80=
=9D can enable network functions or control abstractions that are =
unavailable when the network is restricted to classical information and =
operations. [5] was intended to provide one concrete, constructive =
example in this direction. We deliberately chose a classical networking =
problem with a long research history so that the distinction could be =
made explicit and evaluated against a well-established theoretical =
baseline.</p><p>So I think we actually agree that compact routing need =
not be a pressing operational concern for today's Internet, nor =
necessarily the dominant routing concern for a future Quantum Internet. =
That is not the point [5] was intended to establish. Its role is to =
demonstrate that, once =E2=80=9Cquantumness=E2=80=9D is admitted into =
the control plane, the resulting design space need not be limited to =
classical control mechanisms.</p></div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>1. The unit of communication is the =
quantum packet, which is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;"forwarded" across entangled =
tunnels, although the stated goal is to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;create E2E entanglement for end =
nodes; I don't quite understand yet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;how forwarding and entanglement =
swapping interact in this</div> =
&nbsp;architecture.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Entanglement swapping is one of the =
operations included in our generalized forwarding semantics. This is =
also consistent with the routing/forwarding decomposition adopted in the =
survey by Amar et al. that you cite later. There, quantum forwarding is =
explicitly distinguished from classical hop-by-hop packet forwarding: it =
comprises elementary-entanglement generation and entanglement swapping =
=E2=80=94 and, where needed, purification and robustness mechanisms =E2=80=
=94 to establish end-to-end entanglement. In our terminology, swapping =
consumes existing entanglement resources to extend or reconfigure =
entanglement connectivity. A quantum packet may therefore progress =
through local transformations and, when required, inter-node transfers. =
In this sense, swapping and forwarding are not alternative mechanisms: =
swapping is one of the mechanisms through which generalized quantum =
forwarding can be realized.</div><div>Hence, the term generalized =
forwarding should not be understood as an unchanged object transported =
across classical-like paths.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>2a. Routers should maintain large =
numbers of long-lived virtual</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;tunnels, which are multihop =
router-to-router connections that they</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;continually restock with Bell =
pairs. &nbsp;(n.b.: The authors don't</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;usually use the term "tunnel", but =
I think it's helpful here, and</div> &nbsp;they usually use the term EPR =
rather than Bell pair.)<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This is close, but I would make two =
clarifications. The two-tier organization described in the I-D does =
allow ESPs proactively maintaining entanglement resources among one =
another. However, what they maintain should not be understood as a set =
of long-lived classical-like tunnels that are continuously stocked with =
guaranteed Bell pairs. The maintained object is an entanglement-enabled =
connectivity relation, not a guarantee that a fixed number of Bell pairs =
is continuously available between ESPs. The individual entanglement =
resources realizing that relation are volatile, consumable, may =
decohere, and are not guaranteed to be continuously available. Thus, =
=E2=80=9Cmaintenance=E2=80=9D here should be understood as maintaining =
the capability to provide that entanglement-enabled connectivity, rather =
than continuously restocking a persistent tunnel to some guaranteed =
level.</div><div>There is also a second, architectural point. Section =
8.1 makes the broader architectural abstractions compatible with both =
proactive and reactive entanglement-generation regimes. Proactive =
maintenance is therefore one realization described in the draft, not a =
requirement imposed by the architecture on every =
implementation.</div><div><br></div><div><br></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div>2b. =
E2E connections are routed through these tunnels, minimizing the</div> =
&nbsp;number of virtual hops and possibly applying other cost =
metrics.<br></div></div></blockquote><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This describes the specific routing =
mechanism in [5], not an architectural requirement of the I-D. The draft =
deliberately does not prescribe a routing algorithm, a cost metric, or =
the minimization of virtual hops. Even in [5], I would not say that =
connections are routed through tunnels in the classical sense. Routing =
operates over an entanglement graph by selecting e-hops and manipulating =
the associated entanglement resources according to the adopted =
entangling-cost metrics.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>3. The normal per-packet processing of =
headers, including selecting</div> &nbsp;the nexthop, should all be done =
utilizing quantum computation.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>In the specific routing mechanism in =
[5], yes</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>4. Each quantum packet should carry =
"stamps", which are state for the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;processing of the packet itself. =
&nbsp;The stamps essentially represent</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&nbsp;program fragments, processed via a =
Plan of Action constructed</div> &nbsp;independently at each node along =
the path from the set of stamps.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Partly. Stamps belong to the =
mechanism described in [6], not to the architectural principles defined =
by the I-D. They are appended to the packet=E2=80=99s meta-header, but I =
would not describe them as program fragments. A stamp is an append-only =
record certifying the outcome of an action at an action-commit boundary: =
it records what has already happened; it does not prescribe what should =
happen next.</div><div><font color=3D"#5856d6"><span style=3D"caret-color:=
 rgb(88, 86, 214);"><br></span></font></div><div>At each node, the =
node-local Dynamic Kernel constructs a speculative local Plan of Actions =
from the service intent, the accumulated stamps, and the node=E2=80=99s =
current internal state. The PoA contains the candidate node actions, =
whereas the stamps provide the minimal authoritative execution history =
that subsequent nodes will exploit. The PoA itself is never carried in =
the packet: each node constructs it locally according to its =
capabilities and currently available resources.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>We have now implemented and =
simulated an executable specialization of this behavior in our =
open-source Q2NS/ns-3 simulator, over repeater chains with up to 1000 =
nodes (<a =
href=3D"https://zenodo.org/records/22092701">https://zenodo.org/records/22=
092701</a>). The results confirm that the meta-header growth is bounded =
by the number and granularity of the logical actions that actually reach =
an action-commit boundary during service =
fulfillment.</div><div><br></div><div>More precisely, the required =
committed-action sequence is determined jointly by the service intent, =
the adopted policy, the capabilities of the participating nodes, and the =
resources already available in the network. Once the service semantics, =
policy, and admissible actions are fixed, an upper bound on the =
meta-header growth can therefore be derived before execution; the actual =
size reached at runtime depends on which actions are required under the =
encountered resource and capability conditions.</div><div>Therefore, =
=E2=80=9Cbounded=E2=80=9D does not mean constant with network size. It =
means that the meta-header contains only the finite execution history =
logically required to bring that service instance to success or failure, =
rather than an ever-growing record of retries, speculative plans, or =
transient state.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>There's a lot more to it than just this, =
but I think those capture the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>essential ideas. &nbsp;I wish I could =
better articulate this in terms of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>problems being solved, but I'm not sure =
I really can yet.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Let's set aside the &lt;-1&gt; =
assumptions for the moment, but they underlie</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>a lot of the following work, and =
represent probably the biggest</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>divergence from my own =
thinking.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The challenges in &lt;0&gt; above are =
reasonable concerns. Let's look at them:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&lt;0.1&gt; As it happens, I worry a lot =
less about the amount of classical state</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>needed to support a quantum connection =
(even in our rather active,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>distributed computation-oriented =
architecture) than I do about the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>availability of entanglement to be =
shared among a set of E2E</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>connections passing through a node, =
regardless of whether the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>connection is designed to use classical =
state at routers or not. That</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is, personally I think &lt;-1.1&gt; =
won't be a valid technological point for</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>a long time yet.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I did just a little asking around, and =
while the people I asked didn't</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>have published numbers yet, it seems =
that a router at an IXP can</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>expect to see several million IP flows =
passing through over the course</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of a minute. &nbsp;That's a lot, but the =
memory for connection state</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>wouldn't be a problem; the challenges =
would be doing the per-packet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>processing at line rate, and managing =
buffer space properly if it is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>anything other than FCFS. &nbsp;With =
quantum event rates FAR lower (six</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>orders of magnitude? more?), the =
processing isn't the problem, but</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>buffer space management is indeed a big =
deal and an open area of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>research.</div><br></div></div></blockquot=
e><div><font color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>I think your argument addresses a =
different scalability problem from the one we mean in =
I-D.&nbsp;</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>I agree with you that =
storing classical per-connection state is unlikely to be the main =
technological bottleneck, particularly when quantum-event rates are so =
much lower than classical packet rates. I also agree that quantum-memory =
availability, coherence constraints, and the allocation of scarce =
entanglement among competing connections are major open problems. We are =
not assuming those problems away.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>But that is not the scalability =
problem we mean. Our concern is neither the number of bits needed to =
describe a connection nor the computational capacity of a router to =
process those bits.&nbsp;</div><div>It is the additional binding and =
causal-consistency obligation (reconciliation) introduced when a =
classical control representation is maintained separately from the =
quantum-resource state to which it refers.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The comparison with the number of IP =
flows through an IXP does not quite capture this =
distinction.&nbsp;</div><div>An IP flow does not normally require every =
router along its path =E2=80=94 and potentially additional remote nodes =
=E2=80=94 to maintain synchronized copies of the descriptors of an =
evolving, non-local resource state. Classical forwarding state is =
locally readable, copyable, and independently updateable. Entanglement =
is different: it is shared across nodes, cannot be locally inspected as =
an ordinary state variable, and can be consumed or reconfigured by =
operations performed at one of the participating nodes.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Take a simple swapping operation. =
Before the swap, the relevant resources may be the (A!-!B) and (B!-!C) =
entanglement relations. After the operation at (B), those resources have =
been consumed and a new (A!-!C) relation has been created, subject to =
the measurement outcome, corrections, fidelity, and remaining coherence =
budget. Any separately maintained classical representation must now =
reconcile (record and causally associate) that transition across the =
affected nodes and any controller or protocol function relying on it. =
Until that reconciliation completes, different entities may reason from =
different views of resource availability, ownership, or partner =
identity. With multipartite entanglement and concurrent operations, the =
number of affected dependencies becomes even =
larger.&nbsp;</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Lower quantum-event rates certainly =
reduce the absolute processing load, but they do not remove this =
reconciliation problem. The relevant quantity is not simply events per =
second; it is whether the classical representation can be updated and =
disseminated before it becomes stale relative to resource consumption, =
decoherence, and subsequent control decisions. In fact, when =
entanglement is scarce, an inconsistent reservation or a decision based =
on a resource that has already been consumed is more=E2=80=94not =
less=E2=80=94costly. So entanglement scarcity and state reconciliation =
are distinct problems, but they interact.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>In particular, I think that a =
classical representation can be reconciled in a small, controlled =
environment with bounded concurrency, known participants, and tightly =
managed timing. My concern is whether the same approach remains viable =
in a general, dynamic, heterogeneous, and eventually multi-domain =
network, where local quantum operations continuously alter shared =
resource relations. I do not see router memory capacity or per-event =
processing speed as answering that question.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This is also why our proposal does =
not try to eliminate classical signaling =E2=80=94 measurement outcomes, =
acknowledgments, and synchronization messages are obviously still =
required. The aim is instead to reduce the scope over which correctness =
depends on reconciling a separately maintained classical description =
with evolving quantum-resource states.&nbsp;</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>In the Dynamic-Kernel approach, each =
node plans from its local resource state together with the minimal, =
authoritative procedural commit history carried by the packet. =
Distributed operations may still use classical signaling internally, but =
their partial outcomes remain local; only terminally committed outcomes =
become visible to subsequent processing.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>So I completely agree that =
quantum-buffer management and entanglement availability deserve =
substantial research. I would just keep them separate from the issue =
raised in I-D: even if router memory and processing were effectively =
free, a separately maintained description of a non-local quantum =
resource would still introduce a distinct consistency and timeliness =
requirement.</div><div><br></div><div><p>As said, the issue we are =
targeting becomes even more apparent when we move beyond bipartite =
entanglement. Consider, as an architectural stress case, two distributed =
multipartite states =E2=80=94 for example, graph states =E2=80=94 each =
shared among remote nodes, that are manipulated and hence transformed =
through an operation involving only a subset of their participating =
nodes.</p><p>The operation may involve only a few nodes, but its =
consequences need not remain confined to those nodes. It can change the =
structure and identity of a quantum resource shared across tens or, =
eventually, hundreds of participants=E2=80=94or, recalling Kleinrock's =
seminal 1975 vision of computer networks at scale, perhaps even =
thousands.</p><p>A separately maintained classical representation would =
then have to capture considerably more than the equivalent of "a swap =
succeeded." It would have to identify which distributed resource =
instances were consumed or transformed, what new resource resulted, =
which nodes participate in it, and which subsequent operations are =
causally permitted to act on that resource. At the same time, other =
operations may be taking place concurrently on different parts of the =
same distributed state or on resources that overlap with it.</p><p>None =
of this means that maintaining such a classical description is =
impossible in principle. The architectural question is different: over =
what scope, with what consistency guarantees, and within what time =
bounds must that description be reconciled before other nodes or =
protocol functions can safely make decisions based on the resulting =
resource? Or, putting the question more simply: as the network scales in =
the number of nodes, distributed resources, concurrent operations, and =
administrative domains, is maintaining and reconciling a separate =
classical description of those evolving non-local quantum resources the =
abstraction on which we want the scalability of a general-purpose =
Quantum Internet to depend?</p><p>This is why we view the issue as more =
fundamental than classical memory capacity or per-event processing rate. =
In a network built primarily around independently managed Bell pairs, =
the reconciliation problem can look like bookkeeping among a small =
number of endpoints and intermediate nodes. Multipartite entanglement =
makes the distributed nature of the problem much more explicit: an =
operation involving only a subset of the participating nodes can alter =
the semantics of a quantum resource whose identity and operational =
relevance extend across the distributed system.</p><p>This is precisely =
the kind of architectural scaling question that the I-D is intended to =
expose. We are not claiming that classical descriptions cannot be =
maintained, nor that classical signaling can or should disappear. We are =
asking whether correctness should continue to depend on maintaining only =
a separate classical representation that must track, with sufficient =
timeliness and causal consistency, an increasingly dynamic set of =
non-local quantum resources as the network scales.</p></div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&lt;0.2&gt; I agree, we should be =
working to minimize the amount of "work"</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>needed for each E2E connection. =
&nbsp;That's one of the key metrics we</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>looked at back in our path selection =
paper</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>[https://nam12.safelinks.protection.outloo=
k.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F1206.5655&amp;data=3D05%7C02%=
7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2=
fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874484564%7CUnknown%7CT=
WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF=
OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DXWUr8ssyQdrHO3Fbd7%=
2Fr2Fxzu14dL2I%2FIuThFsppmEg%3D&amp;reserved=3D0]. &nbsp;But I don't =
think that the</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"stretching" of paths due to =
shortcomings in the addressing and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>routing architecture are as big a =
concern as the Napoli team does.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>One key reference they keep coming back =
to is</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F0708.2309&amp;data=3D05%7C02%7=
Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2f=
cfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874504653%7CUnknown%7CTW=
FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO=
IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DIUBnHX3vukgE1cbXsHph=
E9fa5trIwHg0Hy3yUCFiXlU%3D&amp;reserved=3D0. &nbsp;That particular paper =
is</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>interesting, but doesn't seem to me to =
be very mainstream; it has some</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>2007 opinions about how the Internet was =
evolving that in the end seem</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>not to have happened over the last 20 =
years.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>One of the authors of that is kc claffy, =
who is one of the most</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>important people in Internet measurement =
and (interesting side note to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>me, at least!) &nbsp;got her start =
during an extended visit to Japan and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>whose first paper was with T. Asaba, Jun =
Murai and Osamu Nakamura.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Anyway, the Krioukov paper is on =
"compact routing", which is not a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>term you will hear from Internet people =
much. What it appears to mean</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is worrying about routing table growth =
and address aggregation for</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>routing purposes. &nbsp;The canonical =
place to learn about that these days</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is probably Geoff Huston's annual blog =
entries for APNIC, most</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>recently =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fblog.a=
pnic.net%2F2026%2F01%2F08%2Fbgp-in-2025%2F&amp;data=3D05%7C02%7Cangelasara=
.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb624=
6b0b1e328f9da0c45fd%7C0%7C0%7C639220367874520568%7CUnknown%7CTWFpbGZsb3d8e=
yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI=
sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DyRG%2BEFc3fLjPohRGFZRj2F3Effv9B=
YrGJnGnUlVLiw0%3D&amp;reserved=3D0</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The IPv4 table is now a little over a =
million entries, which is a lot</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>but not the disaster it was feared to be =
twenty years ago.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The "compact routing" folks fear that =
keeping the routing table size</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>manageable means selecting suboptimal =
routes that result in</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"stretching" a path. &nbsp;AFAICT, this =
is in truth a non-issue in today's</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Internet, but the Napoli team worries =
about it in their quantum</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>network design.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>So, I think it's reasonable to expect =
that quantum networks can select</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>a "best" path for the foreseeable =
future. &nbsp;The survey by Amar &amp;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>friends is great =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fieeexp=
lore.ieee.org%2Fdocument%2F10882978&amp;data=3D05%7C02%7Cangelasara.caccia=
puoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e3=
28f9da0c45fd%7C0%7C0%7C639220367874536843%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0=
eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj=
oyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DIHmjx5HmZVEkENbPOrJvqPTUd1UL5AST2LI3dI=
SWVJA%3D&amp;reserved=3D0. &nbsp;I</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>think the big question right now is not =
the abstract, graph-theoretic</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>problem of path selection, but instead =
how to integrate path selection</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>and resource management/access =
multiplexing. &nbsp;We did some preliminary</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>work on that long ago</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Faqua.sfc.wide.ad.jp%2Fpublications%2FAparicio-ma=
ster-thesis.pdf&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb=
4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0=
%7C639220367874856572%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi=
OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C=
%7C&amp;sdata=3DrV9kYpxzNxpju45NFqQQCOPicZdIsPoH5QmlbNjEbJY%3D&amp;reserve=
d=3D0</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>and some in the restricted environment =
of a data center network/LAN</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>just recently in =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F2605.07295&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina=
.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%=
7C0%7C0%7C639220367874874482%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd=
WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C=
0%7C%7C%7C&amp;sdata=3DgRKrbJI6gncOLY%2Fq2Y2dPR%2BgASBqwILGTN5lh6b6djY%3D&=
amp;reserved=3D0 (which will be</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>presented next month at IEEE QCE). =
&nbsp;There are some other people out</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>there working on this, as well, and I'm =
falling behind on the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>literature here; both the Napoli team =
and a couple of other things</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I've read recently have references I =
hadn't seen before, such as</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F10575563%2F&amp=
;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e=
08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C6392203678748901=
30%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA=
iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DvEk=
tV4tDhYubpQA0lkj04xVwVIK4GjHLmfixe03eic8%3D&amp;reserved=3D0.</div><blockq=
uote type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>I think this is another point where =
our motivations may have become crossed. Path stretch is not what =
motivates the I-D.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>In =
[5], we use compact routing as a concrete case study: once the control =
plane is grounded not only in classical abstractions but also in quantum =
ones, such as Quantum Addressing, we can construct a routing protocol =
with sublinear quantum routing-table size and entangling stretch bounded =
by a constant. To be clear, we are not claiming that classical =
abstractions are unnecessary. Our claim is that they need to be =
augmented with quantum abstractions.</div><div>These routing properties =
are results of the specific mechanism developed in [5], not =
architectural requirements of the I-D. The mechanism is therefore =
discussed in [5], while the I-D deliberately stops at architectural =
principles and does not prescribe a routing protocol.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>But the more fundamental point is =
neither table size nor routing itself. The confusion may come from our =
own wording in the I-D, which still presents Quantum Addressing mainly =
through routing and forwarding examples. We should make its broader role =
clearer in the next revision.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The departure we propose is =
semantic. A conventional control plane =E2=80=94 which is concerned with =
routing, configuration, management, policy enforcement, and resource =
coordination =E2=80=94 performs these functions through classical =
representations. Our Quantum Control Plane retains those classical =
mechanisms while augmenting them with quantum-native abstractions that =
can be encoded and operated on as quantum states. Classical abstractions =
and classical signaling remain necessary: they are complemented, not =
replaced.</div><div>Quantum Addressing is one such abstraction, but it =
is neither restricted to routing nor intended to represent the entire =
quantum control structure. It can represent and support operations on =
sets (via superposition) of candidate nodes, paths, or domains and can =
therefore contribute to resource selection, distributed coordination, =
and service fulfillment =E2=80=94 not only to next-hop computation. We =
still need both the physical-network view and the dynamically evolving =
entanglement view.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Recent work on quantum-enabled clock =
synchronization and networked quantum metrology provides a useful =
precedent. Quantum states and nonclassical correlations =E2=80=94 and, =
depending on the protocol, entanglement =E2=80=94 are used as =
operational resources for a network-relevant coordination function. Some =
experimental protocols combine photon correlations with classical =
communication and post-processing, which is actually close to the point =
we are making: quantum resources augment rather than eliminate classical =
mechanisms. The narrower analogy is that quantum resources need not =
merely be represented and managed by a control mechanism; they can =
participate in performing the coordination function.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>[6] provides an example at a =
different architectural level. It is a protocol suite organized around =
dynamic composition that allows the network to complete a requested =
service through distributed, node-local execution. Its meta-header =
contains the service intent =E2=80=94 including the participating nodes =
expressed through Quantum Addresses =E2=80=94 and the accumulated =
action-commit stamps. Each Dynamic Kernel uses this information, =
together with its local state, to construct and execute a local Plan of =
Action. As these local actions commit, the service progresses toward =
completion.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Quantum Addressing is =
therefore one component of the meta-header, not the whole control =
structure. The stamps serve a different purpose: they provide the =
authoritative procedural execution history that allows subsequent nodes =
to determine what remains to be done. Also, this packet-carried =
procedural control should not be confused with external QCP/EDC =
orchestration, which may provide optional policies or hints but is not =
required for the correctness of service completion in [6]. The =
structural gain here is that no continuously refreshed global execution =
plan is required: only committed outcomes cross node boundaries through =
the packet-carried history.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>A =
separately maintained classical control field (classical header) could =
certainly be considered, but it would still need an explicit association =
and reconciliation mechanism to remain aligned with the evolving quantum =
resource to which it refers. This implies that the alignment problem =
still has to be solved.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Seen in this way, [5] and [6] =
illustrate quantum-native abstractions at two different levels. [5] uses =
Quantum Addressing within a control-plane routing mechanism operating =
over the entanglement graph. [6] embeds Quantum Addressing within a =
richer in-band control structure used by a dynamically composed protocol =
suite to complete a requested service.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>So yes, I agree that integrating =
path selection with resource management and access multiplexing is an =
important problem, and your earlier metric could be instantiated within =
the more general entangling-cost formulation used in [5]. It is simply =
not the motivation for the draft. Our architectural thesis is broader: =
limiting control semantics to classical representations introduces an =
additional association and reconciliation requirement and prevents =
quantum states and operations from being used natively as control =
abstractions.&nbsp;</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Saying with different words, =
separating procedural control from an evolving quantum resource =
introduces an additional association and causal-consistency requirement =
that could become a scalability bottleneck. And, restricting the control =
plane to classical representations prevents it from natively preserving =
and coherently operating on genuinely quantum control variables. This =
semantic capability motivates augmenting =E2=80=94 not replacing =E2=80=94=
 classical control with quantum-native abstractions. [5] and [6] provide =
two concrete examples of the resulting design space.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>** Quantum Packets **</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&lt;1&gt; Quantum packets: here's where =
I get stuck most on understanding</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the architecture. &nbsp;With apologies =
to the authors, even after reading</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the above, I'm not quite sure what =
constitutes a packet and how it</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>moves through the network. &nbsp;Maybe =
my brain is working from too</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>different a point of view. &nbsp;But the =
most up-to-date reference [6] is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>also, happily, the most concrete on =
processing. &nbsp;It provides some</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>information on how the metadata in the =
packet is created and updated,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>how a packet is processed and how it =
moves through the network.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I am unclear on whether a packet is =
believed to be reliably delivered.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Some of the papers pay a lot of tribute =
to early datagram work from</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the 1970s, so I think maybe the packets =
are assumed to be unreliable.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Moreover, somewhere they mentioned that =
since we are building E2E</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>entanglement, it's okay to drop some =
things because they aren't</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>carrying valuable data. &nbsp;However, =
given how much work goes into each</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>packet, this might be a poor =
choice.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The figure from Sec. 5 of =
[1]:</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>+---------------------------------+-------=
---------------------------+</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>| =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Quantum Header =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| =
&nbsp;&nbsp;&nbsp;&nbsp;Quantum Payload =
&nbsp;&nbsp;&nbsp;&nbsp;|</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>+---------------------------------+-------=
---------------------------+</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>| &nbsp;&nbsp;- Quantum Address |A&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| &nbsp;- Entangled =
qubits |e_i&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>| &nbsp;&nbsp;- Optional metadata =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| =
&nbsp;&nbsp;(bipartite or multipartite) =
&nbsp;&nbsp;&nbsp;|</div><blockquote type=3D"cite"></blockquote><div><font=
 color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>+---------------------------------+-------=
---------------------------+</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(Here's hoping the ASCII art figure =
survives modern mail writers &amp;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>readers.)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>This is simplified and a little =
different from Fig. 3 in [5], which</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>includes:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>header:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>- src addr: x_i</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>- dst addr: x_j</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>- an array of address structures, |A&gt; =
=3D |A_j^1&gt;,|A_j^2&gt;,|A_j^3&gt;...</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>**each of which is a weighted =
superposition of node addresses**</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>payload:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>- an array of qubits: =
|e_1&gt;,|e_2&gt;,|e_3&gt;...</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Note that x_i and x_j are *classical*, =
single-valued addresses; any</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>given packet has exactly one source and =
one destination address.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>However, these addresses are encoded in =
qubits, such that the entire</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>packet can all be viewed as a single =
block of qubits.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>However, the next set of header fields =
(which I think is what is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>called "metadata headers" or =
"meta-headers" in some of the papers and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in the figure above?) *is* in a weighted =
superposition. &nbsp;This is very</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>likely the source of the confusion over =
whether or not the Napoli</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture is proposing that =
destination addresses be in</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>superposition in a way that "splits" =
quantum amplitude over a set of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>destinations, as at least some of the =
Innsbruck papers propose</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(https://nam12.safelinks.protection.outloo=
k.com/?url=3Dhttps%3A%2F%2Fwww.nature.com%2Farticles%2Fs41534-021-00472-5&=
amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b=
82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C6392203678749=
09588%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs=
IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3D=
p0KZF%2B2h1EbccO51AFYA9Q2Vlv8ui68tr1luZ449HAc%3D&amp;reserved=3D0).</div><=
blockquote type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>[Edit: I now think Fig. 3 of [5] is =
incorrect. &nbsp;See more on this</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>below, but I'm keeping the description =
here just in case I'm wrong</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>about it being wrong, and to help others =
understand where I went wrong</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>if I'm right about it being wrong. =
(Confused yet? &nbsp;So am I.)]</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I'm a little unclear on whether |A&gt; =
in the I-D figure above [1] is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>supposed to be the same as |A&gt; in =
[5]. &nbsp;I think not.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Focusing on the |A&gt; from [5], it =
appears to be a *complete routing</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>table for the network*, carried *in the =
packet itself*. &nbsp;This is a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>striking design choice, with =
implications that echo through all of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture. &nbsp;I'm also not =
entirely certain I've understood it right.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Note that |A&gt; is *not* a source route =
header, a la RFCs 5095</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(deprecating part of RFC 2640), 6275, or =
6554, or like SRv6 (described</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in a whole plethora of RFCs including =
8754). &nbsp;I actually don't see why</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>this couldn't be a source route, which =
would simplify all of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>processing and allow this meta-header to =
be carried in the classical</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>channel. &nbsp;If you don't like =
stateful connections and are worried about</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>path selection overhead, this can help, =
but it doesn't solve the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>scalability problem of having most of =
the network nodes know a LOT</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>about the network topology; in fact in =
might make it worse.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>But sticking with the proposed =
structure, here's what I understand</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(which might be wrong). &nbsp;(This idea =
is also tied up with the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>many-tunnels notion, which we'll defer =
for a bit, so part of this is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>oversimplified.)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Sec. II-D of [5] says, "[F]orwarding =
decisions...[are]...enabled by a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>quantum header in the packet, as =
illustrated in Fig. 3, which carries</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the quantum equivalent of =
source-destination addresses. This approach</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>generalizes 'next-hop' selection in the =
quantum realm by applying</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>appropriate quantum operations to =
quantum addresses in routing tables,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>thereby eliminating classical header =
parsing." &nbsp;Then the caption to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Fig. 3 says, "Quantum packet structure. =
The header carries quantum</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>information for the quantum routing =
logic, such as source-destination</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>quantum network address |x_i&gt;, =
|x_j&gt;, and quantum superpositions</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>|A_j&gt;, representing set of quantum =
nodes introduced in Sec. IV-B,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>while the payload carries entangled =
qubits (ebits) to be shared among</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>network nodes."</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I now think that that description =
surrounding the packet structure in</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Fig. 3 is wrong, that |A_j&gt; is *held =
at the router nodes*, not</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>included in the packet. &nbsp;Also note =
that the packet figure in the I-D</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(the ASCII figure reproduced above) is =
simpler and does not appear to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>include the routing =
information.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Assuming those qubits labeled ebits are =
locally buffered at the router</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(as discussed next), I'm now back to not =
understanding what a "packet"</div>is in this =
architecture.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Rod, no apologies needed: these are =
very useful comments. I think, however, that three different levels are =
being mixed here: the architectural packet abstraction in the I-D, the =
specific routing packet used in [5], and the packet realization used by =
the protocol suite in [6].</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The packet structure in the I-D is =
deliberately more general than the one in [5]. The I-D defines only the =
architectural boundary: a quantum packet has a quantum header carrying =
addressing and other control information, and a quantum payload carrying =
the quantum resources on which the network operates. It does not =
prescribe the fields required by a particular routing mechanism, =
protocol suite, or service. The structure can therefore be specialized =
according to the network function being implemented.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>[5] provides one such specialization =
for its quantum-routing mechanism. There, =E2=88=A3xi=E2=9F=A9 and =
=E2=88=A3xj=E2=9F=A9 are quantum addresses represented by =
computational-basis states.They are perfectly distinguishable quantum =
states that encode one source and one destination in that particular =
realization.</div><div><font color=3D"#5856d6"><span style=3D"caret-color:=
 rgb(88, 86, 214);"><br></span></font></div><div>The =E2=88=A3Ajl=E2=9F=A9=
 fields have a different role. Each of them represents one partition of =
the e-neighborhood of a particular ESP vj. They are announced by vj as =
routing-control information and therefore belong in the quantum header =
rather than in the payload. Once received, this information can be =
retained in the corresponding local routing-table entry. Thus, being =
carried in a packet when announced and being stored at a router for =
subsequent queries are not mutually exclusive.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>They are also not a complete routing =
table carried inside every packet, and they do not encode the complete =
entanglement graph. They describe scoped e-neighborhood information =
associated with a particular e-hop. The complete local routing table =
contains multiple entries and remains at the ESP.</div><div>So I do not =
think Fig. 3 of [5] is wrong in the sense you suggested.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Also, =E2=88=A3A=E2=9F=A9 in the I-D =
should not be identified one-to-one with the complete field structure =
used in [5]. In the I-D, it denotes the more general Quantum Addressing =
abstraction. In [5], that abstraction is specialized into source and =
destination address fields and superposed e-neighborhood fields for a =
particular (compact) routing mechanism. In [6], it is embedded in an =
even broader meta-header: Quantum Addresses identify the participants in =
the service intent, while the meta-header also carries the other intent =
parameters and the accumulated action-commit stamps.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The superposed e-neighborhood fields =
in [5] should also not be interpreted as splitting the packet payload =
across several destinations, as in the Innsbruck proposal. In [5], the =
superposition is used as a control structure: the routing logic queries =
whether the target address belongs to one of the represented =
e-neighborhoods and selects the corresponding e-hop. The payload does =
not enter a superposition of destinations merely because a header field =
contains a superposition of node identifiers.</div><div>For the same =
reason, =E2=88=A3Ajl=E2=9F=A9 is not a source route. A source route =
carries an ordered sequence of nodes through which a packet should pass. =
A classical source route could certainly be studied as another routing =
mechanism=E2=80=94the I-D does not exclude it=E2=80=94but it would not =
be a different encoding of the same mechanism in [5]. It would replace =
local quantum-address processing with a precomputed path that would =
still have to remain valid with respect to the evolving entanglement =
graph.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>As to what it means for =
a quantum packet to =E2=80=9Cmove,=E2=80=9D Generalized Quantum =
Forwarding should be understood as a forwarding abstraction, rather than =
as a single primitive operation or merely the physical transmission of a =
carrier from one node to another. It captures the overall semantics by =
which a packet is processed and advanced: the relevant header or =
meta-header information is processed to determine the applicable =
actions; the payload and its associated entanglement resources may be =
transformed, consumed, or left unchanged; and, when required, the =
resulting packet is transferred to the selected next node. A quantum =
packet therefore progresses logically through a combination of local =
transformations and inter-node transfers. This does not imply that the =
same immutable block of qubits=E2=80=94or even the same physical =
carriers=E2=80=94traverses every physical link.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The protocol suite in [6] makes the =
above distinction concrete. Processing at a node may update the =
meta-header through action-commit stamps and manipulate the payload as =
service fulfillment progresses. ACT_FORWARD(nh) is the specific action =
that transfers the resulting packet=E2=80=94and the authority over its =
meta-header=E2=80=94to the selected next node. The actual sending of the =
packet is therefore one action within generalized forwarding, not its =
complete definition. This is consistent with [5], where packets carrying =
locally held members of EPR pairs are propagated through sequences of =
quantum operations rather than merely through transmission over physical =
links.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>On reliability, the I-D =
does not prescribe either a reliable-delivery or a best-effort packet =
service. That is a protocol-level property. In [6], retries and backoffs =
can occur within the selected protocols, and an action reaches a =
terminal outcome as either success or explicit failure. ACT_DROP is also =
a possible terminal action. The relevant reliability question is =
therefore whether the requested quantum service is completed under its =
specified requirements, rather than whether every individual packet is =
guaranteed to reach a destination unchanged.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>** Routing and Next Hop Selection =
**</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>So, proceeding from this point forward =
as if the routing info is held</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>at the router...</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>A router has a "quantum routing table", =
illustrated in Fig. 5 of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>[5]. &nbsp;(They use "entanglement =
service provider", or "ESP", but as far</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>as I can tell an ESP is just a router, =
so I'll stick with the term</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>router here.) &nbsp;This is Sec. IV-B, =
mentioned above as being where |A_j&gt;</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is defined.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>They define a routing table entry (Fig. =
5) as (I'm reordering fields</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in a way that makes sense to me, not =
their order):</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* the nexthop address (|v_j&gt; in the =
figure; I am going to write it</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>without the ket as v_j since it's =
effectively classical info)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* the matching condition, which is not =
simply a longest prefix, as</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in a UNIX-like or Internet-like FIB; =
it's a *SUPERPOSITION* of the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>addresses of the *NEIGHBORS* of v_j. =
&nbsp;(recall v_j is our</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>neighbor, so this is the neighbors of =
that neighbor)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* some "ebits": I believe these are the =
*actual* qubits that are</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>entangled with the neighbor v_j! =
&nbsp;The result of the routing lookup</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is not just "you should send to v_j", =
it's "here's a qubit entangled</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>with v_j for you to use." &nbsp;(Or, =
presumably, "here are enough qubits</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>to send the entire packet to v_j.") =
&nbsp;Thus, this isn't really a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>_routing_ table, it's a combined FIB and =
buffer management table!</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>This is an important =
distinction.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I put "routing table" in quotes because =
it's not a RIB (routing</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>information base), and in fact I don't =
think it's exactly a FIB</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(forwarding information base) either. =
&nbsp;What I *think* it actually is,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>is a combined FIB and buffer management =
subsystem. &nbsp;This is also a bit</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of a departure from other proposed =
architectures.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>For every virtual neighbor a router has, =
there is an independent</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>routing table entry. &nbsp;It's a little =
bit like an inverted FIB in a UNIX</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>system, where the lookup key is the dst =
addr, and the result is an</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>interface index or a neighbor's address, =
except that we have to scan</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the entire table and query the node =
address superposition in order to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>figure out if this particular neighbor =
is the right match.</div><blockquote type=3D"cite"></blockquote><div><font=
 color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The addresses being matched are *not* =
labeled |A_j&gt; in Fig. 5, but in</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Fig. 7 and Eqs. 36 &amp; 37 they are. =
&nbsp;So I guess we're on solid ground</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>here saying that the we're *NOT* doing =
source routing with the routing</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>table carried in the packet =
itself.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The next hop is selected from this table =
using Grover's quantum search</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>algorithm =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fen.wik=
ipedia.org%2Fwiki%2FGrover%2527s_algorithm&amp;data=3D05%7C02%7Cangelasara=
.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb624=
6b0b1e328f9da0c45fd%7C0%7C0%7C639220367874928871%7CUnknown%7CTWFpbGZsb3d8e=
yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI=
sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DqKh8MkLrfaDx4ChlVShuum2n1swQ0wx=
sfu7DowPlny8%3D&amp;reserved=3D0. Sec. IV</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of [5] covers this in detail. &nbsp;I =
don't believe this is an effective</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>design choice, but I also don't think =
it's actually crucial to the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture so this isn't a showstopper =
criticism. &nbsp;(It is, however,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>one of the key points related to their =
claim that classical control</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>doesn't scale, which, as Wojtek pointed =
out, is claimed frequently but</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>not supported by any data or =
quantitative analysis I have seen in any</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of the papers I have =
read.)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The proposed implementation of Grover =
will require hundreds of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>long-lived, high-fidelity qubits and =
thousands or tens of thousands of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>high-fidelity gates. &nbsp;This =
essentially implies that each quantum</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>router is a full-fledged quantum =
computer, with a lot of memory and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>quantum error correction. &nbsp;This is =
one of the primary reasons I say</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>this is a 4G architecture. &nbsp;It =
assumes an even stronger</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>repeater/router node than the 3G =
architecture.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I spent a long time studying the circuit =
they propose, but in the end</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the key point for our purposes is that =
it selects a virtual neighbor</div>and a buffered qubit or qubits that =
are entangled with that neighbor.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>I think we are mostly aligned here, =
now that the packet-structure issue discussed above has been cleared up. =
A few qualifications, though.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>First, an ESP is not quite =E2=80=9Cju=
st a router.=E2=80=9D In [5], it is a tier-2 Quantum Data Plane entity =
implementing Generalized Quantum Forwarding. This includes next-e-hop =
selection, but also the generation, purification, swapping, =
transformation, and consumption of entanglement resources. Routing and =
next-e-hop selection are therefore only part of its =
role.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Your reading of the =
table is otherwise broadly correct. Each entry couples the e-hop address =
and its matching information with the actual locally stored halves of =
EPR pairs shared with that e-hop. This coupling is deliberate: unlike a =
classical forwarding decision, a quantum-forwarding decision cannot be =
executed independently of the consumable quantum resource required to =
realize it. I agree, however, that simply calling this a =E2=80=9Crouting =
table=E2=80=9D may invite an overly classical RIB/FIB interpretation, =
and we should make the terminology clearer.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The FIB analogy is useful, but I =
would stop short of calling the table a complete buffer-management =
subsystem. [5] does not specify generic buffer-management functions such =
as scheduling, admission control, or replacement policies. I would =
describe it more precisely as an entanglement-aware forwarding table. =
The associated entanglement resources are also not necessarily =E2=80=9Cen=
ough qubits to send the entire packet=E2=80=9D to vj. They are =
pre-established entanglement resources that generalized-forwarding =
operations, such as swapping or purification, can manipulate or consume =
to extend the requested entanglement connectivity. More precisely, the =
lookup identifies a matching table entry and hence the corresponding =
e-hop. That entry stores a certain number of locally held halves of EPR =
pairs shared with the e-hop, which constitute locally available =
entanglement resources for the subsequent generalized-forwarding =
operations. The lookup therefore identifies the entry and it does not =
itself =E2=80=9Creturn=E2=80=9D the stored entangled qubit. Nor does [5] =
assume that their number is determined by the size of the quantum =
packet: the number of entanglement resources maintained per entry is =
explicitly left as a design parameter.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>One further clarification: the =
mechanism does not sequentially scan the entire table. The entry labels =
are prepared in superposition, and the Schr=C3=B6dinger oracle queries =
the associated superposed e-neighborhood information coherently and =
non-destructively. If the target address is absent from a given =
e-neighborhood field, the oracle acts trivially on that field: it is =
neither measured nor modified, and its superposition remains available =
for subsequent queries. If the target is present, the oracle coherently =
couples the corresponding entry label to the hitting component of the =
address field and induces the conditional phase inversion used to mark =
that entry; the address field is still not measured. If no address field =
contains the target, no stored superposed address is measured, =
collapsed, or otherwise altered. Whether this is the right technological =
tradeoff is, of course, a separate and fair question.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>On =E2=88=A3Ajl=E2=9F=A9, why this =
is not source routing, why the table is held locally rather than carried =
in every packet, I think we have already covered the relevant =
distinctions above.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The same applies to the =
architectural status of Grover-based lookup: as discussed above, it is =
one specific mechanism explored in [5], not a requirement of the I-D. =
Likewise, our concern about the scalability of purely classical control =
is not derived from Grover=E2=80=99s speedup or from routing-table size; =
it concerns the reconciliation of a separately maintained classical =
representation with an evolving non-local quantum-resource =
state.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div><div>Finally, I would =
distinguish the resource requirements you mention from the results =
reported in [5]. Figure 7 illustrates a straightforward, explicitly =
unoptimized circuit for a small address size; it is not intended as a =
fault-tolerant resource estimate.</div><div>The figures you mention =E2=80=
=94 hundreds of long-lived qubits and thousands or tens of thousands of =
gates =E2=80=94 do not appear to be results reported in [5], so I assume =
they derive from a separate resource model or implementation analysis =
you conducted (I=E2=80=99m genuinely interested in it). I agree that =
such estimates may well indicate that this particular realization is =
technologically demanding, but they necessarily depend on assumptions =
such as the oracle decomposition, native gate set, error model, and =
error-correction overhead.</div><div>In any case, these costs pertain to =
that particular realization in [5], not to the architectural assumptions =
of the I-D.</div></div><div><br></div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Addressing point &lt;2a&gt; &amp; =
&lt;2b&gt;:</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The "virtual neighbors" are what I am =
calling tunnel endpoints. As</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>best I can tell, the set of neighbors =
for each node is intended to be</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>long-lived. &nbsp;Although other =
researchers have proposed dynamic</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>entanglement swapping with set of =
perpetually-changing neighbors that</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>must be tracked (which I think is =
impractical), I think in the Napoli</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture tunnels are perpetually =
"recharged" with entanglement so</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>that there are always Bell pairs =
available.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>What I have called tunnels, they call =
virtual neighbors with</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"activated entanglement-proximity", and =
the topology on top of that</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>they call the "artificial topology". =
&nbsp;In [5] II-D, they refer to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"artificial topology maintenance" which =
requires them to "continuously</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>regenerate virtual links" as they are =
depleted by forwarding.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Under the assumption that entanglement =
is readily made, this seems</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>like a potentially good choice. &nbsp;It =
can be used to simplify routing</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>around/across a dense network core. =
&nbsp;It's trying to solve the problem</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of potentially needing to understand the =
entire Internet topology,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>which is a crucial =
issue.</div><br></div></div></blockquote><div>Thanks!</div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>As I understand it, if the network =
consists of n_e routers, each</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>router has O(sqrt{n_e}) neighbors. =
&nbsp;Although they use O(.) notation, I</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>believe the intended constant factor is =
1, so if you have 100 routers,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>each has ten neighbors; if you have =
100,000,000 routers, each has</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>10,000 neighbors. &nbsp;10K =
tunnels/neighbors sounds like a lot, but in</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>classical terms it's really not; when I =
was at Network Alchemy around</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the year 2000, we built a VPN gateway =
that used a single Pentium CPU</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>and was designed to handle 30,000 IPsec =
tunnels. &nbsp;Sufficient</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>production of entanglement, availability =
of buffer memory, and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>multiplexing across the tunnels instead =
are the challenges, which</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>aren't really addressed by the Grover =
routing table lookup.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The key idea behind this particular =
number is to make every</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>router-router pair be one or two virtual =
hops away as often as</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>possible, and effectively never more =
than three. &nbsp;This is especially</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>crucial for the Grover lookup, which =
they have designed to search</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>across the set of =
neighbors-of-neighbors. &nbsp;If each router has</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>0(sqrt{n_e}) neighbors, then the set of =
neighbors-of-neighbors is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>O(sqrt{n_e}^2) =3D =
O(n_e).</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>However, intelligent selection of the =
set of neighbors is tricky. If</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>they are selected so that each added =
tunnel adds a new node to the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>topology, of course it will be =
cycle-free, and you will end up with a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>tree that is exactly n_e - 1 =
links.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>If instead they are selected at random =
(with replacement), then the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>topology graph will contain triangles =
and larger cycles. &nbsp;A little</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>calculation shows that as n_e --&gt; =
infinity, P(distance &gt; 2) --&gt; 1/e =3D</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>~36%. &nbsp;That would be a =
problematically large probability in their</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>scheme.</div><br></div></div></blockquote>=
<div><font color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Thanks! This is very useful, because =
I think the probability calculation assumes a different construction =
from the one in [5].</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>First, we do not set the number of =
e-neighbors to sqrt{n_e} with a constant factor of one. In the =
construction, k=3D(1+m)sqrt{n_e} log=E2=81=A1(n_e), which we abbreviate =
as O(sqrt{n_e}). Therefore, the examples of 10 neighbors for 100 nodes =
and 10,000 for 100 million nodes do not follow from the parameterization =
used in the paper. This is also an asymptotic sufficient construction, =
rather than a claim about the operationally optimal number of =
neighbors.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>More importantly, =
e-neighbors are not selected uniformly at random with replacement. For =
an ESP vi, N(vi) is the set of the k ESPs closest to vi according to the =
selected entangling-cost metric w. We deliberately leave the specific =
metric open: it may capture fidelity, entanglement-generation cost, =
delay, or another performance criterion, while requiring it to satisfy =
the metric and isotonicity properties stated in the paper. Overlapping =
neighborhoods are therefore allowed; the construction does not assume =
that every new virtual link reaches a previously uncovered node, nor =
that the neighbors-of-neighbors are disjoint.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The randomized component is instead =
the baseline covering construction. Using known covering results, the =
partial-anchor construction guarantees Property 1 with high probability: =
every e-neighborhood contains at least one anchor. The full-anchor =
construction guarantees Property 2 with high probability: for any =
destination, an ESP has an e-neighbor tracking that destination. These =
properties give paths of at most three and two entanglement hops, =
respectively, with high probability. For additive metrics, the =
corresponding entangling-stretch bounds are five and three. So your =
calculation about asymptotic probability is not the model analyzed in =
[5].</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>I do agree with your =
broader resource point: entanglement generation, quantum-memory =
availability, and multiplexing among concurrent demands are major =
challenges, and the Grover lookup does not solve them. That was not its =
intended role. The narrower question addressed in [5] is whether, once =
the entanglement overlay is constructed according to the stated model, =
quantum-native addressing can provide sublinear routing state and =
bounded entangling stretch.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>[5] III invests a lot of effort in =
discussing path cost and proving</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>various constraints on a couple of =
variants in selection, but TBH I</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>get lost in how the path cost is used to =
select neighbors. &nbsp;Every node</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>creates a tunnel/virtual link with every =
node with an entanglement</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>cost (deliberately left undefined here, =
but could be e.g. time to make</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>a Bell pair) below a certain threshold, =
plus some set of other nodes</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in the network that I think are randomly =
chosen. &nbsp;To me, this scheme</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>seems to require a LOT of classical =
knowledge about the complete</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>network topology, including the ability =
to efficiently determine the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>set of nodes below that threshold and =
the ability to select other</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>nodes in the network at =
random.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Moreover, this results in network-wide =
total work to create and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>maintain sqrt{n_e} tunnels * n_e nodes =3D=
 n_e^{3/2} total virtual</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>links. &nbsp;If n_e =3D 10^8, then this =
is 10^12 total tunnels in the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>network, the vast majority of which will =
never be used.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Instead, it seems crucial to *design* =
the physical and virtual</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>topology to match physical constraints, =
traffic demands and</div><blockquote type=3D"cite"></blockquote><div><font=
 color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>organizational needs.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Which is, in fact, what the Internet's =
three-tier scheme of LAN</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(spanning tree), IGP (OSPF, ISIS, or =
iBGP), and EGP (eBGP) does. It's</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>known to be imperfect, but as an =
existence proof for a network</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>consisting of a lot of routers acting =
autonomously, it's hard to beat.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Our QRNA =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.n=
ii.ac.jp%2Fpi%2Fn8%2F8_65.pdf&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%=
40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da=
0c45fd%7C0%7C0%7C639220367874947901%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG=
kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3=
D%3D%7C0%7C%7C%7C&amp;sdata=3DcwcrVcxQx6kM8HvRkry8ZWe3BokvJrww%2FxFwGqSP2M=
M%3D&amp;reserved=3D0,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fdoi.org%2F10.1145%2F3610251.3610556&amp;data=3D0=
5%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def7898=
0b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874973353%7CUnkn=
own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z=
MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DnRRKsXGNqkqT=
9ZX6VEeV8aMZNbsBJ8z5crnsyudKnmA%3D&amp;reserved=3D0,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F2112.07092&amp;data=3D05%7C02%=
7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2=
fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367874991624%7CUnknown%7CT=
WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF=
OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DH3TTil%2BvySBpEzbtx=
WMzrram5kuomz8GikNDYv2IMJ8%3D&amp;reserved=3D0) attempts to provide =
similar</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>recursive isolation of topology by =
creating connection-based tunnels</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>across individual networks (ASes or =
equivalent).</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>And with all of this I'm once again lost =
as to the expected semantics</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of a "packet". &nbsp;Sometimes it feels =
like a locally-held data structure</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>that is guiding the development of E2E =
Bell pairs, sometimes it feels</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>like a datagram that does get =
transferred (teleported, most likely)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>hop to hop along the path. &nbsp;In =
either case, I'm unclear on how the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"packet" gets from the end node to the =
router (where our discussion</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>has been centered), how many qubits of =
payload it contains, and lots</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>of details about the supporting =
classical signalling (which still</div>seems to be =
necessary).<br></div></div></blockquote><div><font color=3D"#5856d6"><span=
 style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>I =
think the first part is already largely covered by the clarification =
above, but let me make the construction in [5] explicit. An =
e-neighborhood is not formed by taking all nodes below a cost threshold =
and then adding randomly selected nodes. For each ESP v_i, N(v_i) =
contains the &nbsp;k ESPs closest to v_i according to the selected =
entangling-cost metric w. As you noted, the specific metric is =
deliberately left open, so that it can reflect generation time, =
fidelity, physical constraints, or other specific =
criteria.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>The randomized component =
concerns instead the covering strategy, not the selection of low-cost =
e-neighbors. In the partial-anchor scheme, the anchor set is constructed =
using the randomized distributed covering algorithm of Awerbuch, =
Bar-Noy, Linial, and Peleg, =E2=80=9CCompact Distributed Data Structures =
for Adaptive Routing,=E2=80=9D STOC 1989. As discussed in Remark 7, this =
construction requires no a priori knowledge of the complete topology and =
guarantees Property 1 with high probability. In the full-anchor scheme, =
the tier-2 nodes are partitioned into tracked sets and each ESP randomly =
selects one of those sets, yielding Property 2 with high probability. As =
we state in [5], these are deliberately unoptimized baseline =
constructions. Our purpose was to isolate what quantum addressing can =
enable and to derive worst-case guarantees without assuming a =
topology-tailored construction. A clustering or covering strategy =
optimized for the physical topology, traffic, or administrative =
structure could provide better practical performance</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>There is, however, a fair =
implementation question here. [5] does not prescribe the discovery =
protocol through which an ESP identifies its k lowest-cost candidates. A =
naive centralized implementation could certainly use extensive topology =
knowledge, but complete topology knowledge is not a requirement of the =
construction: the paper explicitly allows neighborhoods to be formed =
independently and potentially from partial network views. So I would =
formulate the open question as how to implement scalable e-neighbor =
discovery =E2=80=94 especially across administrative domains =E2=80=94 =
rather than as an intrinsic requirement for every node to know the =
complete topology.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>On =
the aggregate size, your qualitative concern about the cost to create =
and maintain the entanglement graph is fair, and we didn't address this =
cost in [5]. This brings us back to the distinction we have been making =
throughout the discussion. Your concern concerns the resource cost of =
one concrete realization, whereas our analysis asked what becomes =
possible when quantum-native abstractions are extended to the control =
plane. [5] proves sublinear routing-table size per ESP and bounded =
entangling stretch. Conversely, saying that the vast majority of the =
links would never be used would require a traffic model that is not part =
of the analysis. Did you have a particular traffic model or workload =
distribution in mind for that conclusion?</div><div>Saying differently, =
the aggregate scaling you point out is a legitimate consideration when =
assessing this baseline construction as a practical realization. It does =
not invalidate the result per se (scaling quantumness to the control =
plane), but it clearly motivates asking whether the same quantum-native =
capabilities can be exploited with more resource-efficient, topology- =
and traffic-aware constructions.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>I =
also agree that a deployed physical and entanglement connectivity graph =
should reflect physical constraints, expected traffic, and =
organizational boundaries. The entangling-cost metric can incorporate =
some of these factors, but jointly optimizing e-neighborhoods, anchors =
or tracked sets, resource provisioning, and traffic demand is left open =
in [5]. This is also one reason why the I-D deliberately defines =
architectural principles without prescribing these =
mechanisms.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Thanks also for pointing =
us back to the QRNA work. It is clearly relevant to recursive topology =
abstraction, administrative isolation, and inter-domain organization, =
and we should cite it explicitly in the revised discussion. I see it as =
complementary rather than as addressing the same question: recursion can =
limit how much of a domain=E2=80=99s internal topology must be exposed, =
whereas our quantum-native control abstractions address how the control =
plane represents and operates on dynamically evolving entanglement =
resources. A recursive or federated organization would still need to =
define how resource representations are associated and reconciled across =
domain boundaries.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Finally, I think the =
packet-semantics questions in your last paragraph are the same ones =
addressed above, so I will not repeat the full explanation here. In [5], =
a tier-1 node is associated with a serving ESP and may delegate the =
richer inter-ESP forwarding decisions to it. However, the routing =
analysis in [5] focuses on the tier-2 ESP overlay. It does not prescribe =
the tier-1 access protocol, a fixed payload size, or the detailed =
classical-signaling procedures. Classical signaling remains necessary, =
we are not claiming otherwise. [6] provides a more concrete realization =
of how physical transfer, local packet transformations, and classical =
signaling interact. These are valid protocol-design questions, but they =
concern specific mechanisms that the I-D deliberately does not =
prescribe.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Anyway, the questions =
you raise are genuinely interesting. Several of them go beyond what we =
analyzed in [5] and require further investigation by the =
community=E2=80=94including us.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>The 1G, 2G, 3G taxonomy =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.n=
ature.com%2Farticles%2Fsrep20463&amp;data=3D05%7C02%7Cangelasara.cacciapuo=
ti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f=
9da0c45fd%7C0%7C0%7C639220367875025533%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1=
hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf=
Q%3D%3D%7C0%7C%7C%7C&amp;sdata=3DPExozkOD2EWfoGn1l6uJdnU13xrxTKV7SYU%2Fmte=
5hZ0%3D&amp;reserved=3D0) is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>about increasingly demanding management =
of errors (photon loss, state</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>&amp; gate errors, decoherence). =
&nbsp;The Napoli architecture assumes:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* high entanglement =
rate</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* high fidelity =
entanglement</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* high availability of quantum memory at =
routers</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* low-latency, high-speed quantum =
computation</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>So while it's not fully accurate to =
classify this architecture in the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>same way, I think it's fair to call it a =
post-3G network. &nbsp;I'll just</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>settle for 4G for the =
moment.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>...and the next extension to the =
architecture actually *DOES* deal</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>with both errors and with classical =
messaging. &nbsp;The newest paper,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"Beyond Layering" [6], introduces =
"stamps" attached to packets. Each</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>stamp represents a requested piece of =
functionality, such as</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>purification. &nbsp;These stamps seem to =
be about halfway in between our</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>RuleSets and David Tennenhouse's IP =
Capsules from the 1990s (predating</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>and in some ways heralding =
SDN),&nbsp;</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Fdl.acm.org%2Fdoi%2Fabs%2F10.1145%2F231699.231701=
&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4=
b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875=
048930%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI=
sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3D=
EIVbZvy2sA%2FxHoifJQpppuy8UHb6a%2BHRAjLgvnl%2BseE%3D&amp;reserved=3D0.</di=
v><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>This one is such a departure from the =
others that it doesn't even</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>mention virtual links or address =
superposition or routing, though its</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>main example does talk about teleporting =
over a two-hop overlay. It's</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>much more focused on the concrete tasks =
necessary for processing a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>single request. &nbsp;It still doesn't =
really take up the issue of a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>connection, and doesn't discuss =
multiplexed use of entanglement</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>resources.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>See [6] Fig. 4. &nbsp;This is an =
incredibly helpful figure for</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>understanding the lower-level =
architecture they propose. &nbsp;The</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Initiator (I'm very happy to see the use =
of this term rather than</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>"source") creates a Plan of Action (PoA) =
for the packet. &nbsp;The PoA is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>only held locally, and is generated =
separately at each node for each</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>packet, but its core is translated into =
a set of Stamps are requests</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>for specific actions. &nbsp;Stamps are =
carried in the packet itself, and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>can include things =
like:</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* LINK_PR</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(purification request? not =
sure)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* ACT_FORWARD</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* ACT_HOLD</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* (local SWAP at the intermediate node =
isn't part of the plan decided</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>by the Initiator?)</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* CONSUME_TP</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>(complete the =
teleportation?)</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Classical messages can be emitted, and =
can trigger further actions at</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the receiving ends.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>There are some details here that can be =
quibbled about, but the basic</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>structure of the PoA is good. =
&nbsp;However, as noted above, I think this</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>should be done using (classical) state =
at routers along the path,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>rather than being incorporated into the =
quantum packet.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I still don't fully understand the =
packet format, including how many</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>qubits are in the header and in the =
payload. &nbsp;The payload seems to be</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>intended to carry halves of Bell pairs =
from the Initiator, or possibly</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>an intermediate node in the path, to the =
destination (what we would</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>call "Responder" in connection setup, =
but they don't have that</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>notion).</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>One issue is that the Stamps are to be =
carried in the quantum packet,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>which means they are likely to consume a =
lot of quantum bandwidth and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>demand high-fidelity carriage, otherwise =
the Stamps will become</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>corrupted.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I would like this design a lot better if =
the quantum header were</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>simply turned into a classical header. =
&nbsp;Then we would have a simple</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>argument about the locus of state, =
whether it should be distributed or</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>localized to a single node. &nbsp;I =
think this argument will come down to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>how much work turns out to be absolutely =
necessary in the middle of a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>path as the technology develops. =
&nbsp;If we do wind up really needing</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>purification and anything other than =
straight-up entanglement swapping</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>in more than one or two places in the =
path, I think we will wind up</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>with the distributed connection. =
&nbsp;That's the way I think of =
our</div>architecture.<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Thanks, Rod. I am very glad that =
Fig. 4 helped clarify the Dynamic-Kernel structure and that you find the =
basic PoA organization convincing.&nbsp;</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>On the 1G=E2=80=933G taxonomy and =
the technological assumptions that you attribute to the architecture, I =
think we have already explained our position above, so I will not repeat =
it here. The same applies to the general packet abstraction and the =
distinction between the I-D, [5], and [6].</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>There is, however, one important =
clarification concerning Fig. 4. Stamps are not requests for actions, =
and the Initiator does not translate its PoA into a set of stamps for =
downstream execution. Each node independently constructs its own local =
PoA from the service intent, the accumulated stamps, and its current =
local state and capabilities. A stamp is appended only after an action =
has reached a terminal outcome. Thus, LINK_PREP, SWAP, CONSUME_TP, and =
ACT_FORWARD in the stamp trace certify actions that have already =
committed; they are not instructions for future execution. In the =
specific Fig.4 trace, ACT_HOLD, instead, is local soft state and =
deliberately produces no stamp. The SWAP in the example is planned and =
executed locally by the intermediate node Y, and its successful =
completion is then recorded in the meta-header.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>I would describe [6] as a different =
architectural dimension. [5] develops one specific quantum-routing =
mechanism, whereas [6] proposes a protocol-suite organization that =
replaces fixed layering with the dynamic composition of network =
functionalities. For that reason, [6] deliberately does not prescribe =
one particular realization of routing for example. The wanted =
functionalities can be realized by suitable micro-protocols or =
meta-protocols and composed at runtime according to the service intent, =
the available node capabilities, and the current resource state. Quantum =
Addressing can likewise be used within the service intent and by the =
composed control and forwarding functions. The teleportation scenario is =
therefore an example of how the composition model operates, not a =
proposal that every service must use that particular overlay or sequence =
of mechanisms. The point of [6] is to avoid fixing their interaction =
through permanent layer boundaries before those mechanisms and =
technologies have matured.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>On =
replacing the quantum meta-header with a classical header, this is =
probably still where we disagree most. I agree that a classical =
realization of part of the Dynamic-Kernel execution model is possible in =
a controlled environment. In fact, we have now experimentally realized =
the dynamic-composition principle through classical orchestration in =
NeQOS (https://github.com/QuantumInternet-it/NeQOS)&nbsp;and deployed it =
on the QuantumInternet.it multi-vendor testbed, coordinating up to 23 =
quantum-classical devices from four vendors over deployed fiber. That =
work is currently under review and is therefore not yet publicly =
available.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>This implementation =
deliberately uses a controlled setting in which the participating =
devices, resource identifiers, topology, workflows, and coordination =
channels are known and bounded. It demonstrates that the Dynamic-Kernel =
principle can be realized with current technology. &nbsp;It should be =
noted that the implementation is limited to the Executor and part of the =
Engine. In particular, a physical quantum meta-header is not =
implemented. Therefore it does not validate the complete suite proposed =
in [6].&nbsp;</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>In =
that more general setting, a classical header can certainly describe the =
requested operations, but an explicit mechanism is still needed to bind =
that header to the corresponding quantum resource and to keep the two =
aligned as the resource is generated, purified, swapped, forwarded, =
consumed, or lost. That association is not impossible, but it introduces =
an additional reconciliation problem. Our concern is that =E2=80=94 as =
said above =E2=80=94 beyond controlled environments, continuously =
maintaining that alignment across independently operated nodes and =
domains could become a scalability bottleneck.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The in-band quantum meta-header is =
intended to reduce the scope of this separation: it keeps the a =
service-scoped, append-only, single-writer procedural state=E2=80=94the =
service intent and immutable commit history=E2=80=94 operationally =
coupled to the evolution of the quantum packet and its resources. This =
localizes the context required by the next Dynamic Kernel and reduces =
reliance on separately replicated procedural history, It also preserves =
quantum-native control information, such as Quantum =
Addressing.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Your concern about =
quantum bandwidth and corruption is nevertheless completely fair. =
Quantum header fields consume physical resources and require suitable =
protection; [6] does not yet provide a quantitative comparison of that =
cost. But the corresponding cost of a classical solution is not zero =
either: it includes association, signaling, state replication, and =
reconciliation. So I do not think we can conclude a priori that turning =
the quantum header into a classical one is the better general solution. =
The comparison has to account for both costs under the same network, =
hardware, failure, and traffic assumptions.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>So, in short: yes, classical control =
alone can work=E2=80=94and we have demonstrated a classical realization =
of the dynamic-composition principle on a real testbed. I just do not =
agree that this removes the architectural motivation for quantum-native =
in-band control outside controlled environments (which will augment =
classical control). The stronger motivation for quantum-native control =
concerns coherent control variables whose semantics cannot be preserved =
by an ordinary classical field. Our claim should therefore not be that =
classical control cannot operate a quantum network, but that it cannot =
be the only control representation.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>To extend the comparison a little more =
with our QRNA/RuleSet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture =
(https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv=
.org%2Fabs%2F2112.07092&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unin=
a.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd=
%7C0%7C0%7C639220367875071475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy=
dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7=
C0%7C%7C%7C&amp;sdata=3DIDxA6Pjh4ArAorPGC0bP%2BxplM%2BzJCAffiLRv9QXwoY8%3D=
&amp;reserved=3D0</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>https://nam12.safelinks.protection.outlook=
.com/?url=3Dhttps%3A%2F%2Farxiv.org%2Fabs%2F2112.07093&amp;data=3D05%7C02%=
7Cangelasara.cacciapuoti%40unina.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2=
fcfe26abb6246b0b1e328f9da0c45fd%7C0%7C0%7C639220367875098972%7CUnknown%7CT=
WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF=
OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DBkeu6zL6jOtpVoLXsLO=
BHNSuXsCLsJjFtKnPyhjH00I%3D&amp;reserved=3D0 =
https://nam12.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Farxiv.=
org%2Fabs%2F1904.08605&amp;data=3D05%7C02%7Cangelasara.cacciapuoti%40unina=
.it%7Cb4d0e3b2a0f44ea4b82e08def78980b9%7C2fcfe26abb6246b0b1e328f9da0c45fd%=
7C0%7C0%7C639220367875126357%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd=
WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C=
0%7C%7C%7C&amp;sdata=3DyHH21ID4fYODRomddK9HWNALgfWeMb9eS77eEH9klLM%3D&amp;=
reserved=3D0):</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* Plan of Action (PoA): like our =
RuleSet, describes a sequence of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>things that should happen. &nbsp;Our =
RuleSets are stateful, defined by</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the Responder during connection setup, =
and live through the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>connection. &nbsp;Napoli PoA is =
ephemeral, defined locally for a packet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>and lives only until that packet =
processing at the local node is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>complete (which could actually be until =
the E2E transaction is</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>complete).</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* Dynamic Kernel: like our RuleSet =
Engine.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* Stamps: like our Rules. &nbsp;Each =
Rule of ours contains a Condition</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Clause and an Action Clause. =
&nbsp;Stamps likewise wait for some</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>condition to be fulfilled before they =
can be "committed".</div><blockquote type=3D"cite"></blockquote><div><font=
 color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The biggest difference is our =
full-path, fully distributed but</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>asynchronous *computation* which results =
in creation of E2E</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>entanglement, versus their emphasis on =
trying to be closer to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>hop-by-hop and to carry less state at =
intermediate nodes. &nbsp;Given</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>that an entire PoA can't be retired =
until the local resources can be</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>reclaimed, this is maybe not as big a =
difference as it first seems.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Overall, except for the need for =
high-fidelity bandwidth to carry the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Stamps in-band, this is a 1G =
architecture, I think, and much more</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>implementable than the 4G stuff in the =
first half of this message.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>One open agenda item, from my point of =
view, is improving the</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>integration of those two sets, assuming =
that is indeed the Napoli</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>plan.</div><br></div></div></blockquote><d=
iv><font color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Rod, I agree that there is certainly =
a family resemblance at the very general level of distributed local =
execution. However, I think the proposed one-to-one mapping obscures the =
distinctive contribution of [6]. Let me try to spell out the differences =
as I see them.</div><div>This is not a judgment that one model is =
universally better than the other. They make different architectural =
choices about where execution authority resides, when protocol logic is =
constructed, how long that logic persists, and how globally consistent =
progress is established. Precisely for these reasons, however, I would =
distinguish [6] quite clearly from QRNA/RuleSets.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>In QRNA, recursion is organized =
through scoped connection layers: connection requests move between =
recursive levels, RuleSets may be rewritten at domain boundaries, and a =
two-pass setup installs connection-scoped programs at the nodes along =
the path. Indeed, in QRNA, connection establishment follows a two-pass =
procedure. First, a request travels from the Initiator to the Responder =
and collects information about the path and available resources. The =
Responder then constructs the RuleSets, which are distributed on the =
return path and installed at the participating nodes as state associated =
with that specific connection.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This is precisely where [6] takes a =
different architectural direction. It does not establish an end-to-end =
connection by constructing and distributing a path-wide program. No =
Initiator, Responder, controller, or intermediate domain determines the =
complete execution logic in advance. Instead, every node constructs a =
new local PoA at runtime from the service intent, the commit history, =
and its current state and capabilities. The network-wide execution =
structure emerges progressively from those local =
decisions.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>The PoA is therefore not =
a short-lived RuleSet. A RuleSet is a program installed for a specific =
connection that prescribes which actions should be executed when the =
corresponding conditions are met, even when those actions occur =
asynchronously.</div><div>A PoA is a locally synthesized, speculative =
DAG that exists only to determine what can be executed in the current =
context of the node. Once the selected local actions have terminated and =
meta-header authority has been transferred, that PoA can be discarded. =
The PoA remains entirely local to the node that constructs it: it is =
never announced, transmitted, or installed at another =
node.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Likewise, the Dynamic =
Kernel is not simply another RuleSet Engine. A RuleSet Engine evaluates =
the conditions and executes the actions of a program installed during =
connection setup. A Dynamic Kernel runs at each node and constructs the =
local program itself: it plans candidate actions, evaluates resource and =
capability constraints, binds the selected actions to the =
micro-protocols currently available, dynamically composes those =
micro-protocols into meta-protocols, and executes the resulting =
schedule.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Stamps are also not =
analogous to Rules. A Rule is a conditional instruction waiting to be =
executed. A stamp is an immutable record generated only after an action =
has reached a terminal outcome. It contains no Action Clause for future =
execution and never waits for a Condition Clause to become true. It =
tells the next Dynamic Kernel what has already committed, thereby =
constraining=E2=80=94but not prescribing=E2=80=94the next locally =
generated PoA. Their temporal and operational semantics are therefore =
almost opposite.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The computation in [6] is also fully =
distributed, but it is distributed in a different sense. QRNA =
distributes a program across the connection path before execution. In =
[6], no global program is distributed: the network-wide =
service-fulfillment DAG emerges from independently generated local PoAs =
and their committed outcomes. Moreover, micro-protocols and dynamically =
composed meta-protocols may themselves coordinate operations across =
multiple nodes, using classical signaling whenever required, without =
relying on network-wide synchronization. This should therefore not be =
reduced to classical hop-by-hop processing.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>The distinctive=E2=80=94and, to the =
best of our knowledge, unique=E2=80=94combination explored in [6] is the =
runtime construction of local PoAs, the dynamic composition of reusable =
micro-protocols as the organizational logic that replaces fixed layering =
while preserving modularity, commit-only in-band stamps, and the =
emergence of a network-wide execution DAG without distributing or =
maintaining a path-wide program.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Finally, I do not think that there =
are two Napoli architectural =E2=80=9Csets=E2=80=9D waiting to be =
integrated. [5] instantiates a particular routing mechanism enabled by =
Quantum Addressing. [6] defines a protocol-organization model within =
which routing and other functions can be dynamically composed. A routing =
mechanism such as the one in [5] can therefore be instantiated within =
this organization, but it is not required by it.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>This separation is not only =
conceptual. In NeQOS=E2=80=94our experimental implementation =E2=80=94we =
realized the dynamic-composition principle, specifically the Executor =
and part of the Engine of the Dynamic Kernel, without implementing the =
routing mechanism proposed in [5]. We used it to operate =
entanglement-based network services and applications on a deployed, =
multi-vendor quantum-network testbed, including sustained =
polarization-drift characterization across quantum links. This provides =
concrete evidence that the protocol-organization model of [6] is not =
tied to the particular routing mechanism developed in [5]. At the same =
time, there is no incompatibility in the opposite direction: the =
mechanism proposed in [5] can be expressed within the compositional =
logic of [6], by realizing its routing and generalized-forwarding =
operations through dynamically composed micro-protocols.</div><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>-----</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Okay, that's more than enough for now. =
&nbsp;Just a few minor notes to</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>close things out:</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The "orthogonal subspace" of the =
address encoding seems to be</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>unnecessary, and might even rest on some =
misunderstanding of</div><blockquote type=3D"cite"></blockquote><div><font=
 color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>encoding data in quantum =
states?</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* The term "ebit" is already defined =
with a different meaning, long</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>ago. &nbsp;See early Bennett papers. =
&nbsp;Let's not run around redefining</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>terms unless necessary.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* As anybody hanging around QIRG can =
tell you, I dislike the use of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>the term "forwarding" unless you're =
really literally forwarding a</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>packet to another node.</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>* In Sec. 4 of the I-D, we have "This =
section extends Section 5 of</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>[RFC9340].&lt;/par&gt; The Quantum =
Internet is an entanglement-packet</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>switching network,..." that wording =
gives the impression that 9340</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>defines the Quantum Internet as a =
packet-based network, which it</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>does not. I recommend you reword it to =
be clear that packet-based is</div> your proposal (though I think not =
completely original).<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>On the =E2=80=9Corthogonal =
subspace,=E2=80=9D I am not sure which passage you are referring to, =
since this does not appear in the I-D. This concept appears in both [5] =
and [6], but in different senses. In [5], orthogonal computational-basis =
states encode perfectly distinguishable node addresses. In [6], =
orthogonality is used for meta-header/payload separation. What we =
actually require in [6] are independently addressable subsystems=E2=80=94o=
r degrees of freedom=E2=80=94with header operations acting trivially on =
the payload. Orthogonality is one possible realization, but is not =
generally sufficient to guarantee non-perturbing access. So, fair =
point.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>On =E2=80=9Cebit,=E2=80=9D=
 agreed. We used the term to denote one locally held member of an EPR =
pair. This creates ambiguity with its alternative meaning as a unit of =
bipartite entanglement associated with the pair rather than with either =
constituent qubit.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>On =
=E2=80=9Cforwarding,=E2=80=9D I know we disagree on the terminology :-) =
We use =E2=80=9Cgeneralized=E2=80=9D deliberately because the function =
includes operations such as swapping and purification, as well as =
physical transfer when required. We will make that broader meaning =
explicit and we will also revisit whether another term would avoid =
confusion.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><div>Finally, agreed on the =
wording concerning RFC 9340. We will make it explicit that the =
entanglement-packet-switching model is our proposal, not something =
defined by RFC 9340. And yes, we are not claiming that the general idea =
of packet-based quantum networking originated with us. Our contribution =
concerns the particular architectural role and structure assigned to the =
quantum packet and its integration with quantum-native control and =
generalized forwarding.</div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div>Whew!<br></div></div></blockquote><div><font =
color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div><font color=3D"#5856d6"><span =
style=3D"caret-color: rgb(88, 86, =
214);"><br></span></font></div><div>Whew indeed=E2=80=94and thank you =
again for investing so much time in this. Your comments have made very =
clear where our wording allows the architectural principles of the I-D =
to become confused with the specific mechanisms explored in [5] and [6]. =
We have quite a bit to fix and clarify in the next =
revision.</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
rgb(88, 86, 214);"><br></span></font></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I think I now have a moderate =
understanding of the overall Napoli</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>architecture. &nbsp;I'm not sure yet how =
they overall want to move forward,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>but it's great to see the architectural =
ideas becoming more =
concrete.</div></div></div></blockquote><div><br></div>We are revising =
the draft accordingly to the replies and your comments! Thanks a =
lot<br><blockquote type=3D"cite"><div><div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>I'm off to West Virginia to see family, =
then Korea for a workshop,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Indonesia for work, then back home, then =
I'll see Sara, Joaquin and</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>others in Toronto! &nbsp;So I'll likely =
be even worse than usual about</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>responding to email, but I'll try to =
keep up.</div><blockquote type=3D"cite"></blockquote><div><font =
color=3D"#00afcd"><span style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>Happy August, y'all,</div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div>--Rod<br></div></div></blockquote><div><br>=
</div><div>Sara&nbsp;</div><div><br></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"></blockquote><blockquote=
 type=3D"cite"></blockquote><div><font color=3D"#00afcd"><span =
style=3D"caret-color: rgb(0, 175, =
205);"><br></span></font></div><blockquote type=3D"cite"><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#12c00e"><span =
style=3D"caret-color: rgb(18, 192, =
14);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div><font color=3D"#12c00e"><span =
style=3D"caret-color: rgb(18, 192, =
14);"><br></span></font></div><blockquote =
type=3D"cite"></blockquote><div>__________________________________________=
_____</div><blockquote type=3D"cite"></blockquote><div>Qirg mailing list =
-- qirg@irtf.org</div>To unsubscribe send an email to =
qirg-leave@irtf.org<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br></div></div></blockquote></div><br></bo=
dy></html>=

--Apple-Mail=_5B93045B-E2E0-45E9-9BD5-DF31CC3D6F0E--