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

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Thu, 26 Jul 2018 08:59:31 +0000

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: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy
[email-masked]<mailto:[email-masked]>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 26 Jul 2018 09:53:25 +0000

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) <[email-masked]>
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <[email-masked]>; [email-masked]
Cc: Italo Busi <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Francesco Lazzeri <[email-masked]>; Carlo Perocchio <[email-masked]>; Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; Anurag Sharma ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; Ricard Vilalta <[email-masked]>; OSCAR GONZALEZ DE DIOS ([email-masked]) <[email-masked]>; Victor Lopez <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>; Sethuraman, Karthik <[email-masked]>
Subject: draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi all,

Sergio Belotti

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 26 Jul 2018 14:49:52 +0000

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,[email-masked],
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS ([email-masked]),Beller, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma ([email-masked]),Ricard Vilalta,[email-masked],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,

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>

Hi all,

Sergio Belotti

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Thu, 26 Jul 2018 16:45:59 +0000

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

Daniele,

Igor
From:Daniele Ceccarelli
To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS WG,[email-masked],
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS ([email-masked]),Beller<mailto:[email-masked]),Beller>, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma ([email-masked]),Ricard<mailto:[email-masked]),Ricard> Vilalta,[email-masked],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,

Absolutely no.

Main reasons:

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 <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Italo Busi <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Francesco Lazzeri <[email-masked]<mailto:[email-masked]>>; Carlo Perocchio <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Anurag Sharma ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ricard Vilalta <[email-masked]<mailto:[email-masked]>>; OSCAR GONZALEZ DE DIOS ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; Victor Lopez <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]<mailto:[email-masked]>>; Sethuraman, Karthik <[email-masked]<mailto:[email-masked]>>
Subject: draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi all,

Sergio Belotti

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 26 Jul 2018 17:37:33 +0000

Hi Michael,

Imagine a client at moment T requests a path computation between points A and B specifying a set of path computation constraints C, and the server returns resulting path P. How should the client interpret the response?

1. At the moment I (the server) have network resources available along the returned path;
2. If you (the client) requested at moment T a tunnel from A to B specifying constraints C, the tunnel would take path P.

The two interpretations are obviously different and therefore have different utility. According to 1. the client may, for example, have no clue that the resources indetified by path P are in fact earmarked for internal nrtwork building, restoration procedures, etc, and hence are only available for internal or privileged clients, but not external general clients, or maybe are simply not covered by the current SLA.

If the client specifies the same parameters for a tunnel and for a path computation for the tunnel, the client can assign a higher Bayesian probability for the interpretation #2, making stateless path computations more useful for the client's TE needs.
What is the point of discovering network resources that are not available for your tunnels ?

Igor

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

My 2 cents

Michael

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 27 Jul 2018 06:29:00 +0000

Hi Igor,

what you are describing is just one of the use cases.

  *   Statefull path computation: I want the request/response to be guaranteed along the same path returned via path computation response.
  *   Stateless path computation: I don't really care about the path, I just want to know that a path exists with given characteristics between A and B.

Here we're talking about stateless path computation. As I said before if a H-PCE needs to find the best path across multiple domains and there are different links/nodes that allow going from one domain to the other, the number of iterations between the H-PCE and the various PCE is huge, hence it should be very simple and in 99% of the cases who cares about an intra domain path? The only thing that cares is that between two border nodes there are X Gbps with given TE characteristics.

Cheers
Daniele

From: Igor Bryskin <[email-masked]>
Sent: giovedì 26 luglio 2018 16:50
To: Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: Francesco Lazzeri <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Carlo Perocchio <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Italo Busi <[email-masked]>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

From: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia..com<mailto:sergio.belotti@nokia..com>>

Hi all,

Sergio Belotti

---

From: Francesco Lazzeri <[email-masked]>
Date: Fri, 27 Jul 2018 08:16:05 +0000

I believe that the main point for deciding whether all the parameters (including name, description and so on) are needed or not for stateless path computation is the adoption of policies.
When I think about policies, I go to the definitions present in RFC3060, where policy information model is described.
According to 3060, basically policies are a (set of) rules where each rule is defined by enabling conditions (boolean expressions that "enable" the policy actions as soon as they become true) and policy actions (the behavior of the policy).
If we introduce this concept in path computation we could think for example to create two policies for a given domain D:

  *   The first one is enabled when the tunnel description contains the string "igor", and the relevant action is avoiding the node X inside the relevant domain.
  *   The second one is enabled when the tunnel description con contains the string "francesco", and the levant action is avoiding the node Y inside the relevant domain.

Let suppose we don't want to use stateless path computation (e.g. the domain is "white", so we have full topology information about it, or, if domain is "black" or "gray",  we just use its abstract connectivity).
We are asking for a new tunnel with description "igor".
Assuming the client (MDSC) knows nothing about those policies, it does path computation end-to-end using the topology information it collected,  and find that the best end-to-end path passing through D.
This path could well use node X: MDSC doesn't care, as it doesn't know that there is a policy installed in D the will ask to avoid that node.
When the end-to-end path needs to be deployed the tunnel requested on D will be created using a path avoding X, because the path creation is done by the controller of the domain D which is aware of and enforces that policy.
But, being this path different from the one computed during the end-to-end path computation, it could have different te-cost, igp-cost, latency and so on, leading to end-to-end figures possibly not in compliance with the end-to-end constraints.
In my view, this is not acceptable.

There are two ways to overcome this issue:

  *   Requesting path computation to the domain D also during end-to-end path computation. This is stateless path computation actually, and means that abstract topology is useless (as we actully are renouncing to use it).
  *   Exposing information about policies to the MDSC (or the client requesting end-to-end path computation). But this is still not enough: abstract topology should be also enhanced in order to take into account the possible policies enforced.
In this example we should have one (or more) abstract connectivity information for ingress-egress of D in case neither "igor" or "francesco" policies are enforced, "igor" is enforced, "francesco" is enforced, "igor" and "francesco" are enforced at once (e.g. asking a path having name "igor and francesco like ietf").
In this case policy information known to MDSC could be limited to the enabling conditions, which should also be referred by the relevant abstract connectivity, of course, so MDSC can select the right connectivity information.

In the past we already had discussions about the scalability of the abstract connectivity model, and basically the stateful model was born because this very reason. The presence of policies makes the scalability issue even more evident, multiplying each abstract link times the number of the combinations of the installed policies in the domain.

So, now we can:

  *   Renounce at all to use policies (or provide for them a definition different from RFC3060, please suggest). In this case not all the attributes present in ietf-te are managed by ietf-te-path-computation are needed.
  *   Use the policies and use only ietf-te-path-computation; this lead to a deep revision of the entire ietf model of the traffic and topology, because abstract connectivity information is no longer needed.
  *   Go ahead with ietf-te plus these policies and face either wrong results or the "dragon" of scalability.

My 2 cents
Francesco

From: Daniele Ceccarelli
Sent: 27 July, 2018 8:29 AM
To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: Francesco Lazzeri <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Carlo Perocchio <[email-masked]>; Leeyoung <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Italo Busi <[email-masked]>
Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi Igor,

Cheers
Daniele

From: Igor Bryskin <[email-masked]<mailto:[email-masked]>>
Sent: giovedì 26 luglio 2018 16:50
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Francesco Lazzeri <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Carlo Perocchio <[email-masked]<mailto:[email-masked]>>; Leeyoung <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti

---

From: Dieter Beller <[email-masked]>
Date: Fri, 27 Jul 2018 17:22:18 +0200

Hi all,

I concur with the comments from Francesco and Daniele below as
well as with those from Michael.

We discussed this issue at length in Montreal after the CCAMP
session and I would like to emphasize again that I am having
reservations about policies being

applied by a path computation engine based on attributes that are
provided as input to path computation, which have absolutely
nothing to do with policy

rules as they were defined for totally other purposes! We called
that hidden policies in our discussion.

Thanks,

Dieter

On 27.07.2018 10:16, Francesco Lazzeri
wrote:

I believe that the main point for deciding
whether all the parameters (including name, description and so
on) are needed or not for stateless path computation is the
adoption of policies.

When I think about policies, I go to the
definitions present in RFC3060, where policy information model
is described.

According to 3060, basically policies are a
(set of) rules where each rule is defined by enabling
conditions (boolean expressions that “enable” the policy
actions as soon as they become true) and policy actions (the
behavior of the policy).

If we introduce this concept in path
computation we could think for example to create two policies
for a given domain D:

The first
one is enabled when the tunnel description contains the
string “igor”, and the relevant action is avoiding the node
X inside the relevant domain.

The second
one is enabled when the tunnel description con contains the
string “francesco”, and the levant action is avoiding the
node Y inside the relevant domain.

Let suppose we don’t want to use stateless
path computation (e.g. the domain is “white”, so we have full
topology information about it, or, if domain is “black” or
“gray”,  we just use its abstract connectivity).

We are asking for a new tunnel with
description “igor”.

Assuming the client (MDSC) knows nothing
about those policies, it does path computation end-to-end
using the topology information it collected,  and find that
the best end-to-end path passing through D.

This path could well use node X: MDSC
doesn’t care, as it doesn’t know that there is a policy
installed in D the will ask to avoid that node.

When the end-to-end path needs to be
deployed the tunnel requested on D will be created using a
path avoding X, because the path creation is done by the
controller of the domain D which is aware of and enforces that
policy.

But, being this path different from the one
computed during the end-to-end path computation, it could have
different te-cost, igp-cost, latency and so on, leading to
end-to-end figures possibly not in compliance with the
end-to-end constraints.

Requesting
path computation to the domain D also during end-to-end path
computation. This is stateless path computation actually,
and means that abstract topology is useless (as we actully
are renouncing to use it).

Exposing
information about policies to the MDSC (or the client
requesting end-to-end path computation). But this is still
not enough: abstract topology should be also enhanced in
order to take into account the possible policies enforced.

In this example we should have one (or more) abstract
connectivity information for ingress-egress of D in case
neither “igor” or “francesco” policies are enforced, “igor”
is enforced, “francesco” is enforced, “igor” and “francesco”
are enforced at once (e.g. asking a path having name “igor
and francesco like ietf”).

In this case policy information known to MDSC could be
limited to the enabling conditions, which should also be
referred by the relevant abstract connectivity, of course,
so MDSC can select the right connectivity information.

In the past we already had discussions
about the scalability of the abstract connectivity model, and
basically the stateful model was born because this very
reason. The presence of policies makes the scalability issue
even more evident, multiplying each abstract link times the
number of the combinations of the installed policies in the
domain.

So, now we can:

Renounce at
all to use policies (or provide for them a definition
different from RFC3060, please suggest). In this case not
all the attributes present in ietf-te are managed by
ietf-te-path-computation are needed.

Use the
policies and use only ietf-te-path-computation; this lead to
a deep revision of the entire ietf model of the traffic and
topology, because abstract connectivity information is no
longer needed.

Go ahead
with ietf-te plus these policies and face either wrong
results or the “dragon” of scalability.

My 2 cents

Francesco

From: Daniele Ceccarelli

To: Igor Bryskin <[email-masked]>;
[email-masked]; [email-masked];
[email-masked]

Cc: Francesco Lazzeri
<[email-masked]>;
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Carlo Perocchio
<[email-masked]>; Leeyoung
<[email-masked]>; [email-masked];
[email-masked]; [email-masked]; Italo
Busi <[email-masked]>

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

Hi Igor,

what you are describing is just one of the
use cases.

Statefull
path computation: I want the request/response to be
guaranteed along the same path returned via path computation
response.

Stateless
path computation: I don’t really care about the path, I just
want to know that a path exists with given characteristics
between A and B.

Here we’re talking about stateless path
computation. As I said before if a H-PCE needs to find the
best path across multiple domains and there are different
links/nodes that allow going from one domain to the other, the
number of iterations between the H-PCE and the various PCE is
huge, hence it should be very simple and in 99% of the cases
who cares about an intra domain path? The only thing that
cares is that between two border nodes there are X Gbps with
given TE characteristics.

Cheers

Daniele

To: Daniele Ceccarelli <[email-masked]>;
[email-masked];
[email-masked]; [email-masked]

Cc: Francesco Lazzeri <[email-masked]>;
[email-masked];

[email-masked]; [email-masked];

[email-masked];
[email-masked]; Carlo Perocchio <[email-masked]>;
Leeyoung <[email-masked]>;
[email-masked];

[email-masked]; [email-masked];
Italo Busi <[email-masked]>

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,[email-masked],

Cc:Francesco
Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia -
DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS ([email-masked]),Beller,
Dieter (Nokia - DE/Stuttgart),Carlo
Perocchio,Leeyoung,Anurag Sharma ([email-masked]),Ricard
Vilalta,[email-masked],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:

Policies
might not be shared with the MDSC

Policies
may be different from PNC to PNC

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)

Last
but not least simplification.

BR

Daniele

From: Belotti, Sergio
(Nokia - IT/Vimercate) <sergio.belotti@nokia..com>

To: TEAS WG <[email-masked]>;
[email-masked]

Cc: Italo Busi <[email-masked]>;
Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>;
Francesco Lazzeri <[email-masked]>;
Carlo Perocchio <[email-masked]>;
Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>;
Anurag Sharma ([email-masked])
<[email-masked]>;

[email-masked]; [email-masked];
Ricard Vilalta <[email-masked]>;
OSCAR GONZALEZ DE DIOS ([email-masked])
<[email-masked]>;
Victor Lopez <[email-masked]>;
Daniele Ceccarelli <[email-masked]>;
Beller, Dieter (Nokia - DE/Stuttgart) <[email-masked]>;
Sethuraman, Karthik <[email-masked]>

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: +39-335761776

Via Energy Park, 20871 Vimercate (MB) ,
Italy

[email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Jul 2018 19:30:12 +0100

I've had several off-line conversations with a number of you where I have
learned a lot about the use cases and desires that are driving this work.
 
However, (there he goes spoiling the effect!) I see nothing in the use cases
that could not be addressed using PCEP (if PCEP were implemented in those
scenarios) so it makes me think that we should generalise (as we should do in
many cases, anyway). That is, we should make our YANG model carry exactly the
same information as a PCEP computation request/response, and for the same
reasons.
 
Some of that information should be part of the base model and some should be in
augmentations, but I don't suppose we should leave stuff out. 
 
The debate about how fields like "tunnel name" are used does not serve us well,
I believe. That in some environments there is information encoded in these
fields so that the PCC can communicate to the PCE the purpose of the path
computation is (of course) a implementation/deployment thing. That it can be
useful to a PCE, looking at the LSPs installed in the network, to match them
against the computations it performed may be incidental to this discussion. My
point is that the parameters are there in PCEP, they may have found various
uses, and the YANG model is supposed to model the PCEP requests.
 
I have yet to be convinced of the desirability of leaving things out. And I
don't see the harm of including stuff.
 
Adrian
 
From: Teas [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: 27 July 2018 16:22
To: Francesco Lazzeri; Daniele Ceccarelli; Igor Bryskin;
[email-masked]; [email-masked]; [email-masked]
Cc: Italo Busi; [email-masked]; [email-masked];
[email-masked]; Carlo Perocchio; Leeyoung;
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation
stateless RPC attributes
 
Hi all,

I concur with the comments from Francesco and Daniele below as well as with
those from Michael.

We discussed this issue at length in Montreal after the CCAMP session and I
would like to emphasize again that I am having reservations about policies being
applied by a path computation engine based on attributes that are provided as
input to path computation, which have absolutely nothing to do with policy
rules as they were defined for totally other purposes! We called that hidden
policies in our discussion.

Thanks,
Dieter

On 27.07.2018 10:16, Francesco Lazzeri wrote:
I believe that the main point for deciding whether all the parameters (including
name, description and so on) are needed or not for stateless path computation is
the adoption of policies. 
When I think about policies, I go to the definitions present in RFC3060, where
policy information model is described. 
According to 3060, basically policies are a (set of) rules where each rule is
defined by enabling conditions (boolean expressions that “enable” the policy
actions as soon as they become true) and policy actions (the behavior of the
policy). 
If we introduce this concept in path computation we could think for example to
create two policies for a given domain D:
 
*	The first one is enabled when the tunnel description contains the string
“igor”, and the relevant action is avoiding the node X inside the relevant
domain.
*	The second one is enabled when the tunnel description con contains the
string “francesco”, and the levant action is avoiding the node Y inside the
relevant domain.
 
Let suppose we don’t want to use stateless path computation (e.g. the domain is
“white”, so we have full topology information about it, or, if domain is “black”
or “gray”,  we just use its abstract connectivity).
We are asking for a new tunnel with description “igor”.
Assuming the client (MDSC) knows nothing about those policies, it does path
computation end-to-end using the topology information it collected,  and find
that the best end-to-end path passing through D. 
This path could well use node X: MDSC doesn’t care, as it doesn’t know that
there is a policy installed in D the will ask to avoid that node. 
When the end-to-end path needs to be deployed the tunnel requested on D will be
created using a path avoding X, because the path creation is done by the
controller of the domain D which is aware of and enforces that policy.  
But, being this path different from the one computed during the end-to-end path
computation, it could have different te-cost, igp-cost, latency and so on,
leading to end-to-end figures possibly not in compliance with the end-to-end
constraints. 
In my view, this is not acceptable.

*	Requesting path computation to the domain D also during end-to-end path
computation. This is stateless path computation actually, and means that
abstract topology is useless (as we actully are renouncing to use it).
*	Exposing information about policies to the MDSC (or the client
requesting end-to-end path computation). But this is still not enough: abstract
topology should be also enhanced in order to take into account the possible
policies enforced. 
In this example we should have one (or more) abstract connectivity information
for ingress-egress of D in case neither “igor” or “francesco” policies are
enforced, “igor” is enforced, “francesco” is enforced, “igor” and “francesco”
are enforced at once (e.g. asking a path having name “igor and francesco like
ietf”). 
In this case policy information known to MDSC could be limited to the enabling
conditions, which should also be referred by the relevant abstract connectivity,
of course, so MDSC can select the right connectivity information.
 
In the past we already had discussions about the scalability of the abstract
connectivity model, and basically the stateful model was born because this very
reason. The presence of policies makes the scalability issue even more evident,
multiplying each abstract link times the number of the combinations of the
installed policies in the domain.
 
So, now we can:
 
*	Renounce at all to use policies (or provide for them a definition
different from RFC3060, please suggest). In this case not all the attributes
present in ietf-te are managed by ietf-te-path-computation are needed.
*	Use the policies and use only ietf-te-path-computation; this lead to a
deep revision of the entire ietf model of the traffic and topology, because
abstract connectivity information is no longer needed. 
*	Go ahead with ietf-te plus these policies and face either wrong results
or the “dragon” of scalability.
 
My 2 cents
Francesco

From: Daniele Ceccarelli 
Sent: 27 July, 2018 8:29 AM
To: Igor Bryskin  <mailto:[email-masked]> <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Cc: Francesco Lazzeri  <mailto:[email-masked]>
<[email-masked]>; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Carlo Perocchio  <mailto:[email-masked]>
<[email-masked]>; Leeyoung  <mailto:[email-masked]>
<[email-masked]>; [email-masked]; [email-masked];
[email-masked]; Italo Busi  <mailto:[email-masked]>
<[email-masked]>
Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation
stateless RPC attributes
 
Hi Igor,

*	Statefull path computation: I want the request/response to be guaranteed
along the same path returned via path computation response.
*	Stateless path computation: I don’t really care about the path, I just
want to know that a path exists with given characteristics between A and B.
 
Here we’re talking about stateless path computation. As I said before if a H-PCE
needs to find the best path across multiple domains and there are different
links/nodes that allow going from one domain to the other, the number of
iterations between the H-PCE and the various PCE is huge, hence it should be
very simple and in 99% of the cases who cares about an intra domain path? The
only thing that cares is that between two border nodes there are X Gbps with
given TE characteristics.
 
Cheers
Daniele  
 
From: Igor Bryskin <[email-masked]> 
Sent: giovedì 26 luglio 2018 16:50
To: Daniele Ceccarelli <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]
Cc: Francesco Lazzeri <[email-masked]>;
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Carlo Perocchio
<[email-masked]>; Leeyoung <[email-masked]>;
[email-masked]; [email-masked]; [email-masked]; Italo Busi
<[email-masked]>
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,[email-masked],
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia -
DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS
([email-masked]),Beller
<mailto:[email-masked]%29,Beller> , Dieter (Nokia -
DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma ([email-masked]),Ricard
<mailto:[email-masked]%29,Ricard>  Vilalta,[email-masked],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> 
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <[email-masked]>; [email-masked]
Cc: Italo Busi <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate)
<[email-masked]>; Francesco Lazzeri <[email-masked]>;
Carlo Perocchio <[email-masked]>; Scharf, Michael (Nokia -
DE/Stuttgart) <[email-masked]>; Anurag Sharma ([email-masked])
<[email-masked]>; [email-masked]; [email-masked]; Ricard Vilalta
<[email-masked]>; OSCAR GONZALEZ DE DIOS
([email-masked]) <[email-masked]>;
Victor Lopez <[email-masked]>; Daniele Ceccarelli
<[email-masked]>; Beller, Dieter (Nokia - DE/Stuttgart)
<[email-masked]>; Sethuraman, Karthik <[email-masked]>
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.

Sergio Belotti

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 27 Jul 2018 20:10:49 +0000

Hi Adrian,

To say that we cannot do a stateless path computation better than what could be done using PCEP today is a bit too bold IMUO. Why then we keep working on PCEP enhancements? ;-)

One example: today, using the TE tunnel model, a client can request (and I know servers that implement) a customized (client controlled) weighted multi-criteria optimization for path selection, specifying any subset of model defined metrics. For example, the client can ask for a best possible compromise between, say, TE e2e cost, delay and following as much as possible a specific explicit path, assigning a relative weight/importance to each of the three criteria. AFAIK this is not possible to do with PCEP today.

Cheers,
Igor

From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, July 27, 2018 2:30 PM
To: 'Dieter Beller'; 'Francesco Lazzeri'; 'Daniele Ceccarelli'; Igor Bryskin; [email-masked]; [email-masked]; [email-masked]
Cc: Italo Busi; [email-masked]; [email-masked]; [email-masked]; 'Carlo Perocchio'; Leeyoung; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

I've had several off-line conversations with a number of you where I have learned a lot about the use cases and desires that are driving this work.

However, (there he goes spoiling the effect!) I see nothing in the use cases that could not be addressed using PCEP (if PCEP were implemented in those scenarios) so it makes me think that we should generalise (as we should do in many cases, anyway). That is, we should make our YANG model carry exactly the same information as a PCEP computation request/response, and for the same reasons.

Some of that information should be part of the base model and some should be in augmentations, but I don't suppose we should leave stuff out.

The debate about how fields like "tunnel name" are used does not serve us well, I believe. That in some environments there is information encoded in these fields so that the PCC can communicate to the PCE the purpose of the path computation is (of course) a implementation/deployment thing. That it can be useful to a PCE, looking at the LSPs installed in the network, to match them against the computations it performed may be incidental to this discussion. My point is that the parameters are there in PCEP, they may have found various uses, and the YANG model is supposed to model the PCEP requests.

I have yet to be convinced of the desirability of leaving things out. And I don't see the harm of including stuff.

Adrian

From: Teas [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: 27 July 2018 16:22
To: Francesco Lazzeri; Daniele Ceccarelli; Igor Bryskin; [email-masked]; [email-masked]; [email-masked]
Cc: Italo Busi; [email-masked]; [email-masked]; [email-masked]; Carlo Perocchio; Leeyoung; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi all,

I concur with the comments from Francesco and Daniele below as well as with those from Michael.

We discussed this issue at length in Montreal after the CCAMP session and I would like to emphasize again that I am having reservations about policies being
applied by a path computation engine based on attributes that are provided as input to path computation, which have absolutely nothing to do with policy
rules as they were defined for totally other purposes! We called that hidden policies in our discussion.

Thanks,
Dieter

So, now we can:

My 2 cents
Francesco

From: Daniele Ceccarelli
Sent: 27 July, 2018 8:29 AM
To: Igor Bryskin <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Francesco Lazzeri <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Carlo Perocchio <[email-masked]><mailto:[email-masked]>; Leeyoung <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Italo Busi <[email-masked]><mailto:[email-masked]>
Subject: RE: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi Igor,

Cheers
Daniele

Daniele,

Igor
From:Daniele Ceccarelli
To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS WG,[email-masked]<mailto:[email-masked]>,
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS ([email-masked]),Beller<mailto:[email-masked]%29,Beller>, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma ([email-masked]),Ricard<mailto:[email-masked]%29,Ricard> Vilalta,[email-masked],Italo<mailto:[email-masked],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,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 28 Jul 2018 15:35:11 +0000

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

My 2 cents

Michael

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti

---

From: Julien Meuric <[email-masked]>
Date: Mon, 30 Jul 2018 16:38:59 +0200

Hi Igor,

FWIW, the PCE WG would welcome your contribution to allocate a
codepoint for a PCEP Object Functions saying "The order of the
attached METRIC and IRO objects express relative preference". If
your implementation doesn't want to go through the standard process,
there are 32768 values "reserved for private use".

Whatever the feature to address, I really wish that multiplying the
number of technical means to express it would increase the number of
implementations supporting it, unfortunately that is not how it
works. Operator's hat on, if your implementation allows to express
your example using a proprietary interface, I'd be happy to write to
piece of code to integrate it into my favorite communication mean.

My 2 cents,

Julien

Jul. 27, 2018 -
[email-masked]:

Hi Adrian,

To say that we
cannot do a stateless path computation better than what
could be done using PCEP today is a bit too bold IMUO. Why
then we keep working on PCEP enhancements? ;-)

One example:
today, using the TE tunnel model, a client can request (and
I know servers that implement) a customized (client
controlled) weighted multi-criteria optimization for path
selection, specifying any subset of model defined metrics.
For example, the client can ask for a best possible
compromise between, say, TE e2e cost, delay and following as
much as possible a specific explicit path, assigning a
relative weight/importance to each of the three criteria.
AFAIK this is not possible to do with PCEP today.

Cheers,

Igor

From:
Adrian Farrel [mailto:[email-masked]]

I've
had several off-line conversations with a number of you
where I have learned a lot about the use cases and desires
that are driving this work.

However,
(there he goes spoiling the effect!) I see nothing in the
use cases that could not be addressed using PCEP (if PCEP
were implemented in those scenarios) so it makes me think
that we should generalise (as we should do in many cases,
anyway). That is, we should make our YANG model carry
exactly the same information as a PCEP computation
request/response, and for the same reasons.

Some
of that information should be part of the base model and
some should be in augmentations, but I don't suppose we
should leave stuff out.

The
debate about how fields like "tunnel name" are used does not
serve us well, I believe. That in some environments there is
information encoded in these fields so that the PCC can
communicate to the PCE the purpose of the path computation
is (of course) a implementation/deployment thing. That it
can be useful to a PCE, looking at the LSPs installed in the
network, to match them against the computations it performed
may be incidental to this discussion. My point is that the
parameters are there in PCEP, they may have found various
uses, and the YANG model is supposed to model the PCEP
requests.

I
have yet to be convinced of the desirability of leaving
things out. And I don't see the harm of including stuff.

Adrian

From:
Teas [mailto:[email-masked]]
On Behalf Of Dieter Beller

Sent: 27 July 2018 16:22

Hi all,

I concur with the comments from Francesco and Daniele
below as well as with those from Michael.

We discussed this issue at length in Montreal after the
CCAMP session and I would like to emphasize again that I
am having reservations about policies being

applied by a path computation engine based on attributes
that are provided as input to path computation, which have
absolutely nothing to do with policy

rules as they were defined for totally other purposes! We
called that hidden policies in our discussion.

Thanks,

Dieter

On 27.07.2018 10:16,
Francesco Lazzeri wrote:

I believe that the
main point for deciding whether all the parameters
(including name, description and so on) are needed or
not for stateless path computation is the adoption of
policies.

When I think about
policies, I go to the definitions present in RFC3060,
where policy information model is described.

According to 3060,
basically policies are a (set of) rules where each rule
is defined by enabling conditions (boolean expressions
that “enable” the policy actions as soon as they become
true) and policy actions (the behavior of the policy).

If we introduce this
concept in path computation we could think for example
to create two policies for a given domain D:

The first one is enabled when the tunnel
description contains the string “igor”, and the
relevant action is avoiding the node X inside the
relevant domain.

The second one is enabled when the tunnel
description con contains the string “francesco”, and
the levant action is avoiding the node Y inside the
relevant domain.

Let suppose we don’t
want to use stateless path computation (e.g. the domain
is “white”, so we have full topology information about
it, or, if domain is “black” or “gray”,  we just use its
abstract connectivity).

We are asking for a
new tunnel with description “igor”.

Assuming the client
(MDSC) knows nothing about those policies, it does path
computation end-to-end using the topology information it
collected,  and find that the best end-to-end path
passing through D.

This path could well
use node X: MDSC doesn’t care, as it doesn’t know that
there is a policy installed in D the will ask to avoid
that node.

When the end-to-end
path needs to be deployed the tunnel requested on D will
be created using a path avoding X, because the path
creation is done by the controller of the domain D which
is aware of and enforces that policy.

But, being this path
different from the one computed during the end-to-end
path computation, it could have different te-cost,
igp-cost, latency and so on, leading to end-to-end
figures possibly not in compliance with the end-to-end
constraints.

In my view, this is
not acceptable.

There are two ways
to overcome this issue:

Requesting path computation to the domain
D also during end-to-end path computation. This is
stateless path computation actually, and means that
abstract topology is useless (as we actully are
renouncing to use it).

Exposing information about policies to
the MDSC (or the client requesting end-to-end path
computation). But this is still not enough: abstract
topology should be also enhanced in order to take into
account the possible policies enforced.

In this example we should have one (or more) abstract
connectivity information for ingress-egress of D in
case neither “igor” or “francesco” policies are
enforced, “igor” is enforced, “francesco” is enforced,
“igor” and “francesco” are enforced at once (e.g.
asking a path having name “igor and francesco like
ietf”).

In this case policy information known to MDSC could be
limited to the enabling conditions, which should also
be referred by the relevant abstract connectivity, of
course, so MDSC can select the right connectivity
information.

In the past we
already had discussions about the scalability of the
abstract connectivity model, and basically the stateful
model was born because this very reason. The presence of
policies makes the scalability issue even more evident,
multiplying each abstract link times the number of the
combinations of the installed policies in the domain.

So, now we can:

Renounce at all to use policies (or
provide for them a definition different from RFC3060,
please suggest). In this case not all the attributes
present in ietf-te are managed by
ietf-te-path-computation are needed.

Use the policies and use only
ietf-te-path-computation; this lead to a deep revision
of the entire ietf model of the traffic and topology,
because abstract connectivity information is no longer
needed.

Go ahead with ietf-te plus these policies
and face either wrong results or the “dragon” of
scalability.

My 2 cents

Francesco

From: Daniele Ceccarelli

Hi Igor,

what you are
describing is just one of the use cases.

Statefull path computation: I want the
request/response to be guaranteed along the same path
returned via path computation response.

Stateless path computation: I don’t
really care about the path, I just want to know that a
path exists with given characteristics between A and
B.

Here we’re talking
about stateless path computation. As I said before if a
H-PCE needs to find the best path across multiple
domains and there are different links/nodes that allow
going from one domain to the other, the number of
iterations between the H-PCE and the various PCE is
huge, hence it should be very simple and in 99% of the
cases who cares about an intra domain path? The only
thing that cares is that between two border nodes there
are X Gbps with given TE characteristics.

Cheers

Daniele

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

Date:2018-07-26
05:54:16

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:

Policies might not be
shared with the MDSC

Policies may be different
from PNC to PNC

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)

Last but not least
simplification.

BR

Daniele

From: Belotti, Sergio (Nokia -
IT/Vimercate) <sergio.belotti@nokia..com>

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

Nokia

M: +39-335761776

Via Energy Park, 20871 Vimercate (MB)
, Italy

[email-masked]

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Mon, 30 Jul 2018 10:50:13 -0400

On 7/27/2018 2:30 PM, Adrian Farrel wrote:
>
> I have yet to be convinced of the desirability of leaving things out. 
> And I don't see the harm of including stuff.
>

I completely agree.
Lou

As contributor.

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 30 Jul 2018 15:02:05 +0000

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

Hi Michael,

Just my 2c,

Igor

My 2 cents

Michael

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

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 30 Jul 2018 20:14:25 +0000

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,[email-masked],Belotti, Sergio (Nokia - IT/Vimercate),[email-masked],[email-masked],
Cc:Italo Busi,[email-masked],[email-masked],[email-masked],Beller, Dieter (Nokia - DE/Stuttgart),[email-masked],Leeyoung,[email-masked],[email-masked],[email-masked],[email-masked],
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

Hi Michael,

Just my 2c,

Igor

My 2 cents

Michael

Daniele,

Igor
From:Daniele Ceccarelli

Hi,

Absolutely no.

Main reasons:

BR
Daniele

Hi all,

Sergio Belotti