Re: [Qirg] updated I-D (-01) on connection setup

Gelard Patrick <Patrick.Gelard@cnes.fr> Thu, 12 September 2019 08:21 UTC

Return-Path: <Patrick.Gelard@cnes.fr>
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 99E9D120864 for <qirg@ietfa.amsl.com>; Thu, 12 Sep 2019 01:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 SMEZEFoWElpO for <qirg@ietfa.amsl.com>; Thu, 12 Sep 2019 01:21:43 -0700 (PDT)
Received: from mx1.cnes.fr (mx1.cnes.fr [194.199.174.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D156412026E for <qirg@irtf.org>; Thu, 12 Sep 2019 01:21:38 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.64,495,1559520000"; d="scan'208,217"; a="10356307"
X-IPAS-Result: A2EIAQDK/3ld/wYBeApmGgEBAQEBAgEBAQEHAgEBAQGBZ4EWgQJZFIEFKgqEF5EMfpIWhh6BZwkBAQEBAQEBAQEtBwECAQGEPwIXgkMjOBMCDAEBAQQBAQEBAQYCAQECAmmEa0MMhUwCAQMjCkUHEAIBBQMNBRACARoDAgICMBQDDgIEAQ0FCIMbgR1tD6pogTIahBwBE0GFMAaBNIFjjCyBEUaCFzU+gmECAgEBgSEJARIBCRg0glUygiYEjFCCbIUhgjOGZY1kbgeBNm6CLIRVjhF0gUCLTgOLBYo+g0GBOIZMknsiKj1xMxonTIJsgUuBAQIXiCg7hT9DMIEhCIw6gSIBgSIBAQ
X-URL-LookUp-ScanningError: 1
From: Gelard Patrick <Patrick.Gelard@cnes.fr>
To: Rodney Van Meter <rdv=40sfc.wide.ad.jp@dmarc.ietf.org>, "qirg@irtf.org" <qirg@irtf.org>
CC: Rodney Van Meter <rdv@sfc.wide.ad.jp>, Takaaki Matsuo <kaaki@sfc.wide.ad.jp>
Thread-Topic: [Qirg] updated I-D (-01) on connection setup
Thread-Index: AQHVaSTI7xt3KvyFDk24GpafwlWkW6cnpZ0g
Date: Thu, 12 Sep 2019 08:21:21 +0000
Message-ID: <F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA0538C3F@TW-MBX-P04.cnesnet.ad.cnes.fr>
References: <652C4922-7839-4700-8E64-3F57804671E2@sfc.wide.ad.jp>
In-Reply-To: <652C4922-7839-4700-8E64-3F57804671E2@sfc.wide.ad.jp>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-24906.005
x-tm-as-result: No--32.788200-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_F1E8EFF81FCF1B46AA7CCA3CC4D5E18CA0538C3FTWMBXP04cnesnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/qP7hu3X5m7ruspmpTCNaHJL83WY>
Subject: Re: [Qirg] updated I-D (-01) on connection setup
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: Thu, 12 Sep 2019 08:21:45 -0000

Hi,

« Use of the quantum network is driven by applications running at two (or more) classical nodes.  Overall behavior is similar to client-server computing.  The connection is initiated from a node similar to client and responded to by a node similar to a server. »

The common need of quantum application like distributing computing,  Distributed quantum sensing (e.g Entanglement enhanced quantum sensing<https://www.researchgate.net/publication/47821472_Entanglement_enhanced_quantum_sensing> ; Distributed quantum sensing in a continuous variable entangled network<https://arxiv.org/abs/1905.09408> ; …), QKD base entanglement, … are distributed entanglement (Bell pair resource for point-to-point relationship) who is the fundamental resource for quantum-enhanced applications.

Thus the quantum-enhanced applications have to request, via classical network,  this entanglement resource  which is generated by entangled quantum light sources (e.g spontaneous parametric down conversion (SPDC)) that must be interconnect to the quantum network.

The proposed communication establishment model is more a request-reply model like RSVP for example  than a publish-subscribe model like MQTT for exemple. In a publish-subscribe model, quantum-enhanced applications will be the subscriber to entanglement resource  and the publishers will be the source of entanglement photon pair.

For the control plan of a quantum network, is a publication subscription model more appropriate than a publication subscription model to meet the needs of quantum applications which is to request/subscribe to entanglement resource    ?

/Patrick


De : Qirg <qirg-bounces@irtf.org> De la part de Rodney Van Meter
Envoyé : jeudi 12 septembre 2019 06:44
À : qirg@irtf.org
Cc : Rodney Van Meter <rdv@sfc.wide.ad.jp>; Takaaki Matsuo <kaaki@sfc.wide.ad.jp>
Objet : [Qirg] updated I-D (-01) on connection setup

If you’re on the drafts list, you probably saw about 19 hours ago that I posted an update to our draft on connection setup in quantum networks.
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/
This is a minor update.

I went back and reread the email messages from when we posted the original in March. I think we covered most of the concerns here on the list, without needing much in the way of changes to the draft. But I clarified a few definitions in the new draft.

I think there are four things that I’d still like to do with this.  One is just writing:

1. Wojciech asked for an example of the process.  Agreed.

I think that’s an excellent idea, and would liked to have had it in the -01 draft, but didn’t get it done before -00 expired, so I went ahead and did the minor update.

There are three technical things that need to be done:

2. Align the terminology with Wojciech’s architecture document (*or vice versa*)
3. Our own thinking on where in the architecture *resource reservation* belongs is evolving; our simulator isn’t quite up to needing that yet, so we don’t have real experience with it yet, but this is an important discussion.
4. Wojciech asked if segment routing (SR) could figure into this, and I have only a dilettante’s understanding of SR, so I can’t say but would like to investigate.

Maybe we can revive the discussion of these here on the list, so that we can put out an -02 before Singapore?

—Rod

Rodney Van Meter
Professor, Faculty of Environment and Information Studies
Keio University, Japan
rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>