Hi, Please see inline: ________________________________________ 发件人: Giovanni Martinelli (giomarti) [[email protected]] 发送时间: 2013年8月1日 6:30 到: Zhangxian (Xian) Cc: [email protected] 主题: Re: comment on draft-zhx-pce-stateful-lsp-sync-00
Hi Xian, On Jul 31, 2013, at 23:14 , "Zhangxian (Xian)" <[email protected]> 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 protected] [[email protected]] 代表 Giovanni Martinelli > (giomarti) [[email protected]] > 发送时间: 2013年8月1日 1:50 > 到: [email protected] > 主题: [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 protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
