[Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

["Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>]

Hi all,

After the discussion held during the last TEAS WG session in IETF102 and some offline talks, we are trying to summarize the questions that we need to answer to resolve the open issue 31 (reference for background https://github.com/rvilalta/ietf-te-path-computation/issues/31) .

The question is: are there benefits in including in input of Path Computation Request RPC also te-tunnel attributes without any foreseen recommended usage by path computation engine? For example this is the case of administration attributes such as 'tunnel description' or of those attributes that are relevant only for the provisioning phase e.g provisioning-state... Please consider that the question is in the scope of a 'Stateless-Path-Computation' service: no state or data is saved by PCE after RPC output is returned to the client.

One of the main use case for the Path Computation RPC design is to support multi domain path computation. In this case the MDSC (the RPC client) addresses to a PNC (the RPC server) a request to compute a path within the PNC native/controlled topology during the quest for a multi-domain path at a given time T1; at a later time T2 (once, for example, the e2e path is identified) MDSC requests southbound to PNC per domain Tunnel setup (the segments of the multi-domain tunnel) with either the same or different metrics and constraints (MDSC implementation decision), to guarantee that the PNC would setup a path equivalent or better than the one computed at time T1.

Example: the MDSC computes a multi-domain end-to-end path between points A and Z and selects a path having te-metric 100. The path A-Z passes through the  domain controlled by PNC  X, entering in B and exiting in C, for which path computation RPC has returned a B-C path with te-metric 20. When asking  PNC X to setup the path B-C, a constraint on te-metric must be provided in order to avoid PNC X finding a suitable path satisfying all the other constraints of the end-to-end path but with te-metric higher than 20. If a different path is found with a metric < 20, that's fine. So, it's not essential that the same identical path is produced at the second path computation. The only requirement is on its metrics.

 Depending on the abstraction level applied by the domain controller the client may never know the actual computed path: the only important requirement is that the path metrics and constraints are met.
Therefore it is not necessary to guaranteed that the path setup at time T2 is exactly the same as the path computed at time T1 but only that it has the same or better metrics.

Regarding the policies, it has been said in the ietf meeting (see the relevant transcript) that they allow a "private" behavior of the server triggered by a condition depending possibly on any attribute of the tunnel request. This actually prevents a client application to perform autonomously the end-to-end path computation (e.g. using detailed connectivity matrix), as it doesn't know how each domain will behave when recomputing the tunnel for deployment (and so applying policies the client doesn't know and which could be even different for different domains).
In order to prevent this, policies should be explicitly shared with the clients, and be included in the detailed connectivity matrix information exposed by each domain to take into account not only the possible alternative path computation parameters, but also all the possible combinations of applicable policies. The client shall then select the suitable detailed connectivity matrix taking into account both the path computation parameters AND the applicable policies.
When such policy attributes are defined, they will be included in the path computation RPC.

Italo and Sergio (on behalf of co-authors/contributors)

Sergio Belotti
Senior System Engineer and Standardization Architect
IP/Optical Networks, Optics BU
Nokia
M: [phone]
Via Energy Park, 20871 Vimercate (MB) , Italy
[e-mail]<mailto:[e-mail]>