[Qirg] Re: comments on draft-irtf-qirg-qi-multiplane-arch-02

["David R. Oran" <[e-mail]>]

I’ll quickly inject something that is possibly totally useless. Here goes. I’m as or even more uncertain than Rod about the what a “stratum” is in the taxonomy and how it differs from a “plane”.

For example, there’s also the usage of the term “stratum” in the domain of clocks (particularly NTP) which at least to me is utterly different from how the document seems to be using the word. In the world of clocks, a stratum specifies dependency relations among elements providing the same service/operation/protocol. So the clock stratum for an NTP server indicates which clocks it depends on for its state synchronization/maintenance, and by extension which clocks depend on it.

So, among the community of interest for QIRG architecture work, most of whom I think know about NTP and clock strata, it may be advisable to think carefully about whether and how to use the term.

DaveO.


On 18 Oct 2026, at 4:19, Rod Van Meter wrote:

> Diego et al.,
>
> Comments on the new version of the draft, mostly but not entirely focusing on the -02 differences in Sec. 5.3, 6.1 and 8.
> https://datatracker.ietf.org/doc/draft-irtf-qirg-qi-multiplane-arch/
>
> I did go back and read it again, end to end.
>
> I'm also using the diff as one tool:
> https://author-tools.ietf.org/iddiff?url1=draft-irtf-qirg-qi-multiplane-arch-01&url2=draft-irtf-qirg-qi-multiplane-arch-02&difftype=--html
>
> -----
>
> First up, I remain confused about what a "stratum" is in your mind.  I went and looked in RFC 8597 (which seems very nice), but it doesn't seem to define the term in detail, either, instead referring to ITU-T Rec. Y.2011 (https://www.itu.int/rec/T-REC-Y.2011-200410-I/en)
>
> Text right below Fig. 1 on p. 6 of Y.2011:
>
> Each stratum comprises one or more layers, where each layer is conceptually composed of a data
> (or user) plane, a control plane, and a management plane.
> 2
> In general, each stratum will have its own set of roles, players and administrative domains
> (see ITU-T Rec. Y.110 [3]). The roles involved in service(s) provision are independent from those
> involved in transport connectivity provision. Each stratum needs to be treated separately from a
> technical point of view. This is achieved by mandatory decoupling of the user (or data) planes of the
> two strata.
>
> ---
>
> Followed by a footnote:
>
> In this Recommendation, the terms "data plane"/"user plane", "control plane", and "management plane"
> are used in a general architectural and logical sense. Each stratum is considered to contain functions to
> transfer data, functions to control the operation of entities involved in transferring such data, and functions
> to manage entities within the stratum. It should be noted that there is a multiplicity of definitions of these
> terms already in use in ITU-T Recs (e.g., I.322 [8], G.993.1 [9], G.807/Y.1302 [10],
> G.8080/Y.1304 ([11]), Y.1241 [12], Y.1711 [13], etc.). However, these are mainly technology specific
> and therefore not entirely appropriate at this level of abstraction. They should be considered in the context
> of the relevant technology when progressing the Functional Requirements and Architecture of the NGN.
>
> ---
>
> In that par above, "layer" definitely does not refer to a protocol layer -- it refers to the idea that strata themselves are layered at some separate granularity.
>
> So the service stratum, in some sense, lives "above" the transport stratum, is that right?  And each of those has a user plane (or data plane), a control plane, and a management plane.
>
> In your current draft, then, you propose three strata:
>
> * service stratum
> * quantum fabric stratum (I like this name better than quantum forwarding!)
> * connectivity stratum
>
> With the fabric stratum sitting above the connectivity stratum and below the service stratum.  And each of those three strata has (at least) four planes:
>
> * telemetry plane
> * resource plane
> * management plane
> * control plane
>
> Is that right?
>
> Wiser heads than mine may have opinions, but I feel like the distinction between stratum and plane (and maybe even protocol layer) isn't clear here yet.  Should they be defined more carefully?
>
> There are places where e.g. SOP is used that seem to span across strata in a "stratification violation" (akin to a layering violation).
>
> (As an aside, the I-D labeled CLASEVO seems to have expired.  Any plans to continue with it?)
>
> -----
>
> More detailed comments:
>
> First par: "require of consensus on"?
>
> In the second paragraph of the introduction you have a broken link to RFC 9340.
>
> 4.1:
>
> Still refers to "quantum forwarding plane".
>
> (Ah, SOP is defined here as "Service Overlay Plane".  I needed that.)
>
> 4.2:
>
> "While there is a radical..." this sentence is hard to follow and probably grammatically incorrect as it currently stands.
>
> Same par, "a proper control" probably doesn't need "a".  Also may not have verb number agreement.
>
> 5.:
>
> Some grammar and clarity cleanup in the first two pars would be good.  Lots of "integration".
>
> 5.2:
>
> "The concept of service unit becomes essential here" -- I agree, and I still don't know what one is.  Can you define?
>
> "how to route these packs" -- what's a pack?  Is it a type of service unit?
>
> "there is no need for a one-to-one mapping between those quantum entanglement units and the service units" -- okay, so is a quantum entanglement unit a pack?  Another type of service unit?
>
> s/open-space/free-space/
>
> "quantum links procedures" -- no s?
>
> "where a particular domain focuses on one or two of the strata, supporting the other strata being hosted in different domains is also conceivable."  So a stratum doesn't extend beyond the boundary of a domain?  I also don't see how the absence of one of the strata can be tolerated in a multi-domain architecture at all.
>
> 5.3:
>
> "Service unit" doesn't seem to be defined, although it's used back up in Sec. 4.1, where it appears to be a consumable of some sort.
>
> 5.3.3:
>
>> A QUI may represent a single entangled pair, a set of entangled
>         pairs, a quantum memory allocation, a local share of an end-to-end
>         shared state, or another quantum resource unit relevant to the
>         service.  The same end-to-end service unit may therefore be
>         associated with different QUIs in different domains, while preserving
>         the service-unit abstraction presented to applications.
>
>
> That seems like a lot to put on a QUI.
>
> Also, does this mean that e.g. a Bell pair might have different identifiers at the two nodes?  How do they share a name for the resource, then?
>
>>    The use of a QUI may also enable re-binding.  For example, when a
>         particular entangled pair decoheres, a quantum memory allocation
>         fails, a link-level establishment attempt does not reach the target
>         fidelity, or an implementation decides to regenerate the underlying
>         state, the domain can bind the same service-unit context to a new
>         local quantum resource allocation.  Such re-binding may not imply
>         preservation of a consumed or measured quantum state; it is a
>         control-plane mechanism for replacing or refreshing the underlying
>         resource associated with the service unit.
>
> Mmm, I'm not sure I understand how to rebind a QUI without ruining actions that are already in progress in various nodes.
>
> I think identifiers for entangled states should be unique.
>
> At the link layer, an identifier should be assigned where the photons are received. In a midpoint link (memory-interference-memory, MIM) it should be done at the BSA when entanglement is confirmed.  In a throw-and-catch link, it should be assigned at the receiver.
>
> After entanglement swapping, the new E2E (or at least multi-hop) state should have a new identifier, I think, and it should be defined where the swapping is executed.
>
> "a QUI may naturally be
>         associated with lifecycle information.  Such information may include
>         a time-to-live, a coherence window, an expiry time, an age value, or
>         an availability window."
>
> We're still studying what the best way is to express this, too. It's important that it be expressed in terms that are meaningful to every node that has the information and might act on it, so using local clocks is only appropriate when the information is only being processed locally.
>
> "Freshness information is
>         useful to distinguish different allocations, avoid accidental reuse
>         of stale state, and reduce replay or mix-up risks"
>
> We called this an "epoch" for each static memory somewhere in our older stuff, though I don't think we have used it recently.  If the identifiers are unique, it shouldn't be a problem.
>
> In general I'm not sure what value of rebinding/reusing an identifier is, though it is also the case that a node could act on its half of a Bell pair before E2E entanglement swapping is complete, so remapping would have to be done somewhere.  But that action could happen at either end (depending on a number of factors including the semantics of the application), and a true E2E identifier usable at both application end nodes, where the entanglement is consumed, doesn't exist at first.
>
> 5.3.4 QoS parameters:
>
> I love the direction this section is going in.  I think some of this is design parameters rather than information that appears regularly in exchanged messages.  It might appear in network management information and when exchanging information about links.  We've been looking into this topic, too, but hadn't gotten around to expressing it this clearly.
>
> I'm not sure this is as mature as some of the other parts of the I-D, in either writing or technical evolution, but then, *all* of QIRG is work in progress that can be expected to change and grow.
>
> 6.1:
>
> I don't have any specific comments on this, except that I don't see a lot of discussion of the strata in each analysis.
>
> In 6.1.4, the discussion of [SATOH20] might benefit from pointing out that the primary focus of that paper is on studying the issue of general network availability and whether there are new attacks in quantum networks that equivalent to e.g. various attacks on OSPF and BGP could destabilize network *operations*.  This one is also a little different from the other papers analyzed there, so maybe it actually belongs in Sec. 8?
>
> Overall, both in the prior version and the new version, Sec. 8 points out a few things but doesn't really analyze them or propose solutions.  Maybe that's okay for this I-D, or maybe it should be rethought.
>
> Overall, as Wojtek said earlier, we do want this one to go to bed soon, to prevent it from becoming a kitchen sink we keep throwing new things into, and so others can refer to it in a stable fashion.  So let's try to keep the scope as tight as we can while cleaning up the things I've covered here, and any other points that others bring up.
>
> --Rod
>
>
> _______________________________________________
> Qirg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

DaveO