Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes---> Yang model vs. PCEP alignment

Julien Meuric <> Thu, 27 September 2018 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0125B127148; Thu, 27 Sep 2018 09:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zMwagoO5cdoo; Thu, 27 Sep 2018 09:05:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 11991130E16; Thu, 27 Sep 2018 09:05:22 -0700 (PDT)
Received: from (localhost []) by localhost (Postfix) with SMTP id 101745615A9; Thu, 27 Sep 2018 18:05:04 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id F26A856138F; Thu, 27 Sep 2018 18:05:03 +0200 (CEST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 33A261812D2; Thu, 27 Sep 2018 18:05:06 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 155B5181285; Thu, 27 Sep 2018 18:05:06 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.408.0; Thu, 27 Sep 2018 18:05:05 +0200
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <>
CC: "" <>, "" <>, Jonathan Hardwick <>
References: <>
From: Julien Meuric <>
Organization: Orange
Message-ID: <>
Date: Thu, 27 Sep 2018 18:05:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/html; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes---> Yang model vs. PCEP alignment
X-Mailman-Version: 2.1.29
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: Thu, 27 Sep 2018 16:05:25 -0000

Hi Sergio,

Sorry for my late feedback (and thanks for the reminder).

Thank you for splitting the problem space, there are indeed different sub-cases:

1. To quote Adrian, leavings things out would be a pity and there is no obvious harm in including, so I would favor the alignment of this WG document on the capabilities defined in PCEP.

2. Those missing features could be relevant to be submitted to the PCE WG as a (set of) draft(s) defining corresponding extensions to PCEP. Their usefulness would need to be discussed within the PCE WG, as part of the usual working process.

3. We enter the tricky kind. I believe these need to be discussed on a case by case basis. (E.g., how large is the misalignment on feature X? How complex would be a patch on feature Y with an optional capability so as to reflect the PCEP way?)

4. The latter kind sounds like a reasonable gap. The alignment goal is not have PCEP and NETCONF fully mimicking each other, all the more as you mention some reconciliation solution from the implementation perspective.

Now, diving down to your example, it seems to combine both 1. and 2.:
- For 1., I think some existing path calculation engine implementations would appreciate that the Yang module allow to express the constraints in a PCEP way.
- For 2., PCEP has SVEC, METRIC and Objective Functions: we probably need to discuss in details, but I am pretty sure a similar feature can be supported; it may be a matter of providing the missing documentation (i.e., an applicability document), or requesting a couple of new codepoints.

Thanks for considering the goal of limiting the discrepancies,


Aug. 09, 2018 -

Hi Julien,

we think your reply, in line with Adrian’s desire, is in favor of an alignment between PCEP and Yang models.

We have found 4 possible types of differences between YANG models and PCEP:

  1. Features defined in PCEP but missing in YANG models

  2. Features defined in YANG models but missing in PCEP

  3. Features supported by both but in different and incompatible way

  4. Features supported by both but with some differences which appear more inherent to protocol characteristics of NETCON/RESTCONF with PCEP which can be reconciled from an implementation perspective.

We can prepare a detailed list of the differences if you think it is valuable.

A typical case in which a feature is differently implemented on the YANG model and PCEP is related to the support of mandatory/optional (relaxable) constraints.

PCEP offers the possibility to decide whether a constraint (almost any object actually in PCEP) must be considered by the path computation or may be ignored. TE-tunnel model has a different mechanism to provide similar feature with an ordered list of paths computed with different constraints and then the possibility to choose one or the other depending of optimization purpose.

Do you think we need to reconcile this difference?


Carlo, Francesco, Sergio



From: Julien Meuric <>
Sent: Monday, July 30, 2018 4:39 PM


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,


Jul. 27, 2018 -

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.






From: Adrian Farrel []
Sent: Friday, July 27, 2018 2:30 PM


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.




From: Teas [] 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.


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




From: Daniele Ceccarelli
Sent: 27 July, 2018 8:29 AM


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


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

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




>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


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" rel="nofollow"> .


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




Teas mailing list" rel="nofollow">