Subject: [Qirg] arch I-D: pull request & comments

From: Rodney Van Meter <[email-masked]>
Date: Tue, 19 May 2020 15:09:47 +0900

<chair hat off>
<individual contributor hat on>

Wojtek et al.,

A pull request for the architecture I-D awaits you at
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/7
(I didn't generate the .txt from it, I figure it's generally better
for such generated files that are stored in git to be managed at one
node.)

I went through the I-D and made a number of small changes; I doubt
anything will need discussion but please check.  Almost all edits are
for clarity, spelling or grammar.  I modified the Muralidharan
reference to the right "generations" paper, and I added Sutor as a
reference for beginners.  (I really do think that's an excellent
beginner's book on quantum computing, with the dead-minimum
assumptions of background in CS, math and physics, as opposed to Mike
& Ike, which can be a steep climb.)

A number of things occured to me while reading, some of which we've
probably covered before:

1. My memory fails me -- in the section on network boundaries, we
previously had a discussion of how much to cover the different types
of logical networks (1G, 2G, 3G), didn't we?  What did we decide?
Personally, I think it's _critical_ in a document like this, intended
to be long-lived and set the direction for the network architecture,
to acknowledge that not only are there physical differences and
administrative boundaries, but there are important distinctions in how
errors will be managed, which affects the content and semantics of
messages that must cross those boundaries, as well -- both for
connection setup and real-time operation.

2. Assessment of fidelity is a statistical thing, requiring constant
monitoring and the sacrifice of generated Bell pairs for tomography or
other methods.  Should we clarify this?  At the moment, fidelity is
mentioned but where it comes from is not.

3. Mentions QKD as depending on Bell pairs, which is not exactly true for
BB84.  Also, E91 and BBM92 are probably worth citing as better
instances of entanglement-based QKD.

4. This (and some of the surrounding paragraphs) needs work:

           It turns out that as long as the underlying implementation
           corresponds to (or sufficiently approximates) theoretical models of
           quantum cryptography, quantum cryptographic protocols do not need
           the network to provide any guarantees about the authenticity,
           confidentiality, or integrity of the transmitted qubits or the
           generated entanglement. Instead, applications, such as QKD,
           establish such guarantees using the classical network in conjunction
           with he quantum one. This is much easier than demanding that the
           network deliver secure entanglement in the first place.
           <vspace blankLines="1" />

This could cite Satoh on quantum network security; AFAIK, our work on
the security of repeater network operation remains the world's only
work on the topic.  One or both of
https://arxiv.org/abs/1701.04587
https://arxiv.org/abs/2005.04617

5. We have discussed Bell pairs as the primary service provided by the
network, but it may be worth mentioning that multi-party states are
useful, and may be generated either by applications operating
end-to-end or by the network itself as a service.  There are a number
of uses of multi-party states documented in the literature, but only
Clement, Damian and Frederic Grosshans on how to create them, I
think.
https://link.aps.org/doi/10.1103/PhysRevA.100.052333

6. "shortest path" is undefined here.  Again, work of ours is
relevant: https://arxiv.org/abs/1206.5655

7. In discussion of rule-based operation, again, work of ours is
relevant: https://arxiv.org/abs/1904.08605
(I _know_ it sounds like I'm citing "cite me" a lot, but this _is_ the
field we have been working for over a decade to establish, and we've
covered a lot of ground in that time, and my students and postdocs
deserve some recognition for the work they have done that is, or
should be, influencing these documents and designs.)

8. The use of "control plane" and "data plane" here might differ a bit
from standard networking use.  "Control plane" usual refers to routing
and management traffic, path setup for MPLS, etc. but here it refers
to soft real-time messages that are part of the entangled state
creation process, essentially the equivalent of packet headers and
SYNs and ACKs in TCP/IP.  I'd argue that's closer to data plane than
control plane.

I don't think the document is close to ready for last call yet, but it
has made a lot of progress.  I think we can put serious discussion of
the document onto the agenda for July, with the hopes of publishing
soon after.

—Rod

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
[email-masked]

---

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 19 May 2020 13:28:46 +0000

Responses in-line. I am going to put items that require action from me on top
of the TODO items from your 6 March e-mail to handle after updating section 6
which will hopefully be next month.

More details in-line. No comment means I fully agree with your point and have
nothing to add.

> A pull request for the architecture I-D awaits you at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_7&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=uAPhFtt4Jag1SImLOB-xdnvE4wqgUKfhwulYKnRNffI&e=
> & Ike, which can be a steep climb.)

Thanks! Pretty straightforward. Merged.

> connection setup and real-time operation.

Shota has submitted a PR about generations which I've been currently
withholding until it becomes clearer what is expected from this section and we
had a bit of a discussion on the mailing list. In general, I agree. We should
add something about generations and what defines them to the draft. The current
state of this PR is here: 
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6/files

I have not reviewed that PR yet, but I have already mentioned what I would like
to see in this section (see 
https://mailarchive.ietf.org/arch/msg/qirg/b87SUszyuj5sXI1twDiEuX3F9oY/)

Feel free to add your thoughts either in the PR or on the mailing list.

> mentioned but where it comes from is not.

I think clarifying the difficulties around fidelity would be valuable. Will add
something once I sort out section 6.

> work on the topic.  One or both of
https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1701.04587&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=LVu3oWfp0WCPG46t-AAs2zgGy6PC0bBYt8ACKAlYI_U&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_2005.04617&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=8Fs-dOf5B_umAIwmL81kWTqHlgTVOc7-MUva1m7T2LA&e=
> Clement, Damian and Frederic Grosshans on how to create them, I
https://urldefense.proofpoint.com/v2/url?u=https-3A__link.aps.org_doi_10.1103_PhysRevA.100.052333&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=P3uNxsyWPSV-AyvZllHG0VcKmtDmxpLzOuLqLrKrs-8&e=
> relevant: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1206.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=5CZHrVvCzrqIE5WlMt53hX0WAA0H7gTARE-g4zWoR3Y&e=
>  
> 
> relevant: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1904.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=RZE6ErezqKuvt7bPhzr6A7xV3ilHq0krX0EcYpQyadA&e=
>  

This is a good point and I've been pondering many times about where do the soft
real-time messages belong to. Lately I've been lumping them into the data plane
which sounds in line with your thinking. Will look into clarifying this.

> the document onto the agenda for July, with the hopes of publishing

Yes agreed. To me, the following items need work:

1. Section 6 needs an update (currently in the process of setting up online
meeting - email coming soon)
2. Add a section on generations (work can start with Shota's PR)
3. Implement your feedback from 6 March e-mail and this e-mail
4. Final editing pass

To me, only items 1 and 2 are what I'd call "major" items which need careful
thought. For item 3, in general I will just implement your feedback. I haven't
done so yet since it covers the entire draft top to bottom so I wanted to have
the core text finalised first in case some of that feedback can be incorporated
with these changes.

> _______________________________________________
> Qirg mailing list
> [email-masked]
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaKT0byF8SKqSzWE&s=wxv8uRZVSeFyskfYTA2SKnUDIBhmcXehDoaOqFQKLh0&e=

---

From: Akbar Rahman <[email-masked]>
Date: Tue, 19 May 2020 14:57:14 +0000

Hi Rodney/Wojtek,

I have one question:

- In section 5.3.2 and section 8 of the current draft-irtf-qirg-principles-03 it states that "no user data enters a quantum network" or a similar phrase.   I believe this statement also requires clarification in terms of the data plane vs control plane comment number (8) in your email chain below.  Specifically, data plane in telecom usually refers to carrying user data as well as protocol overhead such as ACKs and SYNs.  So it seems confusing to state that "no user data enters a quantum network" and then talk about a data plane.  I recommend removing the references to "no user data enters a quantum network" from the draft or else clarifying the basic definition of what you mean by quantum networks.

Best Regards,

Akbar

-----Original Message-----
From: Qirg <[email-masked]> On Behalf Of Wojciech Kozlowski
Sent: Tuesday, May 19, 2020 9:29 AM
To: [email-masked]
Subject: Re: [Qirg] arch I-D: pull request & comments

Responses in-line. I am going to put items that require action from me on top of the TODO items from your 6 March e-mail to handle after updating section 6 which will hopefully be next month.

More details in-line. No comment means I fully agree with your point and have nothing to add.

> connection setup and real-time operation.

Shota has submitted a PR about generations which I've been currently withholding until it becomes clearer what is expected from this section and we had a bit of a discussion on the mailing list. In general, I agree. We should add something about generations and what defines them to the draft. The current state of this PR is here:
https://github.com/Wojtek242/draft-irtf-qirg-principles/pull/6/files

I have not reviewed that PR yet, but I have already mentioned what I would like to see in this section (see
https://mailarchive.ietf.org/arch/msg/qirg/b87SUszyuj5sXI1twDiEuX3F9oY/)

> mentioned but where it comes from is not.

I think clarifying the difficulties around fidelity would be valuable. Will add something once I sort out section 6.

> 3. Mentions QKD as depending on Bell pairs, which is not exactly true
> for BB84.  Also, E91 and BBM92 are probably worth citing as better
> Clement, Damian and Frederic Grosshans on how to create them, I think.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_120
> 6.5655&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8
> UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFaK
> T0byF8SKqSzWE&s=5CZHrVvCzrqIE5WlMt53hX0WAA0H7gTARE-g4zWoR3Y&e=
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_190
> 4.08605&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k
> 8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=DAxWywV9qbtvoGKGw6BAJ7W2sUeFa
> KT0byF8SKqSzWE&s=RZE6ErezqKuvt7bPhzr6A7xV3ilHq0krX0EcYpQyadA&e=
>

This is a good point and I've been pondering many times about where do the soft real-time messages belong to. Lately I've been lumping them into the data plane which sounds in line with your thinking. Will look into clarifying this.

1. Section 6 needs an update (currently in the process of setting up online meeting - email coming soon) 2. Add a section on generations (work can start with Shota's PR) 3. Implement your feedback from 6 March e-mail and this e-mail 4. Final editing pass

To me, only items 1 and 2 are what I'd call "major" items which need careful thought. For item 3, in general I will just implement your feedback. I haven't done so yet since it covers the entire draft top to bottom so I wanted to have the core text finalised first in case some of that feedback can be incorporated with these changes.

> —Rod
>
> Rodney Van Meter
> Professor, Faculty of Environment and Information Studies Keio
> University, Japan [email-masked]
>
>
>
_______________________________________________
Qirg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/qirg
[Banner]

[Banner]<https://www.interdigital.com/white_papers/streaming-media-report->

ABI - Streaming Media Report<https://www.interdigital.com/white_papers/streaming-media-report->
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: Wojciech Kozlowski <[email-masked]>
Date: Wed, 20 May 2020 15:22:52 +0000

Good point. I think it's important to keep the sentence that "no user data
enters a quantum network", but I agree that in that case it might be worth
clarifying control/data plane separation. 

As I see it, all quantum operations are data plane operations. Even though they
do not carry user data, the resulting entangled pairs are still delivered to
the user. And, as Rod mentioned in his comment, any classical messages that are
hard/soft real-time should also be included in the data plane.

I will keep this in mind when I get around to sorting this set of comments.

On Tue, 2020-05-19 at 14:57 +0000, Akbar Rahman wrote:
> Hi Rodney/Wojtek,
> 
> 
> I have one question:
> 
> - In section 5.3.2 and section 8 of the current draft-irtf-qirg-principles-03 
> it states that "no user data enters a quantum network" or a similar
> phrase.   I believe this statement also requires clarification in terms of
> the data plane vs control plane comment number (8) in your email chain
> below.  Specifically, data plane in telecom usually refers to carrying user
> data as well as protocol overhead such as ACKs and SYNs.  So it seems
> confusing to state that "no user data enters a quantum network" and then talk
> about a data plane.  I recommend removing the references to "no user data
> enters a quantum network" from the draft or else clarifying the basic
> definition of what you mean by quantum networks.
> 
> 
> 
> Best Regards,
> 
> 
> Akbar
> 
> 
> withholding until it becomes clearer what is expected from this section and
> we had a bit of a discussion on the mailing list. In general, I agree. We
> should add something about generations and what defines them to the draft.
> The current state of this PR is here:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Wojtek242_draft-2Dirtf-2Dqirg-2Dprinciples_pull_6_files&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=2ZhqspGd4LNOQ1DWMOHiwEoXsaEliy8aKWoDQa59SkM&s=HHpLh3ebUvbMgoYmXtp8_XRCn9kRH8GZpEP2yu7ZCMw&e=
> like to see in this section (see
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_qirg_b87SUszyuj5sXI1twDiEuX3F9oY_&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=2ZhqspGd4LNOQ1DWMOHiwEoXsaEliy8aKWoDQa59SkM&s=zRgbCSHbA_icrS-O_Q1hYJj2L_25B2bD_rQ1GQh5W-c&e=
>  )
> This is a good point and I've been pondering many times about where do the
> soft real-time messages belong to. Lately I've been lumping them into the
> data plane which sounds in line with your thinking. Will look into clarifying
> this.
> 
> > 
> meeting - email coming soon) 2. Add a section on generations (work can start
> with Shota's PR) 3. Implement your feedback from 6 March e-mail and this e-
> mail 4. Final editing pass
> 
> thought. For item 3, in general I will just implement your feedback. I
> haven't done so yet since it covers the entire draft top to bottom so I
> wanted to have the core text finalised first in case some of that feedback
> can be incorporated with these changes.
> 
> > —Rod
> > 
> > Rodney Van Meter
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.irtf.org_mailman_listinfo_qirg&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=2ZhqspGd4LNOQ1DWMOHiwEoXsaEliy8aKWoDQa59SkM&s=I7F8qx1jqXz4lvIp1CuXJ7SH9-ZF_b8QHocUx90_vQQ&e=
>  
> [Banner]
> 
> [Banner]<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.interdigital.com_white-5Fpapers_streaming-2Dmedia-2Dreport-2D&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=2ZhqspGd4LNOQ1DWMOHiwEoXsaEliy8aKWoDQa59SkM&s=owNYL0ebSRnLecbTiTx6_AtQS2ZBKYGd1Vc8A-B5yWg&e=
>  >
> 
> ABI - Streaming Media Report<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.interdigital.com_white-5Fpapers_streaming-2Dmedia-2Dreport-2D&d=DwIGaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=xRe3k8UnFVGCjuC7RWUARpslGfYlRaP7D3dVZXHUEVc&m=2ZhqspGd4LNOQ1DWMOHiwEoXsaEliy8aKWoDQa59SkM&s=owNYL0ebSRnLecbTiTx6_AtQS2ZBKYGd1Vc8A-B5yWg&e=
>  >
> This e-mail is intended only for the use of the individual or entity to which
> it is addressed, and may contain information that is privileged, confidential
> and/or otherwise protected from disclosure to anyone other than its intended
> recipient. Unintended transmission shall not constitute waiver of any
> privilege or confidentiality obligation. If you received this communication
> in error, please do not review, copy or distribute it, notify me immediately
> by email, and delete the original message and any attachments. Unless
> expressly stated in this e-mail, nothing in this message or any attachment
> should be construed as a digital or electronic signature.