Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 8 Jul 2013 09:58:36 +0000

Hi, Dear PCErs, 

      We have just upload a new draft specifying the need in PCEP to allow incremental LSP state synchronization as well as PCE control over this process for stateful PCE(s).  It also proposes PCEP extensions to support the requirements.   

       Any comments/feedback are appreciated. 

Regards,
Xian ( on behalf of all authors)

________________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2013年7月7日 19:41
到: Zhangxian (Xian); Xiegang (A); Dhruv Dhody
主题: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

A new version of I-D, draft-zhx-pce-stateful-lsp-sync-00.txt
has been successfully submitted by Xian Zhang and posted to the
IETF repository.

Filename:        draft-zhx-pce-stateful-lsp-sync
Revision:        00
Title:           LSP Synchronization for Stateful Path Computation Element (PCE)
Creation date:   2013-07-05
Group:           Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-zhx-pce-stateful-lsp-sync-00.txt
Status:          http://datatracker.ietf.org/doc/draft-zhx-pce-stateful-lsp-sync
Htmlized:        http://tools.ietf.org/html/draft-zhx-pce-stateful-lsp-sync-00

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   [Stateful-pcep] specifies a set of extensions to PCEP to enable
   stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via
   PCEP and maintaining of these LSPs at the stateful PCE.  This
   document describes the mechanisms for incremental LSP Database (LSP-
   DB) synchronization as well as PCE control of the LSP-DB
   synchronization process.

The IETF Secretariat

---

From: Ina Minei <[email-masked]>
Date: Mon, 8 Jul 2013 19:48:25 +0000

One minor comment for those of you who might be reviewing this draft, please be aware that 
Pce-triggered sync is also covered in http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05#section-5.5.4 (though the entire database is exchanged in that case).

Ina 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Monday, July 08, 2013 2:59 AM
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs, 

Regards,

A new version of I-D, draft-zhx-pce-stateful-lsp-sync-00.txt
has been successfully submitted by Xian Zhang and posted to the IETF repository.

Abstract:

The IETF Secretariat
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 8 Jul 2013 21:46:17 +0000

Hi there

The incremental state synchronization mechanism looks like a potentially useful optimization.  I have a few questions for the draft authors.

The motivation of the incremental synchronization mechanism is to reduce the time and bandwidth of the synchronization process.  This is likely to be true in scenarios where the LSP database is large and the number of changes since the last successful synchronization is small.  Conversely, if the LSP database is small and the PCE has taken a long time to recover then it might actually be quicker to perform a full mark-and-sweep synchronization.

Is the intent of your draft that the PCC and PCE can choose whether to perform an incremental or full synchronization based on how out of date the PCE's database is?  In which case, who makes the choice, using what criteria, and how is that choice made known to the other party?  Or is the intent that incremental synchronization is always preferred if both parties support it?

The incremental synchronization relies on the PCC replaying the necessary PCRpt messages to the PCE to bring it up to date, including any that relate to deleted LSPs.  Do you have any guidelines on how many PCRpts the PCC should cache and for how long?  Have you considered a check-pointing mechanism where the PCE occasionally confirms that is has a persistent copy of DB version x to avoid this cache from growing too large?

You need to deal with the case where both PCE and PCC set the D flag and yet the PCC's cache of PCRpts does not go back far enough to make an incremental synchronization possible.  In this case, a full synchronization is necessary regardless of the D bits.

Regards
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 08 July 2013 10:59
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs, 

Regards,

Abstract:

The IETF Secretariat

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 9 Jul 2013 07:33:20 +0000

Hi, Ina, 

     Yes; we are aware of this and so from protocol extensions point of view, this draft does follow the use of related flags defined there. 

    However, the intention of these two PCE-triggered action are different. In this new draft, it aims to allow the PCE to control the timing of LSP state synchronization (even before its LSP DB is up-to-date) across PCEP sessions. While in draft-ietf-pce-stateful-pce-05 intends to allow sanity check by PCE after the stateful PCE is fully functional (aka with full LSP-DB). 

    What do you think of the draft itself? Do you think the requirements are valid? 

Regards,
Xian

________________________________________
发件人: Ina Minei [[email-masked]]
发送时间: 2013年7月9日 3:48
到: Zhangxian (Xian); [email-masked]
主题: RE: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Ina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Monday, July 08, 2013 2:59 AM
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs,

Regards,

Abstract:

The IETF Secretariat

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 9 Jul 2013 13:17:24 +0000

Hi, Dear Jon, 

    Thank you very much for the useful comments. Please see our reply inline (looking for [AUTHORS]):

________________________________________
发件人: Jonathan Hardwick [[email-masked]]
发送时间: 2013年7月9日 5:46
到: Zhangxian (Xian); [email-masked]
Cc: [email-masked]
主题: RE: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi there

[AUTHORS]: Agreed. 

Is the intent of your draft that the PCC and PCE can choose whether to perform an incremental or full synchronization based on how out of date the PCE's database is?  In which case, who makes the choice, using what criteria, and how is that choice made known to the other party?  Or is the intent that incremental synchronization is always preferred if both parties support it?
[AUTHORS]:  In the current version 'incremental synchronization' is always preferred if both parties support it. Do you feel strongly if this needs changing?

[AUTHORS]: PCC needs to cache PCRpts of deleted LSPs only if there exist some PCEP session to a stateful PCE a)which was previously up and LSP-DB synchronized, but temporarily down; b)supported LSP-DB-Version TLV in PCRpts (IDB flag was set in OPEN).
  
[AUTHORS]: Also, say the DB version when a LSP gets deleted is X,  The DB version at the time of last synchronization for a 'down' session be DBV(i) where i=1 to N (N temporarily down sessions with above conditions satisfied), Then you no longer need to cache PCRpts of a deleted LSPs if X < MIN{DBV(i),(i=1...N)}

[AUTHORS]: Whenever a down session comes up and state is synchronized, the above condition can be used to clear the cache. Since this is a local mechanism of PCC, should it be a part of the specification? 

[AUTHORS]: One way to do this would be to have another flag in LSP object along with SYNC to indicate if PCC report is for incremental state synchronization. 

Best Regards,
Xian (on behalf of all authors)

Regards
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 08 July 2013 10:59
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs,

Regards,

Abstract:

The IETF Secretariat

---

From: Ina Minei <[email-masked]>
Date: Tue, 9 Jul 2013 16:18:44 +0000

Xian, 

The idea of only doing an incremental sync is very useful, I think the requirements are valid for cases where large dbs are involved. As Jon mentioned, it is not applicable to all scenarios, and one must always weight the cost in extra complexity vs the benefit. 

My original email was to make sure the wg is aware of the other sync-related changes in the stateful pce draft, since I don’t think many people have had a chance to read the draft.

The draft might want to expand on how to determine what is missing, correlation between version db and srp-id-numbers or other mechanisms to avoid having to keep unbounded state for the purpose of cross-checking, errors in this process and recovery from them.

Thanks, 

Ina 

-----Original Message-----
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: Tuesday, July 09, 2013 12:33 AM
To: Ina Minei
Cc: [email-masked]
Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Ina, 

Regards,
Xian

One minor comment for those of you who might be reviewing this draft, please be aware that Pce-triggered sync is also covered in http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05#section-5.5.4 (though the entire database is exchanged in that case).

Ina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Monday, July 08, 2013 2:59 AM
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs,

Regards,

Abstract:

The IETF Secretariat

---

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 9 Jul 2013 20:24:57 +0000

Hi Xian

Thanks for your replies.  Here are my suggestions.

-  The draft should explain more clearly the circumstances in which this is a worthwhile optimization.

-  I agree that there is no need for you to go into detail about how the PCC's cache of database updates should operate.  However, I do think that you should state that it is not necessary for the PCC to store a complete history of all database updates.

-  You should define a mechanism where the PCC can choose to send a full resynchronization instead of an incremental synchronization.  This could be either because of a policy on the PCC or because the PCC does not have enough history in its database update cache to perform an incremental synchronization.

Regards
Jon

-----Original Message-----
From: Zhangxian (Xian) [mailto:[email-masked]] 
Sent: 09 July 2013 14:17
To: Jonathan Hardwick
Cc: [email-masked]; [email-masked]
Subject: Re: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear Jon, 

Hi there

  

Best Regards,

Regards
Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: 08 July 2013 10:59
To: [email-masked]
Subject: [Pce] FW: New Version Notification for draft-zhx-pce-stateful-lsp-sync-00.txt

Hi, Dear PCErs,

Regards,

Abstract:

The IETF Secretariat