Re: [Qirg] Call for agenda items at the IETF 118

["Diego R. Lopez" <[e-mail]>]

Hi,

First of all, let me apologize (to Rod and you all) for not replying before to the original message Wojtek mentions, since I was totally unaware of it. Actually, I checked with Blanca and Vicente, and they did not have Rod’s original message either. I am not sure what may have happened, but anyway I do believe it is important to address Rod comments as well and I will start with them, taking the text of his message from the (blessed) mail archive.

In total, this will become a long message, but I hope you’ll find the dialog interesting enough to get to the end of it…


Rod said, a few months ago:

1. I know it's heavily informed by your QKD work, but can you say a
   little (here on the list, no need put it in the document yet) on
   your view of the relevance of this document to more general-purpose,
   entangled quantum networks?
The purpose of the document is precisely this: derive a framework for general-purpose quantum networks (what is described in section 4.2) from the previous experience in QKD (what is described in section 3) and the CLAS proposal (introduced in section 4.1).
In the -01 version in which we are working right now, we should be clearer about this aspect, making a more direct declaration and, looking at the current ToC, giving the document a structure more focused on this key issue.

2. Likewise, what about the relationship with <whisper> ITU
   </whisper>? You have cited (and probably worked on) a number of
   those QKD-specific documents; how do you see the IETF role v. the
   ITU role?
3. My _impression_ of the ITU work is that it is strongest at the
   physical layer and above the application layer, at the key
   management functionality. This leaves a big gap in the middle
   layers -- L3-4 ish, give or take.  Does that match your experience?
I was directly involved in some initial QKD ITU work, especially when it came to define architecture for control and management, precisely with the idea of making room to SDN and model-based management concepts. As you say, the work was first very much focused on the physical layer features, and after that on key management, what seems natural given the goals of ITU standardization and their connection to governmental cooperation and international regulation. And this does leave a big gap, for network protocols and models in all possible planes, whatever the names we give to them (see below).
I have a similar experience when SDN blossomed a decade or so ago. ITU took the original research proposals and the early ideas from (de-facto or de-iure) standards and provided a quite comprehensive conceptual architecture, further applied in many different environments. The IETF focused on protocols, and the network architecture associated with them, accelerating the development of matters such as YANG data models, NETCONF/RESTCONF or CLAS itself. I see a similar pattern here.

4. "Quantum forwarding plane" is probably the wrong name. For
   entangled networks, there really is no forwarding; the service
   provided by the network is creation of E2E entanglement to be
   consumed by applications.  That is very much a distributed process,
   nothing at all like the Internet's store-and-forward of packets.
   (Actually, I would expect this aspect to be true for multihop,
   trusted intermediate node QKD, as well.)
“Quantum forwarding” was the term we decided to use some time ago to identify the separation of concerns between the sharing of quantum states and the procedures related to the services intended to be supported by this sharing. We used the term “forwarding” to, first, be neutral between the prepare-and-measure and entanglement used in current QKD devices, and second, illustrate the idea that the goal of a data network is about the abstract task of “forwarding data” from one end to another/others.
We would be more than happy to find a new term for what is now the “quantum forwarding stratum” that better reflects the goal of quantum state sharing across the network, but let me remark the “forwarding” here is intended to be the abstract process of making the state available at different points of the network. So, an alternative would be to include this justification in the text of the draft.

5. Going back to point 1, how will this architecture support the
   stages of evolution of a Quantum Internet as outlined by Wehner,
   Hanson, Elkouss (Science)?
Good that you ask about it, because matching the framework with the stages identified in this paper is one of the things we had in our to-do list. I do not see any serious misalignment here, and it would add to the rational for the proposal we make in the draft.


And now, Wojtek says:


1.       I do find all of Rod’s questions still relevant, and I don’t think they’ve been answered on the mailing list yet. The e-mail in question: https://mailarchive.ietf.org/arch/msg/qirg/k-ceak6qkD6JSQ0Jn-NFZuy6AqA/.
Thanks again for the heads up!

2.       Following up on Rodney’s questions about the ITU – is this architecture inconsistent with what the ITU is proposing? I guess the “key” question is whether key relaying is done in a separate “key management” layer or whether it’s part of what you call the “quantum forwarding plane”. Is that the only difference?
First of all, this architecture is intended to provide a framework for the integration and validation of the different proposals we have and will have for exploring the Quantum Internet. It is intended to go beyond key distribution aspects. As I said in my reply to Rod, QKD was the focus of section 3, but we are trying to go beyond. This said, the mechanisms for key relaying proposed by ITU would fall on the SOP (as discussed in section 3) and eventually on the Service Stratum (as introduced in section 4.1). I am thinking we could make the exercise of mentioning this mapping when talking about the SOP in section 3 (only briefly, see below) and may be including a more thorough discussion in section 4.1.

3.       Perhaps I’m too naïve about SDN and control planes, but I was somewhat bothered by the fact that the document constantly refers to SDN controllers while the draft was about networking planes and strata. In principle, and to the extent this draft is concerned, one can discuss networking plane functionalities without assuming a particular implementation – in this case of a logically centralised SDN controller. I think it is worth separating a controller implementation from this multiplane draft simply because it is entirely possible to build a QKD network with the same networking planes, but no centralised controller for a control plane. Do you think these concepts can be separated or do you see them as intrinsically linked to each other?
The draft, and the CLAS architectural proposal itself, is built under the assumption that planes within and across strata communicate through well-defined, open interfaces supporting programmability, as a generalization of the common SDN architecture that defines a controller as a mediator between application and network (forwarding) devices. It includes the archetypal case of a centralized controller, but is not limited to that particular realization, as you say. These broader implications of SDN principles are among the main motivation of the original CLAS proposal, and it is the main reason for using it as the base for the framework proposed by the draft.

4.       I was a bit lost in the transition from Section 3 to Section 4. Section 3 talks about a Service Overlay Plane and then in Section 4 we jump into a Service Stratum. Having stared for ages at the big stratum diagram I can see the usefulness of this separation – I understand that the key benefit is the ability to logically separate the control and management planes of the different strata – is that correct? I think the rationale for using CLAS is there in the text, but it doesn’t stand out very strongly. Could you perhaps make it easier to understand why CLAS is good for quantum networks? Intuitively, it looks really attractive to me, because it seems that one can simply replace the forwarding stratum with repeaters while the service stratum remains QKD and one can now run QKD over untrusted repeaters!
Section 3 is mainly intended to present the lessons learned from QKD deployments, and introduce a general architecture applicable to those deployment, while section 4 is the generalization of such architecture towards a Quantum Internet, augmented by the extended SDN approach CLAS proposed, as discussed in my reply to the previous point. We could enhance the draft by changing a little bit the flow, making clear section 3 is about the foundations of the proposed framework and including the discussion on CLAS there. Section 4 would start with this discussion of the extended SDN concepts enabled by CLAS how this decoupling can be become beneficial for quantum networks, including the example you mention, that can be quite illustrative…

5.       It is clear that there a lot of lessons you have learned in your QKD deployments and that have been presented in this draft and I think we could benefit if the draft was much more explicit about their relevance to entanglement-based networks. This relates to Rod’s first question, and I do think it is an important one in the context of QIRG. As I see it: the connectivity stratum, i.e., the OTN remains the same for both QKD and entanglement networks – they both need optical fibres. The quantum forwarding stratum would change in between QKD and entanglement networks – or at least evolve more steadily from QKD to entanglement in an isolated fashion hidden behind the standard inter-stratum APIs. And then the service stratum can remain unchanged if all one cares about is QKD – one simply gains additional security with an entanglement-based forwarding stratum – or it can evolve to provide new applications. Would it make sense to involve a bit of discussion on what the service stratum could look like for applications beyond QKD?
As I said in my reply to Rod’s first question, we want to make a clearer statement about how the general principles proposed in the document derive from QKD experience, trying to go beyond QKD networks. Again, I think the points you make regarding how strata would evolve could be useful to make this clearer. Actually, I intend to address them in the coming version of the document.

6.       Do you see any of the ETSI APIs as suitable for the inter-stratum APIs?
The SDN APIs (QKD-015, QKD-018, QKD-023 at least) certainly yes. One of the goals we have is to analyze them and explore how we can make them evolve to address the general quantum network case.

I hope you find this helpful in your next iteration of the draft!

Indeed! Thanks so much!

Be goode,

--
“Esta vez no fallaremos, Doctor Infierno”

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/dr2lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Mobile: [phone]
---------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição