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

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Thu, 03 November 2016 19:16 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3A11296A5; Thu, 3 Nov 2016 12:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 B5eoBhYaRY2F; Thu, 3 Nov 2016 12:16:41 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A4DD1129617; Thu, 3 Nov 2016 12:16:40 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EF8C6B420E913; Thu, 3 Nov 2016 19:16:34 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA3JGbLl015847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2016 19:16:38 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA3JGbg0007164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2016 20:16:37 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 3 Nov 2016 20:16:37 +0100
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: Leeyoung <leeyoung@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Igor Bryskin <Igor.Bryskin@huawei.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: AQHSNdciiwbM2GAvW0axSr1lXYwl+KDHRCFw///xlACAABFawIAAQmiAgAAWg9A=
Date: Thu, 03 Nov 2016 19:16:36 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <AM2PR07MB09943987D6E27931F8C7CF3EF0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <0C72C38E7EBC34499E8A9E7DD007863908F0EF32@dfweml501-mbx> <655C07320163294895BBADA28372AF5D48B5BB53@FR712WXCHMBA15.zeu.alcatel-lucent.com> <AM2PR07MB0994C0B4EB099666B97844C0F0A30@AM2PR07MB0994.eurprd07.prod.outlook.com> <655C07320163294895BBADA28372AF5D48B5BC01@FR712WXCHMBA15.zeu.alcatel-lucent.com> <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CC9D2@dfweml501-mbx>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48B5C82FFR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/_UfZzbu6XRtkj3CiQPmbkYti3EU>
Subject: Re: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2016 19:16:45 -0000

Isn't the intention of defining "compute-only tunnels" to create state in the controller, but not to signal them? If the tunnel should be signaled and resources shall be allocated, why not just configure a vanilla tunnel? Uses cases seem to exist for both variants, and both can be encoded in YANG. Is there anything I miss here?

Michael


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

Hi Michael,

I think I am with you on your point. If we use rpc, it is clear. On the other hand, if we were to use "stateful compute-only" it seems that the system/controller has to keep the state of the paths somewhere which is not YANG datastore. My understanding is that YANG datastore is updated only when the path is signaled and resource is allocated. Would this give the system/controller additional burden to keep the "interim" state?

Young

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Scharf, Michael (Nokia - DE)
Sent: Thursday, November 03, 2016 8:58 AM
To: Daniele Ceccarelli; 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: [CCAMP] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Maybe I miss something, but to me, the domain controller either computes a path stateless, which can be modeled in YANG in an RPC. Or the domain controller computes a path, stores state, and provides access to the result in the YANG datastore. In the latter case, whether resources are allocated, or whether the NEs get actually provisioned, is an orthogonal question.

As a side note, I am not sure of I would call a domain controller or an NMS a PCE. Path computation is only a subset of the functions of a domain controller.

Michael



From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, November 03, 2016 2:49 PM
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