Re: [Qirg] Survey paper about the Quantum Internet Protocol Stack

Joseph D Touch <joseph.d.touch@aero.org> Wed, 08 June 2022 16:36 UTC

Return-Path: <prvs=1515e6542=joseph.d.touch@aero.org>
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 D48A6C157B55 for <qirg@ietfa.amsl.com>; Wed, 8 Jun 2022 09:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, INVESTMENT_ADVICE=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aero.org header.b=BfuYeCto; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=gEM2wfLs
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG5h4X22faEO for <qirg@ietfa.amsl.com>; Wed, 8 Jun 2022 09:36:51 -0700 (PDT)
Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (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 7BDBBC157B41 for <qirg@irtf.org>; Wed, 8 Jun 2022 09:36:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1654706211; x=1686242211; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eSLWoAzFjNqI1jvzph2lSn+R0ALZtUBL4d3rH81qzKM=; b=BfuYeCtoupZKC28pj2N4iAH70EfPl8ulg2W09UMvtpnUZy0WATmF8sir 3uhrLjugn+jP04b/UwMTLrVJfnoCSXJT0MlyTNLk7XTChns71s650Yuv4 WfCGbGtMe/lLCXgxAQtlCpySGBUD2faNp8w9BiU3x34WElShKwZmNHWY6 s=;
x-SBRS: 3.5
x-SenderGroup: Inbound_Office365
IronPort-Data: A9a23:laC5yqhZ07lUNrb5KbmimAFEX161ChcKZh0ujC45NGQN5FlHY01je htvUWGAa/yKZTf3cot3aYrg/U0DvceAyt9lGQVp/i0zQn8W8JqUDtmndUqhZCn6wu8v7a5EA 2TyTvGacajYm1eF/k/F3p7J8yUkjclkYZKlULWbYEidfSc9FGF5z0sLd9cR2uaEu/Dha++2k Y608pS31GONgWYuaDpKs/Lb8nuDgdyp0N8mlg1nDRx0lA+G/5UlJMp3yXaZchMU6qENdgKLb 76rIIORpws1zD90Yj+RqYsXR2VRKlLkFVXX0CIOA8BOtTAZzsA6+v5T2PPx8i67gR3R9zx64 I0lWZBd1W7Fl0AD8QgQe0AwLs1wAUFJ0ID6AUeRiMHP81DtNCSv26pWFX4WPZJNr46bAUkWn RAZAB8mRUjZwsiSmPe8QOQqgdk/Js72Oo9Zomtn0TzSEfchR9bEXrnO4thbmjw3g6iiH96HP 5ZfNWUpMkiGOkUfUrsUIMtWcOOAhH7kfiVY7l7Tua0q6Gj7xQFr1/7qKtW9ltmiFJsJwRrHz o7A12PLJxQrHvyD9RqUyWiI36zIninUB41HQdVU8dYx2QbImQT/EiY+UFKhqvS9jkn4UNtbJ kIa+wIzq6k0/QqqUrHVXRCju3+Pt1gdX95RGus9wByLy6zdpQeFbkANSjNRYdoqrsJwXTE2z FKSlM7BCjlmsbnTQnWYnp+NrCm9ESkPMWFEYjULJTbp+PHmqYA3yxjLFNloG/bvisWvQGmgh TeXsCI5mrMfy9YR0Lm29kzGhDTqoYXVSgky5UPcWWfNAh5FiJCNWLGI1nbi4Kp8Ma3eERqZ4 0AdpOie87VbZX2SrxClTOIIFbCvwv+KNjzAnFJid6XNERz9pBZPmqgAv1lDyFdV3tUsImC4O hCJ0e9FzNoMYiv3MfMfj5eZUZxC8ET2KTjyuhk4hPJya4BpfQ+O+idpbk34M4vFyhJxz/lX1 Xt2jq+R4ZsyDK1myH+8Q70S2rRznCQmnzqLFdb80git1qeYaDiNU7AZPVCSb+c/qqSZvAHS9 NUZPMyPo/m+bAEcSnaPmWLwBQlVRZTeOXwQg5ALHgJkClY6cFzN89eLndscl3VNxsy5bNvg8 HCnQVN/w1Hin3DBIgjiQik9Ne+xB8gh9y1kY3JE0bOUN54LMdfHAEA3J8tfQFXb3Lc8pRKJZ 6VYIJTZW6wTItg5021MNMCj9uSOiyhHdSrVZnH+P1DTjrZlRgfT/cTjcBen/y4UFi2tvNc/p LvI6+8oactreuiWN+6PMKjH5wrp4xA1wbsuN2OVfIU7UBiyoeBCdnyg5tdqcppkAUiSllOyi VzKaT9G/rOli9Fur7H0aVWs9NrB/x1WRRYBQAE2LN+eaUHnw4ZU6dQeC7vYJW6GCTycFWfLT bw98swQ+cYvxD5i27eQ2Z4ypU7iz7MDf4Nn8zk=
IronPort-HdrOrdr: A9a23:dxRxna2RLp7V8quela5vIwqjBRdyeYIsimQD101hICG9Lfb0qy n+pp4mPEHP4wr5AEtQ4uxpOMG7MBDhHO1OkPMs1NaZLUTbUQ6TQL2KgrGSpAEIdxeeygcZ79 YZT0EcMqy9MbEZt7ed3ODQKb9Jr7e6GeKT9J7jJhxWPGNXgtRbnmNE43GgYyhLrWd9ZaYRJd 653I5qtjCgcXMYYoCQHX8eRdXOoNXNidbPfQMGLwRP0njBsRqYrJrBVzSI1BYXVD1ChZ0493 LergD/7qK/99mm1x7n0XPJ5Zg+oqqh9jIDPr3NtiEmEESvtu+aXvUlZ1S2hkF3nAjg0idvrD CGmWZcAy060QKsQojym2qj5+Co6kdR15epo2Xo/kfLsIj3Qik3BNFGgp8cehzF61A4tNU5y6 5T2XmF3qAnRC8osR6NkOQgbSsa4HZcYEBS49I7njhaS88TebVRpYsQ8AdcF4oBBjvz7MQiHP N1BM/R6f5KeRfCBkqp9VVH0ZipRDA+Dx2GSk8Ntoic1CVXhmlwyw8dyNYElnkN+ZohQ90djt 60eJhAhfVLVIsbfKh9DOAOTY++DXHMWwvFNCaXLU78HK8KNnrRo9r84akz5uutZJsUpaFC0K jpQRddryo/akjuAcqB0NlC9Q3MWny0WXD3xsRX9/FCy8nBrXrQQFi+oXwV4rudSq8kc7zmst 6ISeFrP8M=
X-IronPort-AV: E=McAfee;i="6400,9594,10372"; a="964747"
X-IronPort-AV: E=Sophos;i="5.91,286,1647327600"; d="scan'208,217";a="964747"
Received: from mail-bl2gcc02lp2108.outbound.protection.outlook.com (HELO GCC02-BL0-obe.outbound.protection.outlook.com) ([104.47.64.108]) by email5-west.aero.org with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2022 09:36:49 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ow6+uz//DtHXTcc3mW3C5udWAbZ6GUKT2SyaRPA8TxYTZ4Bi41edDsEFL4SqX3CrHZZT6+BHgxUTPI9NLs4MFlmFL+EMNeDMRyLLNL8pORqLrOVR5lE4P6jZmtfGlVC4PhTYPfUi1YbX+uc0FJAJzl8K7cwiEbllH7ADXwhJYBw1L72/YxDsH0TluCIU/LmNWByV08MY+ofeonhmiFcBnl3aKWF/ZBRS/RW35U9TQpB+IaA9xTxGUaVimSDwaNQyNOuCht2im0VwW54E10n88BKUvvsF8gnJzNqMj/ave0jcxQI/5Mk6P0JNujnEwpQQl8l+dGiv8X/to1lB8pWcrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eSLWoAzFjNqI1jvzph2lSn+R0ALZtUBL4d3rH81qzKM=; b=TG23MW+b48tHd+M6KPJd6nPH1ldekv1aRtrzLM+mLhBwgH2JGEl/flUIEIHYS8jqqBLIG6VA9CVhnvQiP/nHGAF22FfCHHKIOKM3r3SxjKkkuGejlIW69Lni534idGh6mMbtTSNGnGFh92llDzKl6FaQCVTrIDoUqtNX9wHZsBIXJKTZ/+GmmuJ97kDi6GjmUj3M2iyPLqALVFia7sFoOTZJvGLAEigPwxBKQAUN3TMdy23axX6KYGzkPJb6F3I7mT8N8moWISztpGtPqNLOAJpREvd5tREjAq5b8/L8u3jkLgZJVQxxOF6fNjyNF0LTnWi0nQi07Q0HUXZfoNKOYQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aero.org; dmarc=pass action=none header.from=aero.org; dkim=pass header.d=aero.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector2-aerospacecloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eSLWoAzFjNqI1jvzph2lSn+R0ALZtUBL4d3rH81qzKM=; b=gEM2wfLsMzg+Afp+Swi3gAqU3wxGRYW0mMNURTOQFDQW5cq+nLOoe3VvFLhgNZQiKQJ4PMxupMqeU7VTu/OXwPPRMQMF/625tRUtnTzOHhUEI808Xl2+pTAlx2qsECDRuDItbHZwuUmbV7eSIi3plUEQehLKkXJO2rodRQ/A5HQ=
Received: from SJ0PR09MB6542.namprd09.prod.outlook.com (2603:10b6:a03:266::20) by MN2PR09MB4955.namprd09.prod.outlook.com (2603:10b6:208:223::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12; Wed, 8 Jun 2022 16:36:47 +0000
Received: from SJ0PR09MB6542.namprd09.prod.outlook.com ([fe80::a4cd:aa27:8012:26c4]) by SJ0PR09MB6542.namprd09.prod.outlook.com ([fe80::a4cd:aa27:8012:26c4%6]) with mapi id 15.20.5332.012; Wed, 8 Jun 2022 16:36:47 +0000
From: Joseph D Touch <joseph.d.touch@aero.org>
To: Marcello Caleffi <marcello.caleffi@unina.it>
CC: Jessica Illiano <jessica.illiano@unina.it>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "qirg@irtf.org" <qirg@irtf.org>
Thread-Topic: [Qirg] Survey paper about the Quantum Internet Protocol Stack
Thread-Index: AQHYeYVpBsqi6/6+OEq8Ls8mUUG3Vq1DpsaAgAAj1gD//9z1gIABrrIA///tPAA=
Date: Wed, 08 Jun 2022 16:36:47 +0000
Message-ID: <3A9F0CB8-8F09-486B-9B48-09F66BA7DFB6@aero.org>
References: <95660D1B-5687-49E8-B779-6FFE27652B13@unina.it> <2d44d95d-2d90-64d6-20a4-36856432cac1@gmail.com> <A118EFF3-FC3E-462E-B368-BC8D95AFE768@unina.it> <92076DEA-CE4B-44C1-A20E-B0F275CB97EF@aero.org> <BBBDD15E-E856-4A88-80A4-CD535E78EBE0@unina.it>
In-Reply-To: <BBBDD15E-E856-4A88-80A4-CD535E78EBE0@unina.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.60.22041000
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=aero.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 11786603-d138-4087-4132-08da496d148d
x-ms-traffictypediagnostic: MN2PR09MB4955:EE_
x-microsoft-antispam-prvs: <MN2PR09MB495575B5EBB68281EDAF01D4BDA49@MN2PR09MB4955.namprd09.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: F7NK1BREHDgcVaRiOFg6ItNkOkZr8dtQ4GrqiUeekJ73uxJ3oqr8XMUrwoP8juhyXiA78RVBtHvgdcWKefoVaYoyMdKOARLZSGP0o1fFaSQIoaTqziR6R1tiXAUaHs1JCQ4N+qm2CNmR3uiLDGH3SbetOMj5rPtgr5FtsNQ7n++puN0/22RA26s8hu1WlgxFlLJIDq/TUEOz0HxklKah/g9+1lvocUSx4INbeL4mAecRg6nFaCHOIpCPPIYos+iy9piAecUlyFvVWfwMbjbePNCwpmHzwE/2xnoeGzNY7KDsrzJDMaTV2td2mNjNROET7nAk1QnldBcMxv7RVgbhHHGjjUZ597IHvS8NkYLWpZvnlQlKqwiI0C6iBmkNjlVnl0W3nbt8/15kDzEQYBWosmGClaXcRb3oRDkE5kKxeU8bbykwJOV4yB2vgR3yjTNyqaAk/MThJ9CfZ5Oj282dBri/dh3LsQ9FK/l34PS9yj5BYGYD+GGaiS8gpeTkWFClIRIIkeOmtZRJzv6IlKUjiYHILHiLwkpROduKpwxgbn3/NE0NB4u+UyFXg5zRUl9mgllDnf/15MloLLYFWKd7DZVdaFgZcSe9O9uKJvMt9LuiaOD0Ft6XK7irZmnzb0h1PC0W6eMBMR92E4R3tmw9HT1uNpjPIL4lhY2REhzmWJsR2mYtJhjLv5v/2JwMmxf6P/QbQOvwPxM+tt1ieMoi0AUddNvG1G0XMIy7vwpQDV0qcvHDJLX8SCJg5TjwFjLYWlyc8LeQ+cXM4zVna+pooMu1FMCIeLSOWpvnsgSl61q2RXk4vzRJ7UVUFRz946iK
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR09MB6542.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(66574015)(186003)(83380400001)(122000001)(38070700005)(38100700002)(6506007)(91956017)(6512007)(53546011)(71200400001)(54906003)(966005)(6486002)(316002)(76116006)(508600001)(2906002)(2616005)(6916009)(30864003)(66476007)(8676002)(66946007)(66556008)(66446008)(64756008)(4326008)(5660300002)(36756003)(8936002)(86362001)(33656002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: Tg/gnysNbTx6gjbo00Rsmps4slKmdrAmQdfYoOz2GT9EIGpljjYl9Ap7jMZv/N+2iv8icoBw6aeT98PzunENdP8v9u55ANIfgR2VDYTrLDL2FyxHKQNnjg5vsWhvi2Ngnb2JIiJFP3juHLmC9iciJ6G40zcZj2RkUurzQFhPgMP0MFawrLSmAKWCPiMEVc5dmG08422TLToxxA1I3jQhIveVjmIPE/0mH9MvKFVAFedEn7UtuPz+dQsSIw4hvg0ptBmtw5KeC8ZIZjrMdZcJc5u00qvWBPVOM0lUIGYQ5l9AzYdQpEPo3933Q8TxaH7k4raz4MxaxL2/kMmJUa8nH1ZDPbnuQ+Um6zKdEHof3kIYQ2KOEU3gYaCkHjYi/AQurCLuE18S6vd7rvpEIphq1Aq2/5R/PTXJ8C2HZoL8uiA3X/7nnzyepkTy4aHkXmvaYK1o61VOkC+ZlkrBsBRvb0KBuzsD0yK2AOwlevyTnilcwahAMDHUStrIKkK7liYTI0geMKOGWmeF5Ovlse34S2dzAY7ND59zibdh78v8g9CIuTZPArF7DzyBF6XzjeWnlSQ68h6Z1wENF6xfri08xYIwuhJLT0SAP2SkfCwYmUQz4CgOvxWm+c483oz3IL99mYGSZVIAaplAhaRFo4sd/4j0FE56/YJUiGXhQ8L+QzRxp9F2mCjiYUSLNeh22d02J418W1ZuoJjT8puspMb/3FHGZb/C9iVlAKHc3sKOBCSurW0QcEJoP9s6p0Z/VkUI7U3BONH6A+LGtqy+ZC5at7SCJdlSoRRMTccpq2ah/wg+rMYVrpfjEDxSPAvthpQVAEXTyNvyMptTCDsuEaRqT0SA4sDYgXai20eLQ+CHsUN9/GkF3qk/shZbB+YKandtB95wDTOojML3ERW41TGBCBbEoYB64etfO58tXrZzJt2srTSqoQrX6nU0p/d3V+USGlydON5b9RxIWr8M9cc5HVEo9lZD6y8f8uwUfToq281O3ipEBXvuL9qi9uQ0Bc8U2uvXhg9CpI3oEnfK+aZ8ZABt1InUCuL1oItAB6sA7zV3syF3OB8LJ3eZ76oglHTrHFQLh5+Ur2pE8IO2/npRsun43bmMYP2MaZJCE1K0w8ZONpAomeeuAAxsciU422vah7PBtPoJi993Q7YMRxtVlcn9qb6Pfnima1KGGxvBqL5USXrJnysV0zaoom5n9YpVV7NC/pHFCAcZht4822ZnripoL2NP8+nXBj0JcvNlbJQt1/2G1USUvavTJ1aN/b4Si+MDJXVTZ0pEj9K7OTlBYn6TMRvtjT1TaB0L5ms28SLGYGjO7g1/1T25KwJvJbXO8iKh2U+5Wzvi13U+9xHQAT34EkLhqKeHQaRbabRX/70Jgs52YpmylgyO8z+pmwcA2wjBW52SSMOKNS03rqkG5pfTC3mRGoNeMjqmhANoSav3HEDf9eHboHwYxBJtJDEGiZ94zzaBfedsc5qXyWcvsmNcI8SH+qzdm4SjBAFZCOvM+mt9n1jOVgmTRmHw/8osB9IxS5Y6QJd+JuxK0RVJFpjDDRKl+yS9J6if4NaIiLnZ64Tc5rcf0JHerpFr3uww1BNATqvZukPi8SrxrisZAmrzD3jJfS0R3Ghx+U7JyB+ogDJTFpGPGo6RySAbbp7ng+VhMEpkjcRlrWpfNDAWkrZRlx7a5lsFu92/Kf7XiWRp1Jt90AMKfVYNocxgh11z/ofka3xnldbBhq7G1zuQLFCroOEeat6ozkQby07aJjpIV6BxW7BxN9oYKQPV3D+Ac9fsTprJ
x-ms-exchange-antispam-messagedata-1: WywSPVcQfZwd7w==
Content-Type: multipart/alternative; boundary="_000_3A9F0CB88F09486B9B4809F66BA7DFB6aeroorg_"
MIME-Version: 1.0
X-OriginatorOrg: aero.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR09MB6542.namprd09.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11786603-d138-4087-4132-08da496d148d
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2022 16:36:47.1098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB4955
Archived-At: <https://mailarchive.ietf.org/arch/msg/qirg/HwRb40FgNkN7ztbsP9CcS7cVE3E>
Subject: Re: [Qirg] Survey paper about the Quantum Internet Protocol Stack
X-BeenThere: qirg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Quantum Internet 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: Wed, 08 Jun 2022 16:36:55 -0000

Hi, Marcello, On 6/8/22, 3:45 AM, "Marcello Caleffi" <marcello.caleffi@unina.it> wrote:



    Hi Joseph,

    I understand that the sentence copied by Jessica, taken as per-se and without reading the long discussion about "physical quantum connectivity" vs “entanglement-enabled virtual connectivity” conducted within the paper, could raise some misunderstanding.



FWIW, I replied to the post, but based the reply on the paper, not just the post.



    Indeed, we believe that there is a lack of common terminology within the community — with different authors using different names for similar functionalities and vice-versa — and this might have impact as well.



Agreed. If you want to talk about classical network terminology, you’ve got 40+ yrs of expertise and its terminology to catch up with.



    I'll try to summarize some concepts at my best, tough some reading of the paper is the better option.



    ------------------------------------------------------------------------------------------------



    Coming to your observations about classical Internet:

    - I agree with you about ND “discovering” L2 connectivity

    - but L2 connectivity means that sender could reach destination by simply transmitting the packet through the proper interface.. this requires that there exists a physical channel (or a sequence of physical channels with some optional hardware — the switch — in between with the only purpose of reducing the collision domain) interconnecting source and destination



The same can be said of L3 connectivity, L4, L5, etc. They all assume that sending a packet out *that* layer implies an ultimate physical path. There is nothing magic about the L2 seen by an L3. E.g., when your IP sends out Ethernet, it could be going over many layers - MPLS, SONET, WDM, etc. - including being tunneled back over IP or even UDP.



    - clearly, probing the existence of a (sequence) of physical channel(s) doesn’t imply that we can acquire full knowledge about the physical topology (and I substantiate your example about complex ethernet networks by mentioning that ND in general can’t discover redundant links closing a loop within switches but simply "Spanning-Tree”-enabled links),



You never probe "physical channels". You probe interfaces. They can be logical, e.g., when you run a VM inside a machine, the Ethernet you think you send out the interface you think you have don't exist "on a wire" unless that packet leaves the machine; even then, it can be encapsulated.



ND won't find lower layers that have loops that the lower layers don't detect or prevent - but that's a useless tautology.



    - so, I stand with the sentence "ND gather information about the physical connectivity”, or if you prefer with the sentence "ND gather partial information about the physical connectivity”, as long as we don’t write something like "ND gather full knowledge about the physical connectivity”



ND gives you none of this on its own. ND is used by IPv6 to discover L2 addresses (and sometimes to redirect to different routers), i.e., it is ARP, proxy-ARP, and ICMP redirects rolled into one. There are ways in which those tools can be USED to gather L2 **REACHABILITY**, but that's not topology. And they don't just spit that info out. You have to write a tool do do this (there are some available).



    ------------------------------------------------------------------------------------------------



    Coming to the paper sentence (BTW, we didn't wrote that L2 classical topology is correlated with quantum link topology), the “physical” connectivity should be placed in the context of “physical" vs "entanglement-enabled virtual” (with the main meaning of “physical" for distinguish from virtual) rather than L1 (physical layer) vs L2 (link layer).



I mentioned that L2 classical isn't correlated with quantum as a caveat in general. It wasn't aimed at something you said. However, you do imply that quantum has a level of logical connectivity that classical does not, which is the converse; classical has many much more rich variants of logical, including concurrent overlays, nested overlays, etc.



    Let me give some more contest about the sentence (but, please, these are just short extracts from the paper with no ambition of providing a complete self-consistent description)



    Pag. 13, Sec. V.1

    <<<

    In classical networks, a single concept of connectivity arises, referred to as \textit{physical} connectivity.



Reachability is a single concept. Connectivity is not  - again, there is no way (from inside a network) to discover physical connectivity, only reachability.



    Whenever there exists a physical communication link\footnote{Obviously, the definition of physical connectivity can be easily extended to a multi-hop route constituted by several communication links.}



That is known as reachability, as above.



   between two nodes, these nodes are defined ``\textit{connected}''. And the successful transmission of a classical message between these two nodes requires at least one use of the physical communication link. As a consequence, the successful transmission depends on the instantaneous propagation conditions of the physical channel underlying the communication link. Stemming from these considerations, the classical connectivity is \textit{physical} since it strictly depends on the physical channel.



Quantum connectivity has the same dependence (see below). All communication depends on a physical channel, in that a physical channel is defined as the physical means by which two or more endpoints establish communication (quantum or classical). Again, this is a tautology driven by definitions and not enlightening.



    Conversely, quantum teleportation enables the transmission of one qubit without any use of a quantum link. Specifically, as long as an entangled state -- say an EPR pair for the sake of simplicity -- is shared between two nodes, they can transmit a qubit regardless of the instantaneous conditions of the underlying physical quantum channel.



I would agree to the claim: "as long as a quantum connectivity was established before, teleportation can transmit a qubit without that link being available now". But you can't establish entanglement without quantum communication. Note - as with classical, quantum comms includes "sneaker-net" (physically moving fermions).



  Remarkably, the qubit transmission is still possible even if the nodes are not anymore interconnected by a quantum link\footnote{It is worthwhile to note that, thanks to the \textit{deferred measurement} principle \cite{NieChu-11,CuoCalKrs-21,IllCacMan-21}, the transmissions of the two classical bits -- and the subsequent post-processing at the destination needed for performing a teleporting operation -- can be delayed at any convenient time. Accordingly, in this section we focus on the peculiar connectivity characteristics arising with quantum entanglement.}. In this sense, we can say that entanglement enables a \textit{virtual} quantum link, and consequently the concept of \textit{virtual connectivity} arises.



This is the key point and agreed.

    >>



    By oversimplifying:

    - physical connectivity means that the connectivity requires the exchange of a message through a sequence of channels, whose instantaneous conditions affect the exchange. During the distribution of entanglement or by directly transmitting a qubit, you’re facing with physical connectivity.

    - Yet, once shared, entanglement provides a virtual connectivity that is independent from the instantaneous propagation conditions of the physical channel

    - (see also the remaining part of Sec. V.1 for further details).



Agreed; my observation is that some of the rest of the discussion of classical networking and the implied new capability of ND (vs ARP, ICMP ping, etc.) is unnecessarily misleading.



    Pag. 25, Sec., VII.5

    <<<

    Clearly, as for the classical Internet, the Quantum Internet should rely on some networking functionalities such as path discovery, forwarding and routing [110, 21]. But these functionalities must be designed to account for the peculiarities of the entanglement as communication resource.

    Indeed, part of these functionalities can be carried out through classical networks by existing protocols. As instance, neighbor discovery – used by network nodes to gather information about the physical connectivity – could be accomplished by resorting to classical protocols [111, 112, 113].



Reachability, not connectivity. AODV and other ad-hoc protocols are no more useful than would be RIP, OSPF, or IS-IS, or even BGP. And IPv6 ND is no more useful than are IPv4 ARP and/or ICMP. AODV and ad-hoc protocols discover connectivity over multipoint links, which you haven’t discussed at all and are not uniquely relevant.



However, as widely described in Sec.5, the concept of virtual connectivity – including its variations such as the augmented and on-demand connectivity – arises with entanglement.



Classical nets have virtual connectivity too. What you’re referring to is what I would call “temporally discontinuous reachability” (or just “discontinuous reachability”), and exists in classical nets too – e.g., email relay and DTN (delay tolerant networking – which is basically re-invented email relay).



IMO, the unique feature of quantum nets is what I would call “post facto reachability”, which classical networks cannot achieve.



(note: the signature I use on my personal email is not accidental: “Temporal epistemologist”, a term that basically means “one who studies communication protocols”, and was coined by my wife, Gail. It refers to the fact that communication protocols describe how information flows over time)



Whether existing neighbor discovery algorithms can be employed for virtual neighbor discovery – and how the physical neighbor discovery should interacts with the virtual one – is yet to be determined. Indeed, not only the virtual connectivity dynamics are intrinsically different from the ones arising with physical connectivity – as described in Section 5 – but when it comes to multipartite entanglement the concept of neighborhood evolves from a binary question – “is a certain node one of my neighbors?” – to a more complex question, including at the very least the discovery of the identities of all the entangled nodes.



They’re the same question and “neighbor discovery algorithm” isn’t relevant here. That implies the difference between one-hop L2 reachable and L3 one-hop reachable, which isn’t relevant for either classical or quantum.



You do need knowledge of reachability as a topology, but again, why does that need to be physical, even for the quantum layer? What do you care if you send a qubit or some lower layer teleports it? Isn’t it the same from your layer’s viewpoint?



The only issue appears to be the difference between quantum reachability (which can be discontinuous) and classical reachability.



    Furthermore, both physical and virtual neighbor discoveries play a pivotal role for the deign of routing services such as path discovery and path forwarding.



Again, these are dependent on reachability only.



Here, the first step is to identify, within the quantum network infrastructure responsible for the distribution of shared entangled states, at least a physical quantum path between source and destination. This quantum path must be augmented by a classical path, so that quantum nodes can exchange proper classical signaling as discussed in Section 7.2. In this regard, one should argue that physical connectivity enables direct communications between neighbor nodes, whereas quantum repeaters and entanglement swapping extend the spatial domain of the virtual connectivity, enabling direct communications between nodes that may be topologically remote. However, virtual connectivity should not be considered as the main connectivity, as well as neither physical and virtual connectivity should be considered as mutually exclusive strategies. On the contrary, they are strictly correlated and path discovery should be able to evaluate – case by case – whether entanglement-based communications outperform direct dispatch, where quantum information is directly transmitted through the physical quantum channel.

    >>>



    So, in a nutshell, in the Quantum Internet:

    - we need classical topology discovery AND quantum topology discovery



Agreed. Where topology is defined by reachability, IMO.



    - classical topology discovery might resort to classical protocols -> but we don’t believe this is the correct direction, see as instance [1,2] where we gave some insights on quantum solutions to classical network functionalities such as MAC



What you really need is to have classical reachability between each pair of quantum nodes at the quantum layer you are designing. There is no need for a complete classical net per se.



    - quantum topology discovery can’t resort only to a quantum version of “classical” protocols because the connectivity is virtual, augmented, on-demand.. so we need to figure out new algorithms and the worst decision would be starting to design a Quantum ND without fully understanding the peculiar features with no classical counterpart of entanglement



The only way to “discover” a quantum topology is to try to send qubits and see where they reach. It’s the exact analog of classical topology discovery. In both cases, as they say with investment advice “past behavior is not a guarantee of future success”. That’s even more true for quantum nets, because the use of entanglement for qubit transmission is destructive (to the entanglement).



    [1] A.S. Cacciapuoti, J. Illiano, S. Koudia, K. Simonov, M. Caleffi, "The Quantum Internet: Enhancing Classical Internet Services one Qubit at a Time", arXiv, May 2022.

    https://arxiv.org/abs/2205.09476

    [2] J. Illiano, M. Viscardi, S. Koudia, M. Caleffi, A.S. Cacciapuoti, "Quantum Internet: from Medium Access Control to Entanglement Access Control", arXiv, May 2022

    https://arxiv.org/abs/2205.11923



    ------------------------------------------------------------------------------------------------



    Btw, thanks for the interest and the email, and feel free to reach us out for any further comment or doubt.



    Regards,

    Marcello