Subject: [Pce] RtgDir review: draft-ietf-pce-stateful-sync-optimizations-07.txt

From: Tomonori Takeda <[email-masked]>
Date: Fri, 20 Jan 2017 07:56:49 +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-sync-optimizations-07.txt
 Reviewer: Tomonori Takeda
 Review Date: Jan 20th, 2017
 IETF LC End Date: Not known 
 Intended Status: Standards Track

Summary:
 I have some minor concerns about this document that I think should be resolved before publication.

Comments:
 This document defines PCEP extensions for optimizing state synchronization.
 Base state synchronization is defined in [I-D.ietf-pce-stateful-pce].

 The document is well organized and easy to read.
 I have some technical questions.

Major Issues:
 None

Minor Issues:
 1) I have a question on incrementing rules for LSP State Database Version Number.
 In page5, it says:
  
   If state synchronization avoidance is enabled, a PCC MUST increment
   its LSP State Database Version Number when the 'Redelegation Timeout
   Interval' timer expires (see [I-D.ietf-pce-stateful-pce]) for the use
   of the Redelegation Timeout Interval).

 Can we ensure that PCC's LSP state DB does not change if LSP State Database Version Number does not change?

 For example, suppose a PCC contains three LSPs.
  LSP#1: delegated to PCE#1
  LSP#2: delegated to PCE#1
  LSP#3: not delegated

 Suppose 
   a) PCEP session between PCE#1 and PCC is terminated.
   b) LSP#3 state changed.
   c) PCEP session between PCE#1 and PCC is reestablished (within  'Redelegation Timeout Interval').
 
 In this case, I think LSP State Database Version Number does not change, but LDP state DB changed in b).
 Are you assuming that PCRpt for b) is stored and sent to PCE#1 after c)?
 
2) Is there any reason why LSP State Database Version Number is encoded per LSP object (LSP-DB-VERSION TLV of LSP object), not per PCRpt?
I think LSP state DB is per PCC, not per LSP. Thus it sounds more straight-forward to encode ID (LSP State Database Version Number) per PCRpt.

3) In page16 (Section 5.2.). it says:

   If the LSP-DB Version is mis-matched, it can send a PCUpd message with PLSP-
   ID = 0 and SYNC = 1 in order to trigger the LSP-DB synchronization process.

 For completeness, it would be good to clarify how to treat any parameter updates for the LSP in PCUpd.
 (Note that Section 6.2 says such procedures for PCE-triggered State Re-synchronization.)

Nits:
 None

Thanks,
Tomo

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 20 Jan 2017 19:31:32 +0000

Hi Tomo, 

Thank you for review and support. Please see inline for comments. 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Tomonori Takeda
> Sent: 20 January 2017 13:27
> To: [email-masked]' <[email-masked]>
> Cc: [email-masked]' <[email-masked]>;
> [email-masked]'
> <[email-masked]>;
> [email-masked]' <[email-masked]>
> Subject: [Pce] RtgDir review:
> draft-ietf-pce-stateful-sync-optimizations-07.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.
> 

[Dhruv] The purpose of the text is to force state synchronization if the PCEP session is not re-established between the re-delegation timer. This is mainly for sanity. 

>  Are you assuming that PCRpt for b) is stored and sent to PCE#1 after c)?

[Dhruv] In the step (b) when LSP#3 state is changed, the LSP State DB Version number will be incremented. This number is incremented for all LSPs, and not just for the LSPs that are not delegated. So in this case, full state synchronization will happen. 

> 
> 2) Is there any reason why LSP State Database Version Number is encoded
> per LSP object (LSP-DB-VERSION TLV of LSP object), not per PCRpt?
> I think LSP state DB is per PCC, not per LSP. Thus it sounds more
> straight-forward to encode ID (LSP State Database Version Number) per PCRpt.

[Dhruv] This was done mainly because PCRpt is a list of state reports of LSP and we do not have a way to encode object/TLV for all LSPs in the PCRpt message. 

>  (Note that Section 6.2 says such procedures for PCE-triggered State

[Dhruv] Good Catch. I can add text "The PCUpd message MUST include an empty ERO as its intended path and SHOULD NOT include the optional objects for its attributes."

Thanks! 
Dhruv 

> Nits:
>  None
> 
> 
> Thanks,
> Tomo
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Tomonori Takeda <[email-masked]>
Date: Sat, 21 Jan 2017 13:35:37 +0000

Hi Dhruv,

Thanks.

Please see in-line.

> [Dhruv] In the step (b) when LSP#3 state is changed, the LSP State DB Version number will be incremented. This number is incremented for all LSPs, and not just for the LSPs that are not delegated. > So in this case, full state synchronization will happen.

OK, I understand that LSP State DB Version will be incremented when LSP State DB changes, as well as Redelegation Timeout Interval timer expires.
That makes sense. Thanks.

> [Dhruv] This was done mainly because PCRpt is a list of state reports of LSP and we do not have a way to encode object/TLV for all LSPs in the PCRpt message.

This works, so I do not have any objection.

> [Dhruv] Good Catch. I can add text "The PCUpd message MUST include an empty ERO as its intended path and SHOULD NOT include the optional objects for its attributes."

Thanks. I think adding text would be beneficial for completeness.

Thanks,
Tomo

-----Original Message-----
From: Dhruv Dhody [mailto:[email-masked]] 
Sent: Saturday, January 21, 2017 4:32 AM
To: Tomonori Takeda（武田知典）; [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [Pce] RtgDir review: draft-ietf-pce-stateful-sync-optimizations-07.txt

Hi Tomo, 

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

> 
> 2) Is there any reason why LSP State Database Version Number is 
> encoded per LSP object (LSP-DB-VERSION TLV of LSP object), not per PCRpt?

>    If the LSP-DB Version is mis-matched, it can send a PCUpd message 
> with
> PLSP-

Thanks! 
Dhruv