Subject: [Qirg] Additional comments on Rodney draft

From: Bruno Rijsman <[email-masked]>
Date: Wed, 20 Nov 2019 14:19:36 +0100

(Last long e-mail, I promise)

COMMENTS ON RODNEY DRAFT
------------------------

Here are some additional comments on draft-van-meter-qirg-quantum-connection-setup-01 that were not yet covered in my previous 2 emails (the segment routing e-mail and the GMPLS/RSVP-TE e-mail).

(1) In section 3.1. bullet 1 you say that the connection setup request follows the next-hops of the standard classical routing algorithm. I think we need to be able to support a more sophisticated path computation function that does not necessarily follow the shortest path determined only by the routing protocol metrics. The connection setup signaling protocol should support something similar to an Explicit Route Object (ERO) in RSVP. In the simplest case, this would simply fall back to the routing protocol shortest path as you suggest. But in more sophisticated cases, it could take other constraints such as remaining "bandwidth" (in bell pairs per second) into account and use a generalization of Constrained Shortest Path First (CSPF). In the most sophisticated cases, a logically centralized controller could take the non-linear effects that exist in a quantum network into account (due to non-deterministic swaps, distillation, etc.) and compute a truly globally optimal path. This is similar to the Routing and Wavelength Assignment (RWA) problem solved by controllers in Optical Transport Networks (OTN).

(2) In section 3.2. (particularly bullets 5 and 6) you state that a single node on the path (namely the egress node) creates the rule set. You call this a "centralized" model, because you contrast it with each node individually creating the rule set. I have no objection to the concept, but the chosen terminology might cause some confusion for classical network engineers. In classical MPLS + RSVP we have a somewhat similar (but not identical) situation where a single node (in this case the ingress node) makes the decision about the path. But we (classical engineers) call this the "distributed" model. The reason for calling this model "distributed" is that if we have many circuits, we have many different ingress nodes making the decision. Similarly, in your model, if we create many different connections S1->D1, S2->D2, S3->D3, etc. then we will have many different egress nodes deciding the rule sets (namely D1, D2, D3, ...). Thus a classical network engineer would still consider this to be a "distributed" model. A classical network engineer would use the term "centralized" model if there is a single controller (path computation element, SDN controller, whatever you want to call it) to decide the paths and rule sets for all connections S1->D1, S2->D2, S3->D3, etc.

(3) In section 3.2. (particularly bullets 1, 2, 3 and 4) you state that you don't want to flood information about nodes and links, for example in OSPF, for various reasons. I agree with many of the reasons, but I do think that this choice causes us to miss something important. With this approach, we cannot take information about the state of the network into account for choosing the path; we can only take it into account for deciding the rule-set when the path has already been decided. In fact, as we saw in comment (1) this document only allows the traditional shortest path to be used. For example, if some link has already used up its full capacity, we cannot choose another path to route around the nearly-congested link, because the bandwidth utilization is not flooded. Quantum networks will be very resource constrained, so this will not be a theoretical situation. But your objections are well taken, so perhaps a compromise is in order:

(3a) Don't flood the details of long linear repeater chains, but just treat them as a single logical link from a network-layer path computation and resource management perspective. Since such links are very common in quantum networks, this already cuts out a lot of the flooded information. This is the key-point of the e-mail thread that followed Dino's response to the GMPLS/RSVP-TE thread.

(3b) Clearly identify the subset of information that could potentially be needed for path computation based on resource availability, and only flood that subset of information. Information that is only needed locally, should not be flooded and should be signaled only when the connection is established. We already have a similar situation in RSVP today, where things like labels (the simplistic equivalent of a rule-set) is only allocated when the connection is established.

(4) In the QIRG meeting someone made an argument for using soft-state. I know this is going to be a controversial statement, but I think that hard-state is *much* better. Soft-state is the main reason that RSVP has problems scaling when we are creating a full mesh of LSPs between N edge nodes, where N large (say more than 100). You end up with 100^2 = 10,000 LSPs, and all the soft-state refreshing just kills the control plane. Hard-state protocols, such as BGP and the now-defunct CR-LDP, only need to advertise state once, and then it stays valid until the state is explicitly withdrawn or the transport connection breaks. The complexities of cleaning up the state are greatly exaggerated by soft-state proponents, and this is a well-solved problem (use TCP + one keep-alive per TCP connection, not per circuit).

— Bruno

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Nov 2019 21:35:30 +0800

> (4) In the QIRG meeting someone made an argument for using soft-state. I know this is going to be a controversial statement, but I think that hard-state is *much* better. Soft-state is the main rea…

Dave Oran said this and he is right. That is if you feel you need a control protocol hop-by-hop in the underlying classical network, which I think you don’t.

Soft state refreshes are more robust for failures and redundancy and allow state to time out gracefully (given there is no time budget to time out state, as Dave stated). 

Soft state refreshes in the last 10 years have gotten a bad name because when there is no state change, people think you waste bandwidth.

Dino

---

From: Bruno Rijsman <[email-masked]>
Date: Wed, 20 Nov 2019 15:05:03 +0100

Ah yes, with apologies to Dave, I knew that this was going to be a controversial statement. Preference for soft-state vs hard-state appears to be like a preferred religion or preferred editor - once someone has an opinion on the matter, it is hard to convince them otherwise (and yes, I myself am guilty as charged ;-)

Just one minor correction: I do think you need a hop-by-hop control plane for the classical channel. Any simple control protocol will do (standard OSPF, BGP, whatever…). For the classical channel, you don’t need anything fancy like RSVP. I am only advocating RSVP-like constructs for the quantum channel.

— Bruno

> On Nov 20, 2019, at 2:35 PM, Dino Farinacci <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Nov 2019 22:24:28 +0800

> Just one minor correction: I do think you need a hop-by-hop control plane for the classical channel. Any 

Yes, of course. So you can move packets across the network.

> simple control protocol will do (standard OSPF, BGP, whatever…). For the classical channel, you don’t need anything fancy like RSVP. I am only advocating RSVP-like constructs for the quantum channel.

Right, agree.

Dino