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

"Adrian Farrel" <> Fri, 27 July 2018 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E822D130EAB; Fri, 27 Jul 2018 11:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eNXAPUwMRvWD; Fri, 27 Jul 2018 11:30:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54968128CF3; Fri, 27 Jul 2018 11:30:44 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w6RIUI1e031453; Fri, 27 Jul 2018 19:30:20 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 7C4502203C; Fri, 27 Jul 2018 19:30:18 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 6538D2203A; Fri, 27 Jul 2018 19:30:18 +0100 (BST)
Received: from 950129200 ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id w6RIUEsF027373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2018 19:30:15 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Dieter Beller'" <>, "'Francesco Lazzeri'" <>, "'Daniele Ceccarelli'" <>, "'Igor Bryskin'" <>, <>, <>, <>
Cc: "'Italo Busi'" <>, <>, <>, <>, "'Carlo Perocchio'" <>, "'Leeyoung'" <>, <>, <>, <>, <>
References: <> <> <etPan.5b59df86.6d3e5bb5.7394@localhost> <> <> <>
In-Reply-To: <>
Date: Fri, 27 Jul 2018 19:30:12 +0100
Message-ID: <029701d425d7$dcbf7c00$963e7400$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01D425E0.3E8E6B50"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--15.183-10.0-31-10
X-imss-scan-details: No--15.183-10.0-31-10
X-TMASE-Result: 10--15.183100-10.000000
X-TMASE-MatchedRID: pS5owHKhBO1md03XlK+nb/lZlPYYWH6dUAjrAJWsTe/jsTquy0JRizOK rPIVSxe2k4KJBWIE+4MZErKS8hD0uI9N2QpGv06v04Rmz/agfdwLBPYMfuIybsi9AjK6C8p1shc sL06e2Sr4YDaIYfThnndN2CP1rXVXLPXoRet+67qeEco05hssvv+o/UjIXF0CVfOB6z8Qn2yBuL DzzkmS1/sYnAkzy/yrbiIWvDi8KmjhuaNyIeP+c9xajlW+zwxCidh5w4ZtoM/+7KZICEbEsj68h GDRXO35t0xwx3PGLb5i64QZPp772ZhSzQYumcTHjNvYZHpO13d+S5m2/8VLmgQLUvnBZL2KaDyg OwnODwydZmruGc01ch8vG9+Zr2igGh6744KLCtImtTGirqG/D0+fvhSDkQoQ3M5CjuZOAD6GGlx lkudxLa6R5pfVEoaM5PNTmewftGTtzSKzUmDUV8NrWpY804TGdSHY4x0UjQlpO7QVkWWTtydFkU CNhBu0yMCUhFRgYkaSUYFHkOz9eVrBy2tJuT9N84dsinZ5e1gsmbwU4T1YtVfXgfL55invwsg3F DXiD8KYszJ0dUKP+4WaXR7PGXA6Aef6h21z2pAdxBAG5/hkW0bbuL7Y47c0ieonMNhzMRDF7lcF sZf9TiWlVyW+MkkM5n0TYrqwYc/UUmE1Fbl+x5D6BbDN9+jOGY9Y+ATae1wuQrPsfsGsmMbbZbr NnnQMug2mZ3usJGQGETFKcwVvwRo/F4wweNBuUBxCs5ulK12+F//Mn3a2w0mDyxNPdHMX75aal1 LPDC4J6hkZu8RXS23MYtYck34dKXdVF04D0smeAiCmPx4NwGmRqNBHmBvenFK7VE/xL0lFGCd0S 0NCsjOsFtuvLjhaEjvomWEe36J8veqgsJ9zaFDFnv+uObj6S4W/MRhJ1X4=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jul 2018 18:30:50 -0000

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
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.
From: Teas [] On Behalf Of Dieter Beller
Sent: 27 July 2018 16:22
To: Francesco Lazzeri; Daniele Ceccarelli; Igor Bryskin;;;
Cc: Italo Busi;;;; Carlo Perocchio; Leeyoung;;;;
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.


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
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
*	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
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
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
From: Daniele Ceccarelli 
Sent: 27 July, 2018 8:29 AM
To: Igor Bryskin  <> <>om>;;;
Cc: Francesco Lazzeri  <>
<>om>;;;;;; Carlo Perocchio  <>
<>om>; Leeyoung  <>
<>om>;;;; Italo Busi  <>
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.
From: Igor Bryskin <> 
Sent: giovedì 26 luglio 2018 16:50
To: Daniele Ceccarelli <>om>;;;
Cc: Francesco Lazzeri <>om>;;;;;; Carlo Perocchio
<>om>; Leeyoung <>om>;;;; Italo Busi
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation
stateless RPC attributes
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.

From:Daniele Ceccarelli
To:Belotti, Sergio (Nokia - IT/Vimercate),TEAS WG,,
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia -
DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS
<,Beller> , Dieter (Nokia -
DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma (,Ricard
<,Ricard>  Vilalta,,Italo Busi,
Date:2018-07-26 05:54:16
Subject:Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation
stateless RPC attributes
>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.
From: Belotti, Sergio (Nokia - IT/Vimercate) <> 
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <>rg>;
Cc: Italo Busi <>om>; Belotti, Sergio (Nokia - IT/Vimercate)
<>om>; Francesco Lazzeri <>om>;
Carlo Perocchio <>om>; Scharf, Michael (Nokia -
DE/Stuttgart) <>om>; Anurag Sharma (
<>om>;;; Ricard Vilalta
( <>om>;
Victor Lopez <>es>; Daniele Ceccarelli
<>om>; Beller, Dieter (Nokia - DE/Stuttgart)
<>om>; Sethuraman, Karthik <>
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 . 
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
M: +39-335761776
Via Energy Park, 20871 Vimercate (MB) , Italy