Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

[Cyril Margaria]

Hi

I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is also
applicable for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affect delegated
and non delegated LSPs, the Stateful PCE would be benefit from knowing
which non delegated LSP is to be rerouted.


BR,
Cyril.


On 27 February 2014 07:40, Ramon Casellas  wrote:

>  El 27/02/2014 3:43, Dhruv Dhody escribió:
>
>
>
>  > What is not available today is to send the LSP object in the PCReq,
> Ina since you bring this up, IMO LSP object in PCReq for passive stateful
> PCE can be useful in case of re-optimization, exclusion etc.
>  Some extensions to PCEP are needed to do that, but the first step would
> be to identify an LSP in PCReq message.
>
>
> Dhruv, Ina, all
>
> TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE
> may delegate a complex (e.g. optical)
> computation/re-optimization/defragmentation to a "back-end" PCE, and both
> the TED and LSPDB are shared between the pool of PCEs. In previous versions
> of the draft, we used the LSP object that was included within a PCEP
> request. There was the issue about the plspid, our approach was based on
> using a dummy plspid and refer to the LSP entry in the database by its
> symbolic name (primary key).
>
> In short, we did find it useful to be able to "refer" to an LSP within the
> db when requesting computations between collaborating PCEs. Indeed, much
> like Dhruv's, for this specific use case, the backend is stateful but
> passive. The alternative is to provide the RRO, but the db contains other
> relevant information that cannot be conveyed in a "rfc5440" re-optimization
>
> Thanks
> Ramon
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01

[Zhangxian (Xian)]

Hi, Jon,

 Glad to see the first two points are now cleared.  Please see my 
explanation to the last point inline, marked with [Xian2]:

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 2014年2月26日 17:12
To: Zhangxian (Xian)
Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizati...@tools.ietf.org
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi Xian, please see [Jon] below...

From: Zhangxian (Xian) [mailto:zhang.x...@huawei.com]
Sent: 22 February 2014 07:33
To: Jonathan Hardwick
Cc: pce@ietf.org; draft-minei-pce-stateful-sync-optimizati...@tools.ietf.org
Subject: RE: Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi, Jon,

   Thank you very much for the constructive comments.  Please see my reply 
inline, marked with [Xian]:

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 2014年2月15日 2:35
To: 
draft-minei-pce-stateful-sync-optimizati...@tools.ietf.org
Cc: pce@ietf.org
Subject: [Pce] Comments on draft-minei-pce-stateful-sync-optimizations-01

Hi there

I have reviewed this draft �C here are my comments.

Best regards
Jon

Section 3.2
Figure 2, I think the “sync done” PCRpt should have SYNC=0, not SYNC=1.
[Xian]: Indeed. Thank you for spotting this typo.

Section 5.2
   If a PCC has to force full LSP DB
   synchronization due to reasons including but not limited: (1) local
   policy configured at the PCC; (2) no sufficient LSP state caches for
   incremental update, the PCC can set the D flag to 0.

Perhaps I have misunderstood, but I think case (2) above doesn’t work.  The PCC 
does not know that it has “no sufficient LSP state caches” until it receives 
the OPEN from the PCE and sees what DBv the PCE has sent.  By then, the PCC has 
already sent its OPEN so it is too late to set D=0.  To cover case (2) the 
draft needs a mechanism for the PCC to change its mind and tell the PCE that it 
is going to send a full snapshot, not a replay of the missing database updates. 
 The simplest thing is probably for the PCC to bring the session down and then 
bring it back up again with D=0.

[Xian]:  It actually depends, IMHO. If it is due to the 1st reason listed 
above, then, it can decide before sending OPEN and set D=0. The cases as a 
result of the 2nd reason might be more complicated. Your analysis would be one 
of the cases, in which a PCC can detect the insufficient LSP state caches ONLY 
after it gets the DB version information from the other party. But if a PCC has 
no LSP state caches or incomplete (missing quite some LSP state or those of the 
DB version in between), I think it is possible that it can decide without even 
checking the DBv from the other party. Does this clarify?

To include the case you described, how about we update the text  as below?

OLD:
   If a PCC has to force full LSP DB
   synchronization due to reasons including but not limited: (1) local
   policy configured at the PCC; (2) no sufficient LSP state caches for
   incremental update, the PCC can set the D flag to 0.

[DD] NEW:
   If a PCC may have to force full LSP DB
   synchronization due to reasons including but not limited: (1) local
   policy configured at the PCC; (2) no sufficient LSP state caches for
   incremental update, the PCC can set the D flag to 0. Note a PCC may have to 
bring
 down the current session and  force a full LSPDB synchronization with D flag 
set to
0 in the  subsequent open message.

[Jon] Looks good to me.

Section 4 talks about the PCE having to mark its LSP database as stale, and 
then remove any stale LSPs at the end of the synchronization process.  I assume 
that this does not apply in section 5.  To avoid confusion, I think section 5 
should state that the PCE does not mark its LSP database as stale if both it 
and the PCC have set D=1.
[Xian]: Sure.  I think we have already explained in Section 5. The last 
sentence of the paragraph below Figure 7 says: “Note that the PCE should not 
mark the existing LSPs as stale for incremental state synchronisation”.

[Jon] Apologies, I missed that.

In figure 7, I may have misunderstood section 4, but I don’t think this is how 
the T bit is specified.  I don’t think T=1 forces the PCC to wait for a PCUpd 
before sending the initial snapshot as you have shown.  I don’t think this 
substantially changes anything about section 5, so I suggest removing the 
discussion of the T bit from section 5.
[Xian]：Section 4 describes how a PCE can force re-synchronization after the 
initial LSP-DB synchronization has been done. Section 5 talks about an 
alternative method for the initial LSP-DB sync. (i.e., incremental way).  The 
idea here is allow PCE to control the sequence of incremental sync., the 
authors do see the value. However, you can see from the explanation of Section 
5, setting the T=1 is NOT a mandate operation to enable incremental sync., but 
a feature optical and not 

Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

[Zhangxian (Xian)]

Hi, All,

 I also support adding this function. I remember previous version of this 
draft (v6) does support this (see: 
http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-06#section-6.4). It 
would be good to explain why it is removed in the current version if not 
before. Also, how the following scenarios mentioned by Cyril, Ramon & Dhruv 
could be addressed if v8 is used. That would help to see if this function is 
indeed useful.

Regards,
Xian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria
Sent: 2014年2月27日 16:44
To: Ramon Casellas
Cc: pce@ietf.org
Subject: Re: [Pce] comments draft-ietf-pce-stateful-pce-08.txt

Hi
I agree with Ramon and Druv.
In addition to those use case, the LSP object in PCReq/PCRep is also applicable 
for non-delegated LSP in an active stateful PCE case.
One example can be the rerouting after a failure, this may affect delegated and 
non delegated LSPs, the Stateful PCE would be benefit from knowing which non 
delegated LSP is to be rerouted.

BR,
Cyril.

On 27 February 2014 07:40, Ramon Casellas 
mailto:ramon.casel...@cttc.es>> wrote:
El 27/02/2014 3:43, Dhruv Dhody escribió:


> What is not available today is to send the LSP object in the PCReq,
Ina since you bring this up, IMO LSP object in PCReq for passive stateful PCE 
can be useful in case of re-optimization, exclusion etc.
Some extensions to PCEP are needed to do that, but the first step would be to 
identify an LSP in PCReq message.

Dhruv, Ina, all

TL&DR +1. Just fwiw, in one of our use cases, a "front-end" stateful PCE may 
delegate a complex (e.g. optical) computation/re-optimization/defragmentation 
to a "back-end" PCE, and both the TED and LSPDB are shared between the pool of 
PCEs. In previous versions of the draft, we used the LSP object that was 
included within a PCEP request. There was the issue about the plspid, our 
approach was based on using a dummy plspid and refer to the LSP entry in the 
database by its symbolic name (primary key).

In short, we did find it useful to be able to "refer" to an LSP within the db 
when requesting computations between collaborating PCEs. Indeed, much like 
Dhruv's, for this specific use case, the backend is stateful but passive. The 
alternative is to provide the RRO, but the db contains other relevant 
information that cannot be conveyed in a "rfc5440" re-optimization

Thanks
Ramon

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce