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

From: Tomonori Takeda <[email-masked]>
Date: Fri, 9 Sep 2016 14:46:05 +0000

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.

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?)

Nits:

None

Thanks,
Tomonori Takeda

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 13 Sep 2016 06:19:32 +0000

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:[email-masked]] 
发送时间: 2016年9月9日 22:46
收件人: [email-masked]'
抄送: [email-masked]'; [email-masked]'; [email-masked]'
主题: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hello,

Summary: 

Comments: 

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?

<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

---

From: Tomonori Takeda <[email-masked]>
Date: Tue, 13 Sep 2016 11:29:31 +0000

Hi Xian

Thanks.

==>

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).

OLD: 

==>

Thanks for clarification. Proposed new text looks good to me.

Thanks,
Tomonori Takeda

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, September 13, 2016 3:20 PM
To: Tomonori Takeda（武田知典）; [email-masked]'
Cc: [email-masked]'; Ina Minei; [email-masked]'; Dhruv Dhody; [email-masked]'
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hi, Tomonori Takeda, 

-----邮件原件-----
发件人: Tomonori Takeda [mailto:[email-masked]] 
发送时间: 2016年9月9日 22:46
收件人: [email-masked]'
抄送: [email-masked]'; [email-masked]'; [email-masked]'
主题: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hello,

Summary: 

Comments: 

Major Issues: 

None

Minor Issues: 

OLD: 

Regards,

Nits:

None

Thanks,
Tomonori Takeda

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 13 Sep 2016 16:10:31 +0000

Thanks Tomonori for your  careful review!
Deborah

> From: Tomonori Takeda [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2016 7:30 AM
> To: 'Zhangxian (Xian)' <[email-masked]>; [email-masked]' <rtg-
> [email-masked]>
> Cc: [email-masked]' <[email-masked]>; Ina Minei <[email-masked]>;
> [email-masked]' <[email-masked]>; Dhruv Dhody <[email-masked]>;
> [email-masked]' <draft-ietf-pce-stateful-pce-
> [email-masked]>
> 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?
> 
> ==>
> 
> <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:
> 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.
> 
> ==>
> 
>    Thank you very much for the detailed review. With regard to the two minor
> issues you raised, please see inline marked with <XIAN>:
> 
> -----邮件原件-----
> 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.
> 
> 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:
> 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,

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Wed, 14 Sep 2016 00:49:32 +0000

Hi Tomonori, 

   Great; I will incorporate the changes in the next draft update. 

Cheers,
Xian

-----邮件原件-----
发件人: Tomonori Takeda [mailto:[email-masked]] 
发送时间: 2016年9月13日 19:30
收件人: Zhangxian (Xian); [email-masked]'
抄送: [email-masked]'; Ina Minei; [email-masked]'; Dhruv Dhody; [email-masked]'
主题: RE: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hi Xian

Thanks.

==>

OLD: 

==>

Thanks,
Tomonori Takeda

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, September 13, 2016 3:20 PM
To: Tomonori Takeda（武田知典）; [email-masked]'
Cc: [email-masked]'; Ina Minei; [email-masked]'; Dhruv Dhody; [email-masked]'
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hi, Tomonori Takeda, 

-----邮件原件-----
发件人: Tomonori Takeda [mailto:[email-masked]] 
发送时间: 2016年9月9日 22:46
收件人: [email-masked]'
抄送: [email-masked]'; [email-masked]'; [email-masked]'
主题: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt

Hello,

Summary: 

Comments: 

Major Issues: 

None

Minor Issues: 

OLD: 

Regards,

Nits:

None

Thanks,
Tomonori Takeda