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

[Igor Bryskin <[e-mail]>]

Hi Michael,

Many network applications today are comfortable when dealing with uncertainties.  The usual way to go about them, of course,  is collecting data, building statistical distributions and use probablistic models and probability mathematics to assign/calculate probabilities for various events in the future. This is how they can accuratly predict things that were thought impossible 10 years ago. Why TE applications cannot do the same? I know that IETF is not the place to discuss how to do this. But neither we discuss how paths are computed over deterministic TE graphs. We just assume that servers can do that, and we focus on framework/models for client-server information exchange.

Now, provided that an intelligent server can perform probablistic evaluations accurately enough,  would it be useful for a TE application to receive from the server along with resulting path  a P(t) metric - path availability probability as a function of time within a specific time interval? I believe so, because then the client, based on this metric, could constrain or optimize the path selection, as well as use the metric in  evaluation of its own hypotheses. If the client does not trust the server's probablistic computations, it could choose to retrieve the necessary  telemetry and do the calculations by irself.

I would go even further and say that not only stateless path computations  could benefit from probablistic metrics, abstract TE topologies should be capable to expose them as well.

Igor
From:Scharf, Michael (Nokia - DE/Stuttgart)
To:Igor Bryskin,[e-mail],Belotti, Sergio (Nokia - IT/Vimercate),[e-mail],[e-mail],
Cc:Italo Busi,[e-mail],[e-mail],[e-mail],Beller, Dieter (Nokia - DE/Stuttgart),[e-mail],Leeyoung,[e-mail],[e-mail],[e-mail],[e-mail],
Date:2018-07-30 11:02:27
Subject:RE: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

I don’t understand how you want to predict all cases in which a stateless path computation would differ from an actual TE tunnel setup. As far as I understand, that would require knowing all future network topology changes, i.e., perfectly predicting all upcoming network failures.  Wouldn’t this be a topic for the IRTF?
In any case, my comments on the RPC attributes were not at all about research.

Michael



From: Igor Bryskin [mailto:[e-mail]]
Sent: Saturday, July 28, 2018 5:35 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>; Igor Bryskin <[e-mail]>; [e-mail]; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; [e-mail]; [e-mail]
Cc: Italo Busi <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]>; [e-mail]; Leeyoung <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi Michael,

I think you are talking about bigger, more general problem of the state of the art stateless path computation.  Thank you for bringing this up.
I think you are saying that a TE apllication based on stateless path computations is finicky. It must deal with uncertainties of different kinds of different (hopefully calculable) probabilities. If this is the case, I agree with you. It is time for us to welcome ourselves into the game of hypothesis, evidencies and probabilities and acknowledge that stateless PCE is not just about computing paths on TE graphs, which is albeit non-trivial, but well-understood/documented/taken care of problem. The difficult part is using probablistic cause-evidence-effect graphs to compute the probability of a path returned at time T0 to point/be close to a satisfectory solution when applied at time T1. The latter aspect is not covered by PCEP architecture stateless path computation, and I think it could be a useful addition to PCE YANG work.

Speaking of which, yesterday Adrian suggested the scope for this effort to be roughly what PCEP can do today.With a high probability (;=))  I predict what he will say 1 year down the road. It will sound sometime like this:
"You really did all this? Great! But wait! Why do we need two solutions doing the same thing? Why clients and servers cannot use just PCEP, considering that whule you were busy catching up, Druv has produced some 17 new RFCs? What exactly we are getting out of PCE YANG anyway? PCE requests and responses on the wire are human readable? That's it ?"

This is, at least, I would say. IMHO PCE YANG should be more ambitious and iclude aspects that are not covered yet, such as probablistic path computations mentioned above.

BTW TE tunnel model based path computation today enables (inherently and totally for free) the statefull  path computation according to its original (pre-Crabb) definition: the server mintains states of returned paths rather than of LSPs taking the paths. How about we stop talking about stateless and statefull paths, and start using probabilities computed for path states?


Just my 2c,

Igor
From:Scharf, Michael (Nokia - DE/Stuttgart)
To:Igor Bryskin,[e-mail],Belotti, Sergio (Nokia - IT/Vimercate),[e-mail],[e-mail],
Cc:Italo Busi,[e-mail],[e-mail],[e-mail],Beller, Dieter (Nokia - DE/Stuttgart),[e-mail],Leeyoung,[e-mail],[e-mail],[e-mail],[e-mail],
Date:2018-07-26 12:46:18
Subject:RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

If the path computation is stateless and there can be more than one path computation request in parallel, or dynamic changes in the network, there are *many* reasons why the result of a path computation RPC could be different to the route of the actual tunnel. Otherwise one would have to be able to look into the future to predict network failures and topology changes that affect the path computation.

And a potential difference between RPC and provisioning is a feature, not a bug. If the RPC caller cannot accept that the actual path could be different from the path computation RPC in some cases, outside his control, the RPC caller has to refrain from using a stateless RPC right from the beginning.

My 2 cents

Michael

From: Teas [mailto:[e-mail]] On Behalf Of Igor Bryskin
Sent: Thursday, July 26, 2018 4:50 PM
To: [e-mail]<mailto:[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: Italo Busi <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Leeyoung <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Daniele,
What is the point of path computation request / response if it can not be guaranteed, generally speaking, that a TE tunnel configured on a given network will take the same path as returned via path computation response?
The policies installed in the network are not expected to be known to all clients, but the policies could significantly  influence  on tunnel routing.
All we are saying is that when the same information is passed for tunnel configuration and in path computation request for the tunnel  in questuon, there will be no reason for a path computation return one path, while the actual tunnel, when requested,  taking  a different one.
Note also that all extra parameters we are talking about are optional and could be omitted in path computation RPC if it is known, for example, from experience that they do not affect the actual tunnel routing.

Igor
From:Daniele Ceccarelli
To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS WG,[e-mail],
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS ([e-mail]),Beller<mailto:[e-mail]),Beller>, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma ([e-mail]),Ricard<mailto:[e-mail]),Ricard> Vilalta,[e-mail],Italo Busi,
Date:2018-07-26 05:54:16
Subject:Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi,

>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?

Absolutely no.

Main reasons:

  1.  Policies might not be shared with the MDSC
  2.  Policies may be different from PNC to PNC
  3.  A high number of path computation results will be discarded (stateless path computation is needed also by the MDSC to understand what are the different options to get from a node in a domain to another node in a different domain and possibly through a number of other domains…hence a high number of comination)
  4.  Last but not least simplification.

BR
Daniele

From: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia...com<mailto:sergio.belotti@nokia...com>>
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Italo Busi <[e-mail]<mailto:[e-mail]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]<mailto:[e-mail]>>; Francesco Lazzeri <[e-mail]<mailto:[e-mail]>>; Carlo Perocchio <[e-mail]<mailto:[e-mail]>>; Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>>; Anurag Sharma ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Ricard Vilalta <[e-mail]<mailto:[e-mail]>>; OSCAR GONZALEZ DE DIOS ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Victor Lopez <[e-mail]<mailto:[e-mail]>>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[e-mail]<mailto:[e-mail]>>; Sethuraman, Karthik <[e-mail]<mailto:[e-mail]>>
Subject: draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

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]>