Re: [Qirg] renewing I-Ds: comments, please!

[Wojciech Kozlowski <[e-mail]>]

Here are my comments on

> Name:     draft-van-meter-qirg-quantum-connection-setup
> Title:    Connection Setup in a Quantum Network
> State:    I-D Exists
> Expires:  2019-09-12 (in 1 week, 2 days)
> 
https://datatracker.ietf.org/doc/draft-van-meter-qirg-quantum-connection-setup/

Major comments are below, minor comments are in attached file (search
for '# WK').

1. The biggest value I see in this draft are the RuleSets and their
condition+action rules mentioned in section 4.3, but they aren't
sufficiently expanded on. I think that this concept, if generalised,
would be valuable to quantum networking in general.

I would first propose renaming them to match+action to tie to existing
terminology in the networking community (match+action is definitely
common, I'm not sure I ever heard of condition). It would also be good
to go into more detail about what these conditions and actions could
be. I think this draft lacks concreteness that a precise list of
possible conditions and actions could provide. A discussion on their
extensibility would also be valuable.

2. I would consider separating the RuleSet definition from the
distribution mechanism. Why? The match+action rules resemble SDN
(software-defined networking) with OpenFlow which program match+action
rules for classical forwarding and thus it would allow these RuleSets
to be distributed in different ways. However, the current protocol also
includes collecting information about available resources so this might
not be as easy as it first sounded in my head. I'm sure it must be
possible though. After all SDNs can also implement telemetry.

Another reason for separating, is that the concepts in this draft
remind me of L3VPN tunnels (especially when the authors talk about the
Responder being 'smarter'). Admittedly, I'm not an expert on this
topic, but a BGP router could potentially fulfil the role of the
Initiator and Responder and distribute information about these
connections using mechanisms that already exist in BGP and MPLS.

3. The resource discussion should be more concrete, but that will be
difficult without some pre-agreed nomenclature and commonly agreed on
notion of resources. It would be good perhaps to tie this with the
principles draft which will lay down necessary resource concepts on
which this draft can build upon.

4. I'm missing a bigger picture somewhere in the draft. Where does this
protocol fit in? Is it meant to run across a single administrative
domain or will it span many? Is it done end-to-end? If it's not end-to-
end, how are different connections glued together. Some diagrams could
help.

Cheers,
Wojciech