Subject: Re: [Pce] comment on draft-zhx-pce-stateful-lsp-sync-00

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 1 Aug 2013 08:10:03 +0000

Hi, 

   Please see inline: 
________________________________________
发件人: Giovanni Martinelli (giomarti) [[email-masked]]
发送时间: 2013年8月1日 6:30
到: Zhangxian (Xian)
Cc: [email-masked]
主题: Re: comment on draft-zhx-pce-stateful-lsp-sync-00

Hi Xian,

On Jul 31, 2013, at 23:14 , "Zhangxian (Xian)" <[email-masked]>
 wrote:

> Hi,
>
>   Thank you for questions.
>
>  I do not understand your statement "if the PCC state is so big that could not be transferred in one shot (not necessarily one packet or one datagram). " When we are talking here is to synchronize the LSP-DB, which consists of LSPs of manageable message size. Actually, it is possible to combine multiple LSP states together.
>

GM> In  section 1.1 "Motivation" you provide some numbers. Could you estimate the the LSP-DB size & bandwidth available? Do you agree that optimisation suggested here has some costs?
Xian>   
"The bible" provides a mechanism for full syncrinization with LSP-DB (say  with the size of X), our proposal is to allow incremental syncronization in which case you transfer partial DB (let's assume Y). Note that Y is always smaller than X. So IMO there is no extra cost with respect to DB size or bandwidth availaible. Incremental sync. can actually help the PCE to come into full function quicker. Having said that, we are not trying to get rid of full sync., but rather to accommodate the scenario where there is such need (i.e., the scenario provided in motivation).   

> Secondly, for what you mentioned "first request fails", what do you mean by that? Since PCEP is based on TCP, so there should be mechanisms to support reliable delivery (outside of PCEP). So, NO MATTER if it is full sync. or partial sync., the DB will be incomplete anyway even if your assumption holds. So it does not invalidate our proposal.

GM> I guess I meant a state syncronization operation (or sequence ) as per section 5.4 "State Synchronisation"  of the bible.  In general operations may fails for different reasons ... anyway TCP should help you in avoiding further mechanism.
Xian> Ok. 

>
>
> As for the last comment, if you read (or may be interested to) the WG draft carefully, the function you mentioned below as "A PCC SHOULD remember the deleted LSP as well" is already supported there. So, I do not see how it is an issue at all.

GM>  could you provide a pointer where is already supported?

Xian> Let me start again. As stated in WG draft "This is accomplished by keeping track
   of the changes to the LSP State Database, using a database version
   called the LSP State Database Version."  and support of R bit in LSP object in Section 7.3, sending the remove state via PCRpt to stateful PCE for deleted LSP is already a part of WG document. In this document this state needs to be remembered for a little while longer to facilitate incremental LSP sysnc. Note that this is not too much of an overhead as this needs to be remembered only if there is a PCEP session down with which the PCC can do incremental update. 

BR,
Xian

Cheers
G

>
> Regards,
> Xian
>
> ________________________________________
> 发件人: [email-masked] [[email-masked]] 代表 Giovanni Martinelli (giomarti) [[email-masked]]
> 发送时间: 2013年8月1日 1:50
> 到: [email-masked]
> 主题: [Pce] comment on draft-zhx-pce-stateful-lsp-sync-00
>
> Dear Authors,
>
> here an engineer (not necessarily a network engineer) comment. It comes to my mind during today presentation so ...  tossing to the list hope help discussion.
>
> Looks to me you are adding an optimisation that actually may add more problems than the one you are trying to solve.
>
> I first wonder if the PCC state is so big that could not be transferred in one shot (not necessarily one packet or one datagram).  In case first request fails wound't be better just retry instead of adding the complexity of incremental updates?
>
> Second, you have to pay the price of partially synchronised DB. What you can do with a partial state? My first feeling you have to just consider your  DB as not synchronised.
>
> Third, You also imply there's more state to maintain at the PCC side as well...  e.g. "A PCC SHOULD remember the deleted LSP as well" .
>
> Cheers
> G
>
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Thu, 1 Aug 2013 08:28:58 +0000

Hi Xian,

for the rest ... well, anything more to add from my side

On Aug 1, 2013, at 10:10 , "Zhangxian (Xian)" <[email-masked]>
 wrote:

> Section 7.3, sending the remove state via PCRpt to stateful PCE for deleted LSP is already a part of WG document. In this document this state needs to be remembered for a little while longer to facilitate incremental LSP sysnc. Note that this is not too much of an overhead as this needs to be remembered only if there is a PCEP session down with which the PCC can do incremental update. 

Just a little note here what I mean is that "sending" is very different from "remembering" and have fairly different implication...

Cheers
G