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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Fri, 27 July 2018 06:29 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10381130E92 for <teas@ietfa.amsl.com>; Thu, 26 Jul 2018 23:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=H32ww81e; dkim=pass (1024-bit key) header.d=ericsson.com header.b=crYpPmZ0
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqcGNFYj3c-N for <teas@ietfa.amsl.com>; Thu, 26 Jul 2018 23:29:05 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DD6130E3C for <teas@ietf.org>; Thu, 26 Jul 2018 23:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532672943; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WbcwnTa8xWeXHFT4Lz4ccTEV30JQKwBV8Wul2Ez2rUw=; b=H32ww81eH8p10XENU2NvxkGEZZ+MtckraZqbaubrColWk8Li4v4MPiqyEW9sw4nT nvXX4OsFBYF/xRN0A/hkNGsqCeniVSbi8IDVBLf/3YbN3t8UvbAql9RImJtGDXJy TaMTsjpojkkYMiz49Cf3OLtaKgkDcNkgHDKshefXu8s=;
X-AuditID: c1b4fb2d-20bff700000055ff-e8-5b5abbaf709d
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.CF.22015.FABBA5B5; Fri, 27 Jul 2018 08:29:03 +0200 (CEST)
Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 27 Jul 2018 08:29:03 +0200
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 27 Jul 2018 08:29:02 +0200
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 27 Jul 2018 08:29:02 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jE3GqvmJIjCewrJNXxGe4yi90Q+zI03emxoyT0pr/6s=; b=crYpPmZ0aMFKAIELeAOuv6lAP2oTd1+iomvuqaooJ+Anj68UKFzsaTwSmoe5BxL4O6G1vqYV+A2VjqvZkT/i9Y7G31hvaTdST8a8SK4X7cSlhEwhI7ZtcoAjO0Isz0dR99bNYGZ9jQOm9aobF20OI0BDz6uzIlw0Tcet4dQ+RA4=
Received: from VI1PR07MB1680.eurprd07.prod.outlook.com (10.166.143.12) by VI1PR07MB4638.eurprd07.prod.outlook.com (20.177.57.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.4; Fri, 27 Jul 2018 06:29:01 +0000
Received: from VI1PR07MB1680.eurprd07.prod.outlook.com ([fe80::d549:6198:b278:1f69]) by VI1PR07MB1680.eurprd07.prod.outlook.com ([fe80::d549:6198:b278:1f69%4]) with mapi id 15.20.1017.000; Fri, 27 Jul 2018 06:29:00 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "sergio.belotti@nokia.com" <sergio.belotti@nokia.com>, "teas@ietf.org" <teas@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>
CC: Francesco Lazzeri <francesco.lazzeri@ericsson.com>, "Karthik.Sethuraman@necam.com" <Karthik.Sethuraman@necam.com>, "michael.scharf@nokia.com" <michael.scharf@nokia.com>, "vlopez@tid.es" <vlopez@tid.es>, "oscar.gonzalezdedios@telefonica.com" <oscar.gonzalezdedios@telefonica.com>, "dieter.beller@nokia.com" <dieter.beller@nokia.com>, Carlo Perocchio <carlo.perocchio@ericsson.com>, Leeyoung <leeyoung@huawei.com>, "ansha@google.com" <ansha@google.com>, "ricard.vilalta@cttc.es" <ricard.vilalta@cttc.es>, "shiyan49@chinaunicom.cn" <shiyan49@chinaunicom.cn>, Italo Busi <Italo.Busi@huawei.com>
Thread-Topic: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes
Thread-Index: AdQkvNfVJK0UViBSSaelX1MjWeaTXAACJLZwAAqffwAAIJt5cA==
Date: Fri, 27 Jul 2018 06:29:00 +0000
Message-ID: <VI1PR07MB16807711951A9443E70E2428F02A0@VI1PR07MB1680.eurprd07.prod.outlook.com>
References: <DB6PR0701MB27272B2E7AF6970DDF0C50F6912B0@DB6PR0701MB2727.eurprd07.prod.outlook.com>, <HE1PR07MB16753FC8D0D876FE54ADBD51F02B0@HE1PR07MB1675.eurprd07.prod.outlook.com> <etPan.5b59df86.6d3e5bb5.7394@localhost>
In-Reply-To: <etPan.5b59df86.6d3e5bb5.7394@localhost>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [93.38.67.165]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4638; 6:qDOAxceGnNZpahZOgISCo4AP/dvYE5BWX21eCFRBDpd8Dvb9AB7lTO9vuEEjcMwcugdWUajKn2APHIbjUYEwAW+C9Zvs/o3CqWhzbJYqYU1PVbzQ9xv8GWwMeSd3ynpt0usYugDQbhbqUYnB+2MfSZ2qKeh3hbErbvmdO/qbNBn9rIVlCl83OUKdTK8lNHAgOkzKlzyfbXImDRWQEZrSMY2oPNdXpMRuvnJ5UVgEFM4Mj630Cq9+2lLaJQxRwZF3hR35jaRnhoXIaKdLJOchwLeD8EwEBRLBFKMM6s5vlRoROvD+ofoL8lixjOhreP7N56aL7xKZtgVs9F3iLFFghi4XHy5W/OWZF3MI8p37RgLCM/OjY/IpWT1BWyuxpdGGXyv8DJ7Moho4yOp6fUt0vQYDVcRGnUob3DigspzG09TkRiIYA3693JNHbNDQP978vzZce2yzcBAxpA7S2Azh9g==; 5:CrEqLvmcBHd5F7vaVXtSDSIJG7+wQK0K/psONH0ZpGGn1kVQO+5fE5GrbzyXCyX+fyHmvvcQDdCpKUOeKiHlY4bT7dh//j2CC3C8OP5GqulGVm6lMFQuxAWrCYkAQKzG5YY87iS2U3E5nCDyo+WfFy1dbbaXObucHk0ge06Gszc=; 7:MGhLK5V9vF0HR0JVoCsGD2/3ZEwb4kNJ+aiL+f+ovg7v1zCWJ/xLHFYNce639Ohz68I5q8PLVGYQv4L73l6l8XGnL/PcMB5r+MCKEXtar5BOQsv0Sft6NOO2u1vIsFXs9cQx5C5sV8qr29q8XkP/YAgMyJ/K+i6ApO5taiZPx03vUJFHVMHpgN/ttM+w1//z0rFXJn/+8rkwStQYLYpS6zQaaAd7S0GKdG05unyh7FeuNJCKIiTrslxa807w0FTJ
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(366004)(376002)(189003)(199004)(53754006)(7736002)(81156014)(105586002)(54906003)(33656002)(97736004)(476003)(606006)(486006)(53936002)(66066001)(5250100002)(106356001)(790700001)(25786009)(9686003)(6116002)(8936002)(54896002)(11346002)(3846002)(86362001)(55016002)(14444005)(446003)(256004)(6306002)(6436002)(236005)(5660300001)(2501003)(2900100001)(14454004)(26005)(6506007)(76176011)(53546011)(68736007)(4326008)(7696005)(478600001)(966005)(110136005)(6246003)(2906002)(186003)(229853002)(74316002)(81166006)(7416002)(99286004)(2201001)(316002)(102836004)(8676002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4638; H:VI1PR07MB1680.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 89fa36be-e377-4994-b516-08d5f38a3d3e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4638;
x-ms-traffictypediagnostic: VI1PR07MB4638:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-microsoft-antispam-prvs: <VI1PR07MB4638EDA7471039AF19AC1C3AF02A0@VI1PR07MB4638.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(40392960112811)(158342451672863)(166708455590820)(50582790962513)(82608151540597)(109105607167333)(195916259791689)(211936372134217);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB4638; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4638;
x-forefront-prvs: 07467C4D33
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Got/kRJLBGxHv+FKRx9b8fCjCY9ExRQLTpILRSIeI9CHKl39YdEbcfr2QDzEHqE2WR4k7zu5g2ulJyaiFN2UY9m3SENDlnlCgHv70O+VsHBG3+I7lVb4mup/w/c5XJXhgdRQRXGSx9FR/rV7Xq6LfDC+J2yzo6MyFtgPgyZeB27fLzZMgJLxp1nGjeNuYvLD52fq0gj1SrR9pbxtz7FrJAFsp+OFWO2On7lnNtjU+UVTSetMKbJSldP1WwQtUrIgU3i/QA7zb+3W69I0pcRif2iOnHn4pcKhDVrOr3gZrlR5zo8zxcN0OJQWx0NGawI82oTiHOjl2vnlkpEMwYtYmHX1GkUs1PK0c5cSQEJgBOY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB16807711951A9443E70E2428F02A0VI1PR07MB1680eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 89fa36be-e377-4994-b516-08d5f38a3d3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 06:29:00.0828 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4638
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGvTPTdkBrrgXkBIMxNWrEFK1oHI0xuI8LCW8qELXKRNnJDBhc HhBpgKpJVTTYBFlsJCwuQZYGELWCiBGQHSuiqVVBFEhcEBDU9qLx7Tv3P/89/7m5LK3Sy33Y iNgEQYzVRavl7szVvZUnNberQ0JX1D4H7sL3QRl3y9zLcJONWm5ypFrG3dNfkHFXrm3lxlr9 uIGc94jLn3qDOPuogeFMfcMKLiW7iuL0PywMl2XYEjibz/x8DvH6+jSGzy1N5FPrPst4s3mM 4i3GTxT/ytZG8RkTNO+YLKOD3ULc14cL0RHHBHH5hoPuR1u/FVPxA+lU0lT3U5SM0vuRAbmx gFfBhKmKMiB3VoXrEdztbFaQ4juCoY4m5l/R1flM4bSosJmCMcM8p8BgIw227lFEBCMFjrIw 4rAjKBtJow2IZeV4HTisu53nnrgcwU99h8tAYzsDxpJIJ3vgSMgoGqGc7Imj4Ov1R3LCm+BL od3Vz+BFYPmW6kqhxGHwsqhcRob1IkgtP0M7BTe8GtLt/a6LEPYFY3X+9DBvsDlyKLI1BnNN C03YCwbeTskIL4DytgaGsC+05ZxFzgGAaxXQ/rhRQQQtNBTenzbfkUNzi4pwEDxJN1LE0ICg PfumnAh+8KGgiSaJDsFtvWU6RRRc/PBabkRa038BTX9ejMZx0JjDmFyLzoHGqw6GtPhDz+VM OeFlcCNvkCasgawpK/P/eS5SFCEvSZCkmCMrA/wFMeKwJMXF+scKCaXoz+d8WDahsaDiwY1W hFmknqUcLgwJVcl0x6TjMVYELK32VJZ07wtVKcN1x08IYtwBMTFakKxoHsuovZX+RTUhKnxE lyBECUK8IP5VKdbNJxkd5tbOPTljt/11qz11LIL9eFbjsZEROvey+8dTumyrz+/UikGV6wJv 7Cv45bVru0deT+aOaJWhrzegRFdnWXqq3zPrdJe+Ym1XxbbFKDvt/nhoUqAmccY7xZ4lcKsu +YttzYtr2zYPccL8iyMzwx4YS2l7oO/5YD8xIzHgUpLu0kI1Ix3Vaf1oUdL9BjZZ36WYAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9ZKBOiOO6z-D1Vj2NetAFGr81Jo>
Subject: Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 06:29:10 -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 <Igor.Bryskin@huawei.com>
Sent: giovedì 26 luglio 2018 16:50
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; sergio.belotti@nokia.com; teas@ietf.org; teas-chairs@ietf.org
Cc: Francesco Lazzeri <francesco.lazzeri@ericsson.com>om>; Karthik.Sethuraman@necam.com; michael.scharf@nokia.com; vlopez@tid.es; oscar.gonzalezdedios@telefonica.com; dieter.beller@nokia.com; Carlo Perocchio <carlo.perocchio@ericsson.com>om>; Leeyoung <leeyoung@huawei.com>om>; ansha@google.com; ricard.vilalta@cttc.es; shiyan49@chinaunicom.cn; Italo Busi <Italo.Busi@huawei.com>
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,teas-chairs@ietf.org,
Cc:Francesco Lazzeri,Sethuraman, Karthik,Scharf, Michael (Nokia - DE/Stuttgart),Victor Lopez,OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.com),Beller<mailto:oscar.gonzalezdedios@telefonica.com),Beller>, Dieter (Nokia - DE/Stuttgart),Carlo Perocchio,Leeyoung,Anurag Sharma (ansha@google.com),Ricard<mailto:ansha@google.com),Ricard> Vilalta,shiyan49@chinaunicom.cn,Italo Busi,
Date:2018-07-26 05:54:16
Subject:Re: [Teas] draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes

Hi,

>The question is: are there benefits in including in input of Path Computation Request RPC also te-tunnel attributes without any foreseen recommended usage by path computation engine?

Absolutely no.

Main reasons:

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

BR
Daniele

From: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia..com<mailto:sergio.belotti@nokia..com>>
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <teas@ietf.org<mailto:teas@ietf.org>>; teas-chairs@ietf.org<mailto:teas-chairs@ietf.org>
Cc: Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>>; Francesco Lazzeri <francesco.lazzeri@ericsson.com<mailto:francesco.lazzeri@ericsson.com>>; Carlo Perocchio <carlo.perocchio@ericsson.com<mailto:carlo.perocchio@ericsson.com>>; Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; Anurag Sharma (ansha@google.com<mailto:ansha@google.com>) <ansha@google.com<mailto:ansha@google.com>>; ylee@huawei.com<mailto:ylee@huawei.com>; shiyan49@chinaunicom.cn<mailto:shiyan49@chinaunicom.cn>; Ricard Vilalta <ricard.vilalta@cttc.es<mailto:ricard.vilalta@cttc.es>>; OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>) <oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>>; Victor Lopez <vlopez@tid.es<mailto:vlopez@tid.es>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com<mailto:dieter.beller@nokia.com>>; Sethuraman, Karthik <Karthik.Sethuraman@necam.com<mailto:Karthik.Sethuraman@necam.com>>
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
sergio.belotti@nokia.com<mailto:sergio.belotti@nokia.com>