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

Rodney Van Meter <rdv@sfc.wide.ad.jp> Tue, 19 May 2020 06:09 UTC

Return-Path: <rdv@sfc.wide.ad.jp>
X-Original-To: qirg@ietfa.amsl.com
Delivered-To: qirg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B945A3A1222 for <qirg@ietfa.amsl.com>; Mon, 18 May 2020 23:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sfc.wide.ad.jp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjv5EJEF14eM for <qirg@ietfa.amsl.com>; Mon, 18 May 2020 23:09:50 -0700 (PDT)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [203.178.142.133]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C213A121C for <qirg@irtf.org>; Mon, 18 May 2020 23:09:49 -0700 (PDT)
Received: from vanmetedneysmbp.fletsphone (69.10.30.125.dy.iij4u.or.jp [125.30.10.69]) (Authenticated sender: rdv) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5F54BA3C1; Tue, 19 May 2020 15:09:48 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1589868588; bh=zCEOO7pbyoYhb1EJ6vov4I0xwrk6FDv/oFXWmZoR9N0=; h=From:Subject:Date:Cc:To:From; b=TSF8b7Hqxc/C35vV+MetkN15KK0sFl8dMGjQqlAWLO3jFDElaKuI4irTqEV5MvXfi 6TsnVFHX5gnFQmA6Hdz0Z9OLma31GhqHFX46lHatRlp5F++PZ5NdddLk6nMKyOyGIP C3FgRPyfpBtGae/10nQ5yoTQSlJY9ZqHOIDE9kHblIAZP5+Cd5W6wMZHKNRtJseFOV twfOv3o1wFLKz81dVQ6hBBmiJTfx1A8McB5ph17iRcH8nJlxHv1I7+GIzmxOIdEV2i rOAAj4I/dbKvuIMr3xLD/fefX936ISEpBJxhEuD+mXOln4jPA+yq3GwSaRoR70Fnta J94ipL2kGQzDA==
From: Rodney Van Meter <rdv@sfc.wide.ad.jp>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <553672B6-E4C5-4537-8916-E2B1F200A362@sfc.wide.ad.jp>
Date: Tue, 19 May 2020 15:09:47 +0900
Cc: Rodney Van Meter <rdv@sfc.wide.ad.jp>
To: qirg@irtf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/xl8rJ0IBIsAQoMHxVcLBO9nVzrQ>
Subject: [Qirg] arch I-D: pull request & comments
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Quantum Internet \(proposed\) RG" <qirg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/qirg>, <mailto:qirg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/qirg/>
List-Post: <mailto:qirg@irtf.org>
List-Help: <mailto:qirg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/qirg>, <mailto:qirg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 06:09:54 -0000

<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
rdv@sfc.wide.ad.jp