Subject: Re: [Qirg] GitHub PR Patch 1

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 4 Feb 2020 00:02:33 +0000

Re: https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/1

Hi Patrick,

Thanks for the pull request!

I've finally had some time to look at it now that I'm back to working on the
draft and before I include your changes I have some questions:

> Bell's pair-generating sources are part of the link.

[WK] I'm not sure I'd say the that the sources are part of the link, but the
link is crucial part of the generation process. I think it's worth returning to
this point once I sort out Sara's contribution about elementary link
generation.

> Quantum internet must support the diversity of encoding schemes.

[WK] I'm not enough of an expert to make a judgement on whether this should or
should not be part of the draft. I've heard of other encoding schemes before,
but not in the context of networks before. Can you explain a bit more about
this and if this will be practical in a quantum network context?

> Need an interconnection protocol to distribute Bell peer between autonomous
systems

[WK] Agreed, a brief addition like yours is good. Will include it. Would it be
worth adding some mention of potential challenges? Such as one AS having one
qubit of the pair and the other AS the other? Without too much detail though.

> Do not prematurely close the door to super dense coding that can be used for
example to transport control plane of classical and quantum Network. In this
use case the control plane can be seen as a quantum application that consumes
quantum bits to realize its functions.

[WK] I'm not sure why you would ever send control information over a quantum
channel. In general classical channels will be cheaper and more practical and
it would be wasteful to use qubits to send control information (where you need
10s of bits for each qubit you transmit). Could you explain a bit more?

> Bell pairs are also the basic fundamental unit for building complex multi-
partite entanglement state shared among several nodes of the network.

[WK] Agreed, will be included.

Cheers,
Wojtek

---

From: Bruno Rijsman <[email-masked]>
Date: Tue, 4 Feb 2020 18:01:18 -0600

I finally got around to generating the pull request for the long-promised new section "Comparison with multi-protocol label switched (MPLS) networks.” for the "Architectural Principles for a Quantum Internet” draft (draft-irtf-qirg-principles-03).

https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3 <https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3>

— Bruno

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 5 Feb 2020 16:51:33 +0000

Hi Wojtek

Thank you for taking the time to respond to my request.

Bests regard

Patrick

-----Message d'origine-----
De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : mardi 4 février 2020 01:03
À : [email-masked]
Objet : Re: [Qirg] GitHub PR Patch 1

Hi Patrick,

> Bell's pair-generating sources are part of the link.

[WK] I'm not sure I'd say the that the sources are part of the link, but the link is crucial part of the generation process. I think it's worth returning to this point once I sort out Sara's contribution about elementary link generation.

[PG]

My request is linking to the answer of Rodney :
De : Rodney Van Meter <[email-masked]>
Envoyé : vendredi 15 mars 2019 13:24
À : Gelard Patrick <[email-masked]>
Cc : Rodney Van Meter <[email-masked]>; Wojciech Kozlowski <[email-masked]>; [email-masked]
Objet : Re: [Qirg] agenda

An interesting question we have waffled about in our design is whether the satellite (or any entangled photon pair source, which we call an EPPS) is part of the link, or a node visible at the network level.  Our current stance is that it’s only part of the link, and can’t be addressed in (e.g.) our connection setup process.  It’s handled instead by a link-layer protocol. Why? Because nodes farther away than the ones receiving those photons never need to send a message to the EPPS.

There are three major link timing regimes:
* meet-in-the-middle, which we call M—>I<—M, memory—>interference<—memory or MIM
* sender-receiver, which we call memory—>memory or MM
* midpoint source, which we call memory<—source—>memory or MSM

Cody Jones et al. (at least one of “al.” is on this list, I believe) did some great analysis on MSM links.
https://arxiv.org/abs/1505.01536

—Rod

> Quantum internet must support the diversity of encoding schemes.

[WK] I'm not enough of an expert to make a judgement on whether this should or should not be part of the draft. I've heard of other encoding schemes before, but not in the context of networks before. Can you explain a bit more about this and if this will be practical in a quantum network context?

[PG]
Quantum states can be implemented by different physical media with different degrees of freedom (DoF) to encode quantum information. A quantum systems can be classified into two categories, depending on the dimensionality of the parameter space that is needed to describe their features accurately. On the one hand, there are quantum features that require a finite dimension.

Light is the most widely used physical medium for communications. It is exploited its different properties (polarization, frequency, angular momentum) and states (Gaussian like coherent state; non-Gaussian like Fock state) to encode quantum information for :

-          entanglement of different states of quantum information.

-          error correction

-          classic information transport

Thus, a quantum state which is represented in a Hilbert Space and can be of finite dimension we will speak of Qubit (Hilbert space of dimension 2) or more generally Qudit (Hilbert space of dimension d), but also of infinite dimension, in this case we will speak of Qumode.

Here it seems that, in a first time, we are rather interested in the notion of Qubit and entanglement of different states of quantum information.

Two-state systems called quantum bits (qubits) can be encoded on the basis of a discrete state (i.e discrete variable) exploiting different degrees of freedom of like spatial, temporal, and polarization (Angular Momentum, Time-bin, Polarization, …). For example with polarization DoF : |ψ> = c0 |H> + c1 |V>

The Qubit can also be encoded on the base of continue state (i.e continue variable). For example, In the domain of continuous variables, a Qubit can be coded as superposition of coherent field: coherent state of light: |ψ> = cα |α> + c-α |-α> or of compressed opposite phases (E.g "Schrödinger cat" states).

As the quantum internet will be a heterogeneous network interconnection all these modes of encoding quantum information must be able to be used

> Need an interconnection protocol to distribute Bell peer between

> autonomous

systems

[WK] Agreed, a brief addition like yours is good. Will include it. Would it be worth adding some mention of potential challenges? Such as one AS having one qubit of the pair and the other AS the other? Without too much detail though.

> Do not prematurely close the door to super dense coding that can be

> used for

example to transport control plane of classical and quantum Network. In this use case the control plane can be seen as a quantum application that consumes quantum bits to realize its functions.

[WK] I'm not sure why you would ever send control information over a quantum channel. In general classical channels will be cheaper and more practical and it would be wasteful to use qubits to send control information (where you need 10s of bits for each qubit you transmit). Could you explain a bit more?

[PG] My resquest is about : quid of the high-dimensional encoding of quantum information (Qudit, Qumode). There are many study on this topic. https://onlinelibrary.wiley.com/doi/full/10.1002/qute.201900038    Why don’t use it to carrier classical information ? if you were to deploy a quantum network for the first time why don’t use quantum canal to carrier control plan (which does not require a lot of traffic) of quantum Network ?

> Bell pairs are also the basic fundamental unit for building complex

> multi-

Cheers,

Wojtek

_______________________________________________

Qirg mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/qirg

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 11 Feb 2020 15:41:18 +0000

Hi Bruno,

Thanks for your contribution! It's written quite clearly so I have no questions or need clarifications. However, it is quite long and verbose which doesn't fit with concise character of the rest of the draft. The material is good though so worth keeping it around somewhere, but I'm hoping to cut it down a bit for this draft. At the moment it's about 3 pages making it about 10% of the entire content. I suggest we draw out the key points from this analogy for this draft.

Having read the section many times I think it can be split into two separate concepts - signalling + match-action rules, and resource reservation + traffic engineering. I think the latter can be left out from this draft. Variations of the match-action rules concept is pretty present in literature come to think of it (even it it's not called that) and given that the pairs don't carry headers it is the natural approach. Resource reservation + traffic engineering is I think a broader and deeper area.

One thing that would be worth mentioning in this section is to simply answer the question "why are we making this analogy"? My take on it is that the undirected nature of entangled pairs (they don't proceed in a line from source to destination, but rather the whole circuit can work on it at the same time) very much lends itself to some form of a circuit approach with match-action rules closely mimicking label swaps.

At the same time it's also worth pointing out that circuits aren't the only way to go around quantum networking with entangled pairs. For example, in https://www.nature.com/articles/s41534-019-0139-x the authors do not consider individual circuits, but instead with a correct local strategy, the two nodes will end up with an entangled pair. Of course, this may well have other complications (e.g. how to install these rules if not using circuits), but my point is only that there may well be a variety of approaches so it's worth avoiding language implying that this is the one and only correct way of doing things. If memory lifetimes were good enough and performance was not a concern, hop-by-hop would be entirely possible so it's worth avoiding language implying this is a MUST rather than a very plausible candidate.

I'd probably also skip point 9 about fully centralised vs distributed. It is correct, but I feel like the text doesn't lose anything if you remove it.

Anyway, all of the above is up for discussion though conciseness would very much be welcome either way :)

Thanks,
Wojtek

On Tue, 2020-02-04 at 18:01 -0600, Bruno Rijsman wrote:
I finally got around to generating the pull request for the long-promised new section "Comparison with multi-protocol label switched (MPLS) networks.” for the "Architectural Principles for a Quantum Internet” draft (draft-irtf-qirg-principles-03).

https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_3&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=HG745pqKDMrOuvEGoaOzZ8E5Zcz6AQe7iFqbW3KHBvU&s=16hS14fH5Dg8j-XMAdSPQuHiuTKymyP6Ox-GffCMcgE&e=>

— Bruno

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 11 Feb 2020 16:01:42 +0000

Responses inline

On Wed, 2020-02-05 at 16:51 +0000, Gelard Patrick wrote:

Hi Wojtek

Bests regard

Patrick

-----Message d'origine-----
De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : mardi 4 février 2020 01:03
À : [email-masked]
Objet : Re: [Qirg] GitHub PR Patch 1

Re: https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/1<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_1&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=Y-L5ux1nx2cE4n0_44-DYxXLvMwwm6j-ig1CPFAEAL4&e=>

Hi Patrick,

[PG]

Cody Jones et al. (at least one of “al.” is on this list, I believe) did some great analysis on MSM links.
https://arxiv.org/abs/1505.01536<https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1505.01536&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=LlizVuEvLLRZ5oMajpGlgWVy0hziruxRChFw7sdfC8I&e=>

—Rod

[WK] Good point. I am currently finalising the elementary-link generation section with Sara and it will mention this. I agree with you that it would be worth making it clear that the entangled pair source is part of the link even if it is a physically separate entity in the section that defines the elements of the network. I take it for granted, but it's not obvious especially if the mid-point/source is a satellite which is a scenario I keep forgetting about. In that case, I would suggest you wait until I send that update to the mailing list and then you can expand on this point (including the points mentioned in the e-mail above) and refer to that text on the elementary link generation.

[PG]

-          error correction

[WK] This is getting too close to physical hardware for this draft in my opinion. Obviously, physical realisation aspects are important, but I would remain wary about how much of that is necessary in this document. Unless other people feel strongly about this, I'm not sure this should be included.

systems

[PG] My resquest is about : quid of the high-dimensional encoding of quantum information (Qudit, Qumode). There are many study on this topic. https://onlinelibrary.wiley.com/doi/full/10.1002/qute.201900038<https://urldefense.proofpoint.com/v2/url?u=https-3A__onlinelibrary.wiley.com_doi_full_10.1002_qute.201900038&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=1dwFov1-yBjn6et2bo8Jy5-QTTO14ZKu0shK4bxNcLE&e=>    Why don’t use it to carrier classical information ? if you were to deploy a quantum network for the first time why don’t use quantum canal to carrier control plan (which does not require a lot of traffic) of quantum Network ?

[WK] I'm still not sure why use the quantum channel to carry classical data. Installing a separate classical channel would be much cheaper and more efficient. If security was a concern, why not just encrypt/authenticate? And I disagree, classical control traffic will not be negligible. Every generated pair will need some amount of metadata sent back and forth to keep track of it and its swaps.

Cheers,

Wojtek

Qirg mailing list

https://www.irtf.org/mailman/listinfo/qirg<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwMGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=zTurpQGFgy2hTdSUcvYihgYwBfSw95qFaux0DCXFjMM&s=Bha1cNqIDcir2fDm_rrOdRjjly2a1vVtqgr4F97Px4I&e=>

---

From: Bruno Rijsman <[email-masked]>
Date: Tue, 11 Feb 2020 16:14:32 -0600

Hi Woj,

Thanks for the feedback.

I agree with most of your points:

- I will attempt to (drastically) reduce the verbosity 

- Add a “why” sentence

- Allow for non-circuit approaches

- The centralized vs distributed discussion can be removed

I do however, I think that a brief mention of the topic of resource reservation would be good to keep. Although reasonable people might have different opinions on the need for resource reservation, to me it seems almost unavoidable given the extreme resource constraints in quantum networks for the foreseeable future.

I will update the pull request and re-submit it.

— Bruno

> On Feb 11, 2020, at 9:41 AM, Wojciech Kozlowski <[email-masked]> wrote:
> 
> Hi Bruno,
> 
> At the same time it's also worth pointing out that circuits aren't the only way to go around quantum networking with entangled pairs. For example, in https://www.nature.com/articles/s41534-019-0139-x <https://www.nature.com/articles/s41534-019-0139-x> the authors do not consider individual circuits, but instead with a correct local strategy, the two nodes will end up with an entangled pair. Of course, this may well have other complications (e.g. how to install these rules if not using circuits), but my point is only that there may well be a variety of approaches so it's worth avoiding language implying that this is the one and only correct way of doing things. If memory lifetimes were good enough and performance was not a concern, hop-by-hop would be entirely possible so it's worth avoiding language implying this is a MUST rather than a very plausible candidate.
> 
>> https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_3&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=HG745pqKDMrOuvEGoaOzZ8E5Zcz6AQe7iFqbW3KHBvU&s=16hS14fH5Dg8j-XMAdSPQuHiuTKymyP6Ox-GffCMcgE&e=>
>> 
>> — Bruno

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 12 Feb 2020 10:35:49 +0000

Responses inline

De : Wojciech Kozlowski <[email-masked]>
Envoyé : mardi 11 février 2020 17:02
À : [email-masked]; Gelard Patrick <[email-masked]>
Objet : Re: GitHub PR Patch 1

Responses inline

Hi Wojtek

Bests regard

Patrick

-----Message d'origine-----
De : Qirg <[email-masked]<mailto:[email-masked]>> De la part de Wojciech Kozlowski
Envoyé : mardi 4 février 2020 01:03
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Qirg] GitHub PR Patch 1

Hi Patrick,

[PG]

My request is linking to the answer of Rodney :
De : Rodney Van Meter <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 15 mars 2019 13:24
À : Gelard Patrick <[email-masked]<mailto:[email-masked]>>
Cc : Rodney Van Meter <[email-masked]<mailto:[email-masked]>>; Wojciech Kozlowski <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : Re: [Qirg] agenda

—Rod

[PG]

-          error correction

[WK] This is getting too close to physical hardware for this draft in my opinion. Obviously, physical realisation aspects are important, but I would remain wary about how much of that is necessary in this document. Unless other people feel strongly about this, I'm not sure this should be included.
[PG-2] It is no more close to physical hardware than entangled pair source. This concerns the heterogeneity of the communication quantum plan (i.e The counterpart of the data plane of classical networks )  that will make up the quantum internet.  The different form of heterogeneity which in my opinion is not emphasized enough in the document.  The quantum internet will be based on the interconnection of heterogeneous networks.  The heterogeneity will concern different technical facets (support of communication : fiber/free space optics/… , Encoding flying qubit for entanglement  often relies on polarization, energy-time, or time-bin coding,  Harnessing different degrees of freedom to encoding quantum information to form a qudit or a qmode, ….).

In addition it should be noted that the most appropriate carrier and associated encoding observable depend on the specific task you want to do. Photons have been proved suitable to transmit quantum information, and atoms or ions to store and process it. Quantum networks, will contain elementary quantum processors and memories, connected by communication channels, and thus will require quantum interfaces capable of transferring qubit states from one type of carrier to another.

systems

[WK] I'm still not sure why use the quantum channel to carry classical data. Installing a separate classical channel would be much cheaper and more efficient. If security was a concern, why not just encrypt/authenticate? And I disagree, classical control traffic will not be negligible. Every generated pair will need some amount of metadata sent back and forth to keep track of it and its swaps.
[PG] The research on High‐Dimensional Quantum Communication could also be benefic to increased classical information capacity. For example NEC plans to use wireless Orbital Angular Momentum (OAM) for the fronthaul of 5G cellular networks : https://www.nec.com/en/press/201812/global_20181219_02.html  This is relevant, it will happen in any way.

Note that If the cost of a quantum infrastructure will not decrease then, for QKD, this will rather encourage post-quantum solutions to replace the algorithm Diffie-Hellman for  hybrid systems incorporating asymmetric and symmetric algorithms (Key exchange and digital signatures are performed with  post-quantum algorithms and encryption of dat is done using symmetric cipher (e.g block ciphers or stream ciphers).

Cheers,

Wojtek

Qirg mailing list

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 12 Feb 2020 10:40:41 +0000

Correction of an error in red

De : Qirg <[email-masked]> De la part de Gelard Patrick
Envoyé : mercredi 12 février 2020 11:36
À : Wojciech Kozlowski <[email-masked]>; [email-masked]
Objet : Re: [Qirg] GitHub PR Patch 1

Responses inline

De : Wojciech Kozlowski <[email-masked]<mailto:[email-masked]>>
Envoyé : mardi 11 février 2020 17:02
À : [email-masked]<mailto:[email-masked]>; Gelard Patrick <[email-masked]<mailto:[email-masked]>>
Objet : Re: GitHub PR Patch 1

Responses inline

Hi Wojtek

Bests regard

Patrick

-----Message d'origine-----
De : Qirg <[email-masked]<mailto:[email-masked]>> De la part de Wojciech Kozlowski
Envoyé : mardi 4 février 2020 01:03
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [Qirg] GitHub PR Patch 1

Hi Patrick,

[PG]

—Rod

[PG]

-          error correction

systems

[WK] I'm still not sure why use the quantum channel to carry classical data. Installing a separate classical channel would be much cheaper and more efficient. If security was a concern, why not just encrypt/authenticate? And I disagree, classical control traffic will not be negligible. Every generated pair will need some amount of metadata sent back and forth to keep track of it and its swaps.
[PG] The research on High‐Dimensional Quantum Communication could also be benefic to increased classical information capacity. For example NEC plans to use wireless Orbital Angular Momentum (OAM) for the fronthaul of 5G cellular networks : https://www.nec.com/en/press/201812/global_20181219_02.html  If it proves relevant, it will be done anyway.

Cheers,

Wojtek

Qirg mailing list

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 13 Feb 2020 11:01:02 +0000

Hi Bruno,

Thank you for this clear and interesting presentation which, among other things, highlights the notion of virtual circuit<https://en.wikipedia.org/wiki/Virtual_circuit> to apply it to quantum networks.

Now, to complete the remarks of Wojtek

-          is this notion generic enough to make it a principle applicable to all quantum network architectures solutions (Autonomous System)   that will constitute the quantum internet ?

-          Shouldn't we extend its definition to take the characteristics of quantum networks ?

o   No label header to identify the quantum virtual circuit.

o   The notion of virtual circuit rather identifies an unordered list of quantum nodes (repeater) participating in the generation of Bell pairs (executes the purification and swapping algorithms) than a path to transfers entangled Qubits.

-          The notion of multipoint to create an entangled graph should also be clarified.

-          If we can “open” a quantum virtual circuit, we must also be able to close the circuit.

if the notion of quantum virtual circuit cannot be raised to the rank of general principle then it may be relevant to write a specific draft to  specify this possible solution.

Best regards
Patrick

De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : mardi 11 février 2020 16:41
À : [email-masked]
Cc : [email-masked]
Objet : Re: [Qirg] Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Hi Bruno,

Thanks,
Wojtek

— Bruno

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 13 Feb 2020 10:26:55 -0600

Hi Galard,

Responses inline >>> below.

— Bruno

> On Feb 13, 2020, at 5:01 AM, Gelard Patrick <[email-masked]> wrote:
> 
> Hi Bruno,
>  
> Thank you for this clear and interesting presentation which, among other things, highlights the notion of virtual circuit <https://en.wikipedia.org/wiki/Virtual_circuit> to apply it to quantum networks.  
>  

>>> Yes, I believe so. The core of the discussion is whether we should use a connection-oriented approach (similar to MPLS) or a connection-less approach (similar to IP) for quantum networks.  Both are very general concepts, general enough to cover any type of network, including quantum networks.

>>> I am making an argument that a connection-oriented approach makes more sense for quantum networks. My motivation is that creating end-to-end Bell Pairs at a given rate between two remote end-points is a very stateful distributed computation that requires a lot of a-priori coordination. Quantum networks are *not* in the business of stateless hop-by-hop forwarding of packets. Although I conceded in my response to Woj that it is far too early to preclude a connection-less approach.

>>> For the short term, we will have our hands full with intra-domain routing for quantum networks. That said, regardless of whether we choose a connection-oriented approach or a connection-less approach, we will have to look ahead to inter-domain quantum routing (where we have multiple autonomous systems) at some point in time. So, at some point we will need inter-domain quantum routing protocols, and in the case of a connection-oriented approach, inter-domain quantum virtual circuit signaling protocols.

>>> Absolutely!

>>> Indeed, this is one of the most important differences between classical MPLS networks and quantum networks. You cannot push an MPLS label onto a qubit (or any other header for that matter, not even a destination address).

>>> I just realized that I forget to mention the analogy with Generalized MPLS (GMPLS).  In GMPLS we also have a control-plane network that controls a data-plane network that is missing the ability to carry explicit MPLS labels (e.g. wavelengths in a DWDM network or time slots in a SONET/SDH network). I will add a short sentence to this effect in the updated pull request.

>>> In GMPLS networks, we use some implicit “label” (e.g. the DWDM wavelength or the TDM time slot) in lieu of explicit MPLS labels. Similarly, in quantum networks we will need to use some implicit qubit information (e.g. the time slot or the wavelength or the polarization or the which-path information) in lieu of explicit headers.

>>> Again agreed. My analogy with MPLS is intended to be rather loose (i.e. not literal). I did not intend to imply that quantum networks will literally do an ordered sequence of MPLS label swaps.  I only intended to imply that some amount of a-priori signaling is needed to install the generalized “rules” (as Rodney calls them) that “control” the distributed computation (the state machines for local Bell pair generations, the swaps, the distillations, etc.) and potentially also to allocate resources.

>>> Good point. There is a (very loosely) analogous concept of point-to-multi-point LSPs in MPLS (they are used for multicast)

>>> Agreed, both establishment and tear-down are needed (and potentially pre-emption as well).

> At the same time it's also worth pointing out that circuits aren't the only way to go around quantum networking with entangled pairs. For example, in https://www.nature.com/articles/s41534-019-0139-x <https://www.nature.com/articles/s41534-019-0139-x>the authors do not consider individual circuits, but instead with a correct local strategy, the two nodes will end up with an entangled pair. Of course, this may well have other complications (e.g. how to install these rules if not using circuits), but my point is only that there may well be a variety of approaches so it's worth avoiding language implying that this is the one and only correct way of doing things. If memory lifetimes were good enough and performance was not a concern, hop-by-hop would be entirely possible so it's worth avoiding language implying this is a MUST rather than a very plausible candidate.
>

---

From: Gelard Patrick <[email-masked]>
Date: Mon, 17 Feb 2020 09:01:36 +0000

Hi Bruno,

Responses inline

Best Regards
Patrick

De : Bruno Rijsman <[email-masked]>
Envoyé : jeudi 13 février 2020 17:27
À : Gelard Patrick <[email-masked]>
Cc : [email-masked]; Wojciech Kozlowski <[email-masked]>
Objet : Re: Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Hi Galard,

— Bruno

On Feb 13, 2020, at 5:01 AM, Gelard Patrick <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bruno,

>>> In GMPLS networks, we use some implicit “label” (e.g. the DWDM wavelength or the TDM time slot) in lieu of explicit MPLS labels. Similarly, in quantum networks we will need to use some implicit q…
[PG] Be careful, the degree of indistinguishability of photons<https://www.nature.com/articles/ncomms15506> ( same spatial mode, same temporal mode, same frequency and polarization ) is a crucial parameter for entanglement.

Best regards
Patrick

De : Qirg <[email-masked]<mailto:[email-masked]>> De la part de Wojciech Kozlowski
Envoyé : mardi 11 février 2020 16:41
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Qirg] Pull request for new section "Comparison with multi-protocol label switched (MPLS) networks."

Hi Bruno,

At the same time it's also worth pointing out that circuits aren't the only way to go around quantum networking with entangled pairs. For example, in https://www.nature.com/articles/s41534-019-0139-xthe authors do not consider individual circuits, but instead with a correct local strategy, the two nodes will end up with an entangled pair. Of course, this may well have other complications (e.g. how to install these rules if not using circuits), but my point is only that there may well be a variety of approaches so it's worth avoiding language implying that this is the one and only correct way of doing things. If memory lifetimes were good enough and performance was not a concern, hop-by-hop would be entirely possible so it's worth avoiding language implying this is a MUST rather than a very plausible candidate.

Thanks,
Wojtek

— Bruno

---

From: Bruno Rijsman <[email-masked]>
Date: Mon, 17 Feb 2020 15:37:52 -0600

Hi Woj,

I have updated the GitHub pull request for the new section to compare quantum networks to classical networks (https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3 <https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3>)

I tried to make it more compact (about half the size, 2 pages now) and more consistent with the style of the rest of the draft (less wooly language). 

I also included some points that came up in the thread with Patrick Gelard (e.g. the GMPLS reference).

Have a look at it, don’t be shy to let me know if more polishing is still needed.

— Bruno

PS: There is a merge conflict on the .txt file. Just merge only the .xml file and re-generate the .txt file.

---

From: Wojciech Kozlowski <[email-masked]>
Date: Wed, 26 Feb 2020 12:11:29 +0000

Thanks for the update - looks much better and more concise. Will merge it at some point next week. I might move things around and rephrase things, but if I do, I'll send an update to the mailing list before doing the final merge to ensure I didn't change the intended meaning.

Wojtek

On Mon, 2020-02-17 at 15:37 -0600, Bruno Rijsman wrote:
Hi Woj,

I have updated the GitHub pull request for the new section to compare quantum networks to classical networks (https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/3<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_3&d=DwMFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=ierDab_Kye53z6jREXO55QYyjvpd-Oejh_81TGUPpk8&s=D8pJduvZiHxVrglMYoNjrO1tUcRD3kc9s_YfBTa5W0s&e=>)

— Bruno