[Qirg] Additional comments on Rodney draft

[Bruno Rijsman <[e-mail]>]

(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