Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

["BRUNGARD, DEBORAH A" <[e-mail]>]

Thanks Tomonori for your  careful review!
Deborah


> -----Original Message-----
> From: Tomonori Takeda [mailto:[e-mail]]
> Sent: Tuesday, September 13, 2016 7:30 AM
> To: 'Zhangxian (Xian)' <[e-mail]>; '[e-mail]' <rtg-
> [e-mail]>
> Cc: '[e-mail]' <[e-mail]>; Ina Minei <[e-mail]>;
> '[e-mail]' <[e-mail]>; Dhruv Dhody <[e-mail]>;
> '[e-mail]' <draft-ietf-pce-stateful-pce-
> [e-mail]>
> Subject: RE: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt
> 
> Hi Xian
> 
> Thanks.
> 
> <XIAN>: We actually take this as a commonly agreed assumption and it is also
> stated in < https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16>. As
> specified in that draft Section 2, delegation means that whoever accepts this
> delegation will be able to change its attributes. So, allowing more than one
> entity to accept the delegation at a given time (OR requesting control of a LSP
> to more than one PCEs) is not going to work. Does adding a explicit reference
> to the draft where delegation is defined work for you?
> 
> ==>
> 
> This may not be so obvious, but with current protocol specifications, we must
> use PCEs in this manner.
> I am fine with current text (no need for change).
> 
> <XIAN>: I think you captured the intention well in the 2nd case your
> elaborated. This use case assumes the use of an active stateful PCE which can
> trigger re-computation based on trigger such as but not limited failures,
> rather than based on undetermined sequential computation requests. How
> about expanding the last sentence as the following?
> 
> OLD:
> A stateful PCE can solve this through control over LSP ordering.
> NEW:
> An active stateful PCE can solve this through control over LSP ordering. Based
> on triggers such as a failure or an optimization trigger, the PCE can order the
> computations and path setup in a deterministic way.
> 
> ==>
> 
> Thanks for clarification. Proposed new text looks good to me.
> 
> Thanks,
> Tomonori Takeda
> 
> -----Original Message-----
> From: rtg-dir [mailto:[e-mail]] On Behalf Of Zhangxian (Xian)
> Sent: Tuesday, September 13, 2016 3:20 PM
> To: Tomonori Takeda（武田知典）; '[e-mail]'
> Cc: '[e-mail]'; Ina Minei; '[e-mail]'; Dhruv Dhody; 'draft-ietf-pce-
> [e-mail]'
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt
> 
> Hi, Tomonori Takeda,
> 
>    Thank you very much for the detailed review. With regard to the two minor
> issues you raised, please see inline marked with <XIAN>:
> 
> -----邮件原件-----
> 发件人: Tomonori Takeda [mailto:[e-mail]]
> 发送时间: 2016年9月9日 22:46
> 收件人: '[e-mail]'
> 抄送: '[e-mail]'; '[e-mail]';
> '[e-mail]'
> 主题: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through discussion
> or by updating the draft.
> 
> Document: draft-ietf-pce-stateful-pce-app-06.txt
> Reviewer: Tomonori Takeda
> Review Date: September 9th, 2016
> IETF LC End Date: Not known
> Intended Status: Informational
> 
> Summary:
> 
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> Comments:
> 
> This document describes applicability of a stateful PCE, as well as general
> considerations for deployment. The document is well organized and easy to
> read. However, there are some minor points which I think should be clarified
> for completeness and easiness to ready.
> 
> Major Issues:
> 
> None
> 
> Minor Issues:
> 
> 1) In page 5, section 4.1, multi-PCE deployments are described. It says,
> "Regardless of the reason for multiple PCEs, an LSP is only delegated to one of
> the PCEs at any given point in time." Is this described/defined in some other
> document, or in this document? In the first case, please indicate a reference.
> In the latter case, I would like to see more clarification and reasoning.
>  <XIAN>: We actually take this as a commonly agreed assumption and it is also
> stated in < https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-16>. As
> specified in that draft Section 2, delegation means that whoever accepts this
> delegation will be able to change its attributes. So, allowing more than one
> entity to accept the delegation at a given time (OR requesting control of a LSP
> to more than one PCEs) is not going to work. Does adding a explicit reference
> to the draft where delegation is defined work for you?
> 
> 2) In page 12, section 5.1.4, predictability is described as an application. It
> says "A stateful PCE can solve this through control over LSP ordering.", but I
> am not sure how stateful PCE solves this scenario. Is it possible even if
> computation requests come in a time series? Or is it assumed that a stateful
> PCE is used in such a way that computation requests do not come in a time
> series? (For example, in a failure scenario, LSP re-computation is not triggered
> by PCC requesting path computation, but by link failure?)
> 
> <XIAN>: I think you captured the intention well in the 2nd case your
> elaborated. This use case assumes the use of an active stateful PCE which can
> trigger re-computation based on trigger such as but not limited failures,
> rather than based on undetermined sequential computation requests. How
> about expanding the last sentence as the following?
> 
> OLD:
> A stateful PCE can solve this through control over LSP ordering.
> NEW:
> An active stateful PCE can solve this through control over LSP ordering. Based
> on triggers such as a failure or an optimization trigger, the PCE can order the
> computations and path setup in a deterministic way.
> 
> Regards,
> Xian (on behalf of all authors/contributors)
> 
> Nits:
> 
> None
> 
> Thanks,
> Tomonori Takeda