[Qirg] Feedback on draft-irtf-qirg-qi-multiplane-arch-02

[Wojciech Kozlowski <[e-mail]>]

Hi QIRG,

<as co-chair> I agree with the authors that it is time to start wrapping up the document so that it (a) does not become a kitchen sink, and (b) can get published before it is no longer relevant. With that said I would like to mirror Rodney’s remark (made at the Tuesday meeting) that 13 pages were added in the last version so it would be good if the authors could provide a concise on-list summary of what was added to justify the 13 pages. Having read the -02 draft, I don’t expect there to be much to worry about, but I would appreciate if the authors could help us here.

Additionally, with three architecture drafts flying around I think it is also important to remark on how they stand relative to each other. As an RG we don’t produce standards and as long as there is consensus that the work is interesting enough to publish it can go ahead provided the relevant context is mentioned in the draft. To address this, I think the authors can start thinking and discussing on the list about what they will write in the paragraph explaining the RG consensus and context as per RFC 5743 section 2.1.

<as individual> Having read the -02 draft I think the draft is a very strong presentation of the authors’ perspective on quantum network architectures grounded in the lessons they learned in QKD. This addresses a very important point of how we will see the QKD networks currently being deployed into future quantum entangled networks and how we might be able to support their co-existence.

I do not have any technical questions to pick apart, just a bunch of suggestions that can hopefully help the authors with conveying their message. You don’t need to reply to these points – I’ll read the update and check how they have been addressed.

Note: I refer to page numbers based on the PDF – not the txt file. I would hope they are the same but just letting you know in case of discrepancies.

## Major points


  1.  In the introduction of the document you mention there are three essential properties: agility, sustainability, and pliability and three characteristics: universality, transparency, scalability. From that point on, references to these properties and characteristics are scattered in the text and not all of them are addressed equally. It would help if at some point in the document you can summarize how your proposal addresses these points.
  2.  There is a distinct lack of diagrams in a few places where a diagram could save you a lot of words or at least illuminate the concepts much better:
     *   In section 4.1, p. 7, the relation between the planes could be shown with a diagram.
     *   In section 5.3.3, a diagram would help to explain the relationship between service units and QUIs
  3.  I am not sure if the document is easy to follow by a network expert with only passing quantum expertise (i.e., knows what QKD is, but not much more). I think it would be valuable to make the document more approachable as it will also make it more approachable to many others. It would be best if somebody with a suitable background could read the document and provide you with feedback.
  4.  It would help if you stated your goal relative to CLAS somewhere clearly in the document. Are you (a) proposing a completely new architecture inspired by CLAS, (b) extending CLAS to quantum, or (c) something completely different. My background in CLAS is weak so a clear statement on the extent to which you build up on CLAS would help. I think section 5.1 is trying to do this, but in my opinion does not really answer my question.
  5.  An inventory of the interfaces your architecture proposes would also help. Your strata diagram shows them diagrammatically, but an inventory of the interface groups would help. If at least, to provide a clear checklist on what work researchers can pick up.

## Minor points


  1.  Section 3, paragraph 4 (p. 5) – you mention integration, it is not 100% clear to me to the integration of what with what are you referring to.
  2.  Section 5.2, p. 11 – it would be helpful if you could relate the Quantum Fabric Stratum to QKD’s Quantum Forwarding Plane – how they relate, what lessons did you take away, etc. And following on this show how this enables an evolution to next-generation networks. This is probably also a good place to draw attention to the change “Forwarding” -> “Fabric”. It appears that you use Forwarding exclusively for QKD, but I only noticed this on a second re-reading. And this addresses Rodney’s naming concern.
  3.  P. 13 onwards – The resource plane is shown in the diagram and referred to extensively later on. But without a definition. I guess it follows from CLAS, but it would help if you could bring in the definition of it into this document especially since the resources of a quantum network will be so different.
  4.  Section 5.3.1, p. 15 - The service unit examples are poorly explained. I have no idea how to deconstruct the three service unit identifiers you proposed.
  5.  Section 5.3.1, p. 16 – The last paragraph is very rich in detail but does not really explain anything. Is this paragraph necessary and if so can you rephrase it in a way that explains the underlying concept as well?
  6.  Section 5.3.4, p.19 – It would help if you strengthened the language that the QoS parameters are suggestions which may or may not be included. Technically you already say this with “QoS parameters to be considered include”, but natural language is a difficult beast so some extra clarity would help.
  7.  Section 6.1.1, paragraph 5 (p. 25) – “Depending on the protocol implemented by the repeaters (for example, the one presented in this work…” <- what is the protocol presented in this work?
  8.  Section 6.1.1, paragraph 6 (p. 26) – You use the term “quantum error correction” twice but seemingly to refer to two different instances of quantum error correction – can you clarify this. The current phrasing is that 2G adds quantum error correction and 3G relies on quantum error correction – what is the delta?
  9.  Section 6.1.2 – I think it would be nice to add a reference to RuleSets from Rodney’s group here.
  10. Section 6.2, second to last paragraph, p. 31 – “simulation time is generally shorter than simulated time” <- I don’t think this is generally true. When I still did simulations I had the opposite because I was simulating every photon detection event which eats up processing time to process the event. This is not just a nitpick but shows that the challenge is even bigger – simulated time can go faster or slower and how do you make both work?
  11. Section 7.4 – it would be worth mentioning the US.

I hope this helps!
Wojciech Kozlowski
Quantum Communication Lead | SURF | [e-mail]<mailto:[e-mail]> | M [phone]
SURF<http://www.surf.nl/> is the collaborative organisation for IT in Dutch education and research