Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Thu, 03 November 2016 14:42 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 B06E4129A89; Thu, 3 Nov 2016 07:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com
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 xL_6GB8O3-7v; Thu, 3 Nov 2016 07:42:38 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7F622129A84; Thu, 3 Nov 2016 07:42:37 -0700 (PDT)
X-AuditID: c1b4fb25-d35ee98000001e3e-ff-581b4cdbdb54
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 58.84.07742.BDC4B185; Thu, 3 Nov 2016 15:42:35 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 15:42:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VRZSp5GZpAGlhWkPlfIyWJVFz7eXdQd+hquGcFyBdN0=; b=IKtisCKrnqIOJXJky2tQEQbonFPgwLFsUVvAzrl8YZ6dflCky/PQ6A7uGiZ4IZupW79sV0M5Xgs8UWz65K0oc+8fc1UXZuen8USi31GTAqgi3v8mw3wiNNvhmUaCfju0JJDBQvuVKzXjfT05qf/ROSETwMm8p83vuvHSWI221OE=
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.7; Thu, 3 Nov 2016 14:42:10 +0000
Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 14:42:10 +0000
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Thread-Index: AQHSNdcqQOP7TAHGy0yJ/Pr4YL6w56DHRTsAgAAAf9CAAAS6gIAAAJSQgAAIIgCAAAEokA==
Date: Thu, 03 Nov 2016 14:42:10 +0000
Message-ID: <AM2PR07MB0994A71F7FD6A771C23853A4F0A30@AM2PR07MB0994.eurprd07.prod.outlook.com>
References: <AM2PR07MB09943987D6E27931F8C7CF3EF0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <AM2PR07MB0994C0B4EB099666B97844C0F0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF96@dfweml501-mbx> <AM2PR07MB0994F166F428A91D580356A3F0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx>
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908F0EFE3@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com;
x-originating-ip: [151.0.200.100]
x-ms-office365-filtering-correlation-id: 8910efd2-2137-4d4d-f264-08d403f797c6
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 7:cgw389NkduClgLnHL6he6Ws/IMSms3s5ihbyULK8+endz0SLN0bXgRJYsB4QFQbRwYbZHJcT7ebrd1KSkp118+LgRsouHZi1Bl85IfFtZwIInDG1Ep0ILaUlou4tFK6vXUCSdFITNszzVPnmeC0QUUNi4bnyxttWo5jg3zvHgbCggTxZ+GItcVAEt1ruHYjrssaY5Kkl7ME6DZVZHcsF3QsXVU+H4vek5LeXVEmJjJUVJv/oxBloOr/FGrsCQa2x0XkAht0fzgMZrTFvivvJRhhykra3E0J3jnoncGUcylERqXQLqgu20A36fk6UAFtczs1PIFHpURKyTImmpHsHadVS07Qd1VhYyGE2lCYhWL4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996;
x-microsoft-antispam-prvs: <AM2PR07MB099630ED50C2707891CAF089F0A30@AM2PR07MB0996.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(50582790962513)(82608151540597)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996;
x-forefront-prvs: 011579F31F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(199003)(2900100001)(122556002)(15975445007)(77096005)(50986999)(86362001)(33656002)(19625215002)(220493001)(101416001)(66066001)(16236675004)(92566002)(76176999)(586003)(106356001)(106116001)(54356999)(3846002)(19300405004)(2906002)(105586002)(790700001)(102836003)(6116002)(19617315012)(93886004)(230783001)(68736007)(76576001)(19580395003)(19580405001)(81156014)(81166006)(8676002)(8936002)(9686002)(3280700002)(2501003)(5002640100001)(74316002)(7736002)(7906003)(7846002)(7696004)(189998001)(87936001)(107886002)(11100500001)(5660300001)(2950100002)(10400500002)(97736004)(3660700001)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM2PR07MB0994A71F7FD6A771C23853A4F0A30AM2PR07MB0994eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 14:42:10.3054 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+845Ox5Hg6+l+Xr5x3VBjJlmxLoXpglpCamZBDbz4H0bm4n6 R2k5TSm0qaESqTGzzTISKYlUmpqXqKUuvCUazijzVmGmpuZ2Fvjf7/meh+/93oePIYWtPBcm XpbCKmXSJBHNp8oiXriLh4NcI7yLbh6QmO8NUJKVLh/JYo+nZKhax5NcHx2wk6j/NFLH6cDs tmleoFa7SASODPUSIWQk/3AMmxSfyir3HL3Ej+utNSLF+E+U1jf3i8pEc4MoH9kzgPdBd+0y mY/4jBDXIdBOaxAnOtbF3H3KIih8m4SVwWaKc4oIGFt6y+NEO4KWYQ2djxiGxgfBbAiynDvg LALm6/Ioy5CtOAxaGmqt7IBDYUH93I7jcDB8HrY+hMI7wJA1Zs0I8EVYMzUQ3IAcCop7OkmL YY/9oWOynrAwwttgofuxlUnsBEPmCoLbCIP2lZHk2BG+ja/yuHw0PFU32jLu8EFfbuNgmHmg tq4GuJKEtr/9dpwRALN3hmw1JUJFgdHGCTBfukRz3IigSuPBsRs86pqguYue0VC20GmdLMQs 1DxRI64KFxgx5dnYDb5+auIVIo/yDUuUrzdJYjn01gSXW8vYAl1lZoqLeMFASTHN8W54WPWd 5FgMpasGauN5JbLTI0cVq4pOjt3r68Uq4y+rVHKZl4xNqUfrX+t1w/LORtQ3dcKAMINEmwWK NecIIU+aqkpPNiBgSJGDoOm0a4RQECNNz2CV8ijllSRWZUCuDCVyEuzXjZ4X4lhpCpvIsgpW +d8lGHuXTBR4rSTBlDoVWjDmdu5G16ZmU60ud2E2TNHj7jlhPEImr32J7jmWrN+VIQ7puJqm i/QP/jh31k+6nNt0Urv9TP+h9tZ5Q1IsrY6qHjRnvwtf1Gx5c6FJJ5+5tdavZ3BW5GRGQE5I uKYuUfzyd/xdn/eY0Cukp/yUpPeq83Ch7w8RpYqT+niSSpX0H6voKp5WAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/RRkaPDKj9yxIC_s9ZXmD-WruSfw>
Subject: Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Nov 2016 14:42:41 -0000

Makes sense.

Cheers
Daniele

From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: giovedì 3 novembre 2016 15:35
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>; CCAMP (ccamp@ietf.org) <ccamp@ietf.org>; pce@ietf.org; TEAS WG (teas@ietf.org) <teas@ietf.org>; mpls@ietf.org
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

For the client to keep returned by the provider path state means requesting from the provider periodic path re-computations.  Provider can re-evaluate previously returned path in an event driven way (e.g. reacting on TED change affecting one of the path's links).

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Understood the concept. It is clear but I'm still struggling with its usefulness. What you call statefull and stateless is with respect to the domain controller, but I see the statefullness and stateless of the paths an higher level controller issue and fair enough to have the stateless concept in the domain controller.
In other words if the higer level controller wants to keep the state of the path why doesn't it simply do that instead of demanding it to the domain controller? Because if should be made available also to someone else?

Cheers
Daniele


From: Igor Bryskin [mailto:Igor.Bryskin@huawei.com]
Sent: giovedì 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com<mailto:michael.scharf@nokia.com>>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

HI Daniele,

A client may ask for a path not to be used immediately (e.g. to present as an abstract link to its own client, in some failure restoration scheme or as a part of disaster recovery network topology re-configuration). In this case the client would want to know at least  if/when the path has stopped being feasible any longer or (ideally) a better path is available.

Igor

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Can you please explain what the "stateful compute-only" stands for I don't understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and then forget about it or I ask to compute and provision it. I don't understand the value of asking for it and remembering about it.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <Igor.Bryskin@huawei.com<mailto:Igor.Bryskin@huawei.com>>; Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>) <ccamp@ietf.org<mailto:ccamp@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>) <teas@ietf.org<mailto:teas@ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

We have discussed this before. From an implementer's perspective, the two clean solutions to the problem seem to either stateful "compute-only" tunnels or a stateless RPC.

Michael


From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (ccamp@ietf.org<mailto:ccamp@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; TEAS WG (teas@ietf.org<mailto:teas@ietf.org>); mpls@ietf.org<mailto:mpls@ietf.org>
Subject: [ALU] [mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

>From the draft:

6.    YANG Model for requesting Path Computation


   Work on extending the TE Tunnel YANG model to support the need to
   request path computation has recently started also in the context of
   the [TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>] draft.

   It is possible to request path computation by configuring a
   "compute-only" TE tunnel and retrieving the computed path(s) in the
   LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>].

   This is a stateful solution since the state of each created
   "compute-only" TE tunnel needs to be maintained and updated, when
   underlying network conditions change.

   The need also for a stateless solution, based on an RPC, has been
   recognized.


   The YANG model to support stateless RPC is for further study.





IB>> Please, note, that in the TE Tunnel model we consider the COMPUTE_AND_FORGET mode. We also consider the concept of path computation action to be defined under the TE tunnel node. All this is to facilitate stateless path computations.

Cheers,
Igor