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

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 26 July 2018 09:53 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 7E5151310AF for <teas@ietfa.amsl.com>; Thu, 26 Jul 2018 02:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=InQA0vcd; dkim=pass (1024-bit key) header.d=ericsson.com header.b=NIDMchEU
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 etiGOmUrIr07 for <teas@ietfa.amsl.com>; Thu, 26 Jul 2018 02:53:41 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 EA5511310B3 for <teas@ietf.org>; Thu, 26 Jul 2018 02:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532598818; 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=1uNLqg/qWXBZD/U1B6K+uzTgaWe3Ryb1ScENExUfM+0=; b=InQA0vcdz13cs8sJbMOLXbgG5PrXtq/J5o+kCoHk27z+cODrhzFfAa8F0x6GTZoU pcCLHm7Zm7Abb9LSqtA6oFUll8j1/BwORPISnwAComK7VY2unUTLfK8065gq3Uho K7aoq113rfTdVs7A23qm/tkafg3wiUqPnFF1XnnxnVY=;
X-AuditID: c1b4fb30-5cb039c0000059c2-33-5b599a220c2d
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.E2.22978.22A995B5; Thu, 26 Jul 2018 11:53:38 +0200 (CEST)
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 26 Jul 2018 11:53:28 +0200
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) 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; Thu, 26 Jul 2018 11:53:28 +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=NmCFzpFlsxakFUXRvlfcWUitWu/od08fKVN1bcVavxw=; b=NIDMchEULIWSt5NGLa2fZY/d0YTGBxWikCknr27R5222LyGSAT6TzRNpKmj0lR3B5kSs1aYejJJBNnRV/FHWIO7bdu/lIAGTMW+mUzmcg6lj/fk4ppvzj24H8rIICUdSqxxlxAimxFXWWWEJ6HTI9ZUZuSxPCYBVDyRLN/VMZEU=
Received: from HE1PR07MB1675.eurprd07.prod.outlook.com (10.166.124.141) by HE1PR07MB3290.eurprd07.prod.outlook.com (10.170.246.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.13; Thu, 26 Jul 2018 09:53:26 +0000
Received: from HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::34bd:5cb6:7c10:ef65]) by HE1PR07MB1675.eurprd07.prod.outlook.com ([fe80::34bd:5cb6:7c10:ef65%6]) with mapi id 15.20.0995.014; Thu, 26 Jul 2018 09:53:26 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, "TEAS WG" <teas@ietf.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>
CC: Italo Busi <Italo.Busi@huawei.com>, Francesco Lazzeri <francesco.lazzeri@ericsson.com>, Carlo Perocchio <carlo.perocchio@ericsson.com>, "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "Anurag Sharma (ansha@google.com)" <ansha@google.com>, "ylee@huawei.com" <ylee@huawei.com>, "shiyan49@chinaunicom.cn" <shiyan49@chinaunicom.cn>, Ricard Vilalta <ricard.vilalta@cttc.es>, "OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.com)" <oscar.gonzalezdedios@telefonica.com>, Victor Lopez <vlopez@tid.es>, "Beller, Dieter (Nokia - DE/Stuttgart)" <dieter.beller@nokia.com>, "Sethuraman, Karthik" <Karthik.Sethuraman@necam.com>
Thread-Topic: draft-ietf-teas-yang-path-computation-02 : path computation stateless RPC attributes
Thread-Index: AdQkvNfVJK0UViBSSaelX1MjWeaTXAACJLZw
Date: Thu, 26 Jul 2018 09:53:25 +0000
Message-ID: <HE1PR07MB16753FC8D0D876FE54ADBD51F02B0@HE1PR07MB1675.eurprd07.prod.outlook.com>
References: <DB6PR0701MB27272B2E7AF6970DDF0C50F6912B0@DB6PR0701MB2727.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB27272B2E7AF6970DDF0C50F6912B0@DB6PR0701MB2727.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.0.200.100]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB3290; 6:Qck2bJTmpVoLwKCHnUBmuY8KyFcl5F1X5RDpOMMmqCKfPFUdJyL4ihgIQLpIOimNS0uFAg74jXcI62GteEdfDD+7AuP7slEwFRvlbw5iivVr7RJeuVxopnbBLvkuhSMUXPE4H5+X+/eMaFaXxV0ArBsHxJoo39Rw0qahUbR37nWvc0flUI3u26zVRN2iIfqA/h0BOEvNNLvVpvQJT3pI4Ocbrwawb2bXh+Czbgmbn+f1AmbHqkDDwRV+NWf3uOaf8JPgWe5aBPVKLeWqxNWUvqn7/AMdRBAIz8mcFstvR/j19LKgKGbd/8NUbHWypE+ShGccgE3LsoBTJtWzmHNMj9mbbolngEpXi3mFBgOiPOa/I7CeBoN6H1j6VafcVzrC/lC4MBasKf3rd9rx/vGjUaXdBd5I1Rf2oyI9x93LFFYlLb/jmND8DxYEnS2DQ4ylitp/qjpagaXx40DblUV5qQ==; 5:rPys6Kg3kkiS/PKujUCMmBLwRrygremjPtOSFCtoCViIY0uwgAowu8uhndVqzWhDisLMhMKx48mRspSfYVSSxysWsBK86kBmuod2ymaqS1V++q4uGBOTGtxu0tgi5L6K2jFlCvTU5is7anE8/u5Pd8JMQWA4txlY6ty5Pa4nrRo=; 7:lzk/hFXHaTBV6dXG+TfHnRVQp3QuFixi+rLc3HC+Lob0tO71PN5XBoNpjbSJYDJqpFh9HtJDkjuP4N/BGAUQTsnh/ibYKy3ITimat3tpYbjmR6d/we4/RWLPzDQav82Y+ltJSKdbzGzMHXZQDTHF8XUhTiXP3wF3b/9PkqJKMf3nptfdZf9x1PHet7oDkzGegOfTUdEY/fAfNqx2cYFrzRCPpe+omIdnuhFvaTnyyzEq+XebIHOYYCqrZThwdBn7
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(136003)(396003)(346002)(189003)(199004)(53754006)(446003)(74316002)(97736004)(66066001)(5250100002)(54896002)(6306002)(9686003)(296002)(110136005)(2501003)(2906002)(236005)(4326008)(7416002)(33656002)(5660300001)(14454004)(316002)(54906003)(81156014)(606006)(14444005)(11346002)(256004)(68736007)(7736002)(81166006)(8676002)(8936002)(186003)(86362001)(99286004)(7696005)(476003)(2900100001)(76176011)(44832011)(966005)(229853002)(478600001)(6506007)(26005)(106356001)(6246003)(486006)(53936002)(3846002)(25786009)(55016002)(6436002)(790700001)(53546011)(105586002)(6116002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3290; H:HE1PR07MB1675.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 0f9b4f79-3a65-41ae-2d97-08d5f2dda1e2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3290;
x-ms-traffictypediagnostic: HE1PR07MB3290:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-microsoft-antispam-prvs: <HE1PR07MB3290A7A852B40ED0FC122716F02B0@HE1PR07MB3290.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)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:HE1PR07MB3290; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3290;
x-forefront-prvs: 07459438AA
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: sbLuJSq+T1zpZ4qIvNV7ZOyK/SHHyzReS0SUssJxmx+idGUv/nTg9NLWCSDHCF2ta6QoQ0n/ff6ptixdKc0SjX1U3ln5RQVL698xjjXdD/uH9DeFA2YVZctY8tAWNZJHDDSSROtdjsuR/hMFqwe185i8Vqa6ZS4K0VT9wkEFexgUivxmv/1bswHlw3UF6u9ebpME99c5p1FrZ6qzQrRc2qE3UkaIb3yq4kXP8kF75onTybmkbfiKtv9ncszIQ+ZDXnnEwG5yxmPOXV75tnwm+pRMpXdHvVxRwOCiUumiq2D6xfUR05a0ssLi3rBVXqsfBqfo1K9gollbMdExlah7OCtrja7hoYKO/hDCTIVz5SY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB16753FC8D0D876FE54ADBD51F02B0HE1PR07MB1675eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f9b4f79-3a65-41ae-2d97-08d5f2dda1e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 09:53:25.8879 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3290
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTcRjH+93dttto9WsqPVRSjUKyNJWoo/cg6YiMoKTMpE291Jxam/mS RCatcA5bZaWr2NSVqJCiVjNf0qWMgjINQa20UhRTUypNES3PW+B/n+/3eX7PGz+aVGSIV9Ax 8YmcNl6tUYplVN6J58k+SnNIqN940VLm5sSQiHli+0QxM2M1IqZOf1PETLV6M4OWfsQUzH5B zLc/Booxd49KmIyHLwhGP2mnmFzDfiZrvFSyV87mjBgRq2++TrHWigvs1aYREWuzTRGs3TRM sJ+72gg2c5pk+2aqyCPSk7KdkZwmJonTbt6tkkU33y0UnWstRyndjfJ0VGFGBiSlAW+BdKdB YkAyWoGbEZT1/nCJCQS9I+8IQdgIaLB2zwsKm0gYttYhIXKbgAx9ByWIbwiMnxrmBE2L8Xbo cxzifXd8G8Gb/i9iXpDYLIKP1v759m44Anpu/SZ4dseR0Pn2ukTgAHAOlBJ8IQqvh6HeszzK 8SnonPDhMxRYBVnOnyTPUqyG7GejYp4R9gRTTcF8dRIvh64+CyEsisFW20IK7AGDvbMigdfC +xKzK8cT2ixZ84sBrpeApeaK60r+4Cx+SQqBMjF8thS7XgdB5bVascBOBJPZXgJ7w9Onvyhh onAo09tdHWLh78CMq0MLgvQPdciE/MwLphU4AcaqOyme5XgZvM7rowTfFzru5IgF3giP84dI gX0gd9ZBLfStSFKCPHScLjwuKiDAl9PGROh0CfG+8VxiBZr7mY1V0352NDiwz4EwjZSL5fXG kFCFSJ2kS41zIKBJpbu86MycJY9Up17ktAmntRc0nM6BVtKUcrmcOVx5UoGj1IlcLMed47T/ owQtXZGOwrmengPqZZfanygCvRplydYlHcodYcOBOcqmr0HZoSmjCtNkXGa1Ndl3Ys9jzfpH Gp/8P7umXl07VrJqcX4qkbbt8siu4DVbgw6ufGA0bvLwV4Wts9+LLfyesgnczh9tnd4QMn5g SpWmutQwcLS9OFi6Z3V54qIbtuHjixLuczPdaUpKF6329ya1OvU/5iuZdpUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/PqCy_oUlQVUI-FSPCr9LqaN8Qg4>
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: Thu, 26 Jul 2018 09:53:45 -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) <sergio.belotti@nokia.com>
Sent: giovedì 26 luglio 2018 11:00
To: TEAS WG <teas@ietf.org>rg>; teas-chairs@ietf.org
Cc: Italo Busi <Italo.Busi@huawei.com>om>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>om>; Francesco Lazzeri <francesco.lazzeri@ericsson.com>om>; Carlo Perocchio <carlo.perocchio@ericsson.com>om>; Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>om>; Anurag Sharma (ansha@google.com) <ansha@google.com>om>; ylee@huawei.com; shiyan49@chinaunicom.cn; Ricard Vilalta <ricard.vilalta@cttc.es>es>; OSCAR GONZALEZ DE DIOS (oscar.gonzalezdedios@telefonica.com) <oscar.gonzalezdedios@telefonica.com>om>; Victor Lopez <vlopez@tid.es>es>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>; Beller, Dieter (Nokia - DE/Stuttgart) <dieter.beller@nokia.com>om>; Sethuraman, Karthik <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>