Re: [Teas] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
Igor Bryskin <Igor.Bryskin@huawei.com> Fri, 04 November 2016 13:07 UTC
Return-Path: <Igor.Bryskin@huawei.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 8BA1E12940C; Fri, 4 Nov 2016 06:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level:
X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, 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 6kqWe-a0wqYI; Fri, 4 Nov 2016 06:07:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF811293DF; Fri, 4 Nov 2016 06:07:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZR58228; Fri, 04 Nov 2016 13:07:06 +0000 (GMT)
Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 4 Nov 2016 13:07:05 +0000
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Fri, 4 Nov 2016 06:06:50 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: Leeyoung <leeyoung@huawei.com>, "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.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: AQHSNdbxqovpH1S/M0ui/wYWAHL6uaDHupQAgAABPgCAAAJUAIAAUW6AgAAHrQD//43VoIAAeTWA//+O+kCAAHmIAIAAnsUA
Date: Fri, 04 Nov 2016 13:06:49 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908F0F1C9@dfweml501-mbx>
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> <655C07320163294895BBADA28372AF5D48B5C82F@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0C72C38E7EBC34499E8A9E7DD007863908F0F10B@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA51@dfweml501-mbx> <0C72C38E7EBC34499E8A9E7DD007863908F0F12D@dfweml501-mbx> <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172A8CCA9B@dfweml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.254.206]
Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908F0F1C9dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.581C87FB.0211, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 751c6e382f2a2d19dfac81b40374c626
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dlmAjojc2ZB2gy0-0FTobT1XcPQ>
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: Fri, 04 Nov 2016 13:07:14 -0000
Hi Young, If the client does not want to keep a COMPUTE_ONLY TE tunnel state it can always delete the state. Besides it will be possible to configure TE tunnel in COMPUTE_AND_FORGET mode, in which the provider will automatically remove the state as soon as it delivers the tunnel path computation results to the client. Furthermore, YANG global/action RPC makes sense when the path computation results could be returned synchronously. If this is not possible or cannot be guaranteed for whatever reason (e.g. path computation takes some time, needs to be requested from remote controller or PCE, etc.) RPC will also work, but this will not be much different from configuring a TE tunnel in COMPUTE_AND_FORGET mode, because the results will have to be delivered asynchronously using the regular client subscription (for the TE tunnel) notification. Igor From: Leeyoung Sent: Thursday, November 03, 2016 4:12 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; 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 Igor, When you say "state", are you referring to the YANG datastore or some other "interim" state of those paths that are calculated but not instantiated as LSPs? If we were to update the YANG datastore for this, I would think that we may have some issue when the customer decided not to instantiate the TE tunnel (after the path compute request). Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 3:02 PM To: Leeyoung; Scharf, Michael (Nokia - DE); Daniele Ceccarelli; 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 Young, >From the provider controller point of view COMPUTE_ONLY TE tunnels will have exactly the same state as "normal" (COMPUTE_ADN_PROVISION) TE tunnels. Igor From: Leeyoung Sent: Thursday, November 03, 2016 3:42 PM To: Igor Bryskin; Scharf, Michael (Nokia - DE); 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: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Igor, In such case, would the YANG datastore be updated? I guess not. If not, then the system/controller has to keep this interim state, would it? Thanks. Young From: Igor Bryskin Sent: Thursday, November 03, 2016 2:34 PM To: Scharf, Michael (Nokia - DE); Leeyoung; 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: RE: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 Michael, You are exactly right. The purpose of the "compute-only" TE tunnel is to create/maintain the normal TE tunnel state and (re-)compute TE paths for the TE tunnel connections/LSPs but not signal/provision the LSPs. Igor From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com] Sent: Thursday, November 03, 2016 3:17 PM To: Leeyoung; 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: http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00 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<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 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
- [Teas] CCAMP and JOINT YANG session agenda @IETF97 Daniele Ceccarelli
- [Teas] draft-zhang-ccamp-transport-yang-gap-analy… Igor Bryskin
- [Teas] http://tools.ietf.org/html/draft-busibel-t… Igor Bryskin
- Re: [Teas] draft-zhang-ccamp-transport-yang-gap-a… Belotti, Sergio (Nokia - IT)
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Scharf, Michael (Nokia - DE)
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Daniele Ceccarelli
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Scharf, Michael (Nokia - DE)
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Daniele Ceccarelli
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Belotti, Sergio (Nokia - IT)
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Daniele Ceccarelli
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Leeyoung
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Scharf, Michael (Nokia - DE)
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Leeyoung
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Leeyoung
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Beller, Dieter (Nokia - DE)
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Leeyoung
- Re: [Teas] draft-zhang-ccamp-transport-yang-gap-a… Zhangxian (Xian)
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Dhruv Dhody
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] http://tools.ietf.org/html/draft-busib… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Dieter Beller
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- [Teas] 答复: [mpls] http://tools.ietf.org/html/draf… Fatai Zhang
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- [Teas] 答复: [mpls] http://tools.ietf.org/html/draf… Fatai Zhang
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Belotti, Sergio (Nokia - IT)
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Italo Busi
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Italo Busi
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Italo Busi
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Francesco Lazzeri
- Re: [Teas] [mpls] http://tools.ietf.org/html/draf… Igor Bryskin