Subject: RE: [Pce] Compliance with the PCECP Requirement Document

From: "ASH, GERALD R \(JERRY\), SBCLABS" <[email-masked]>
Date: Sun, 28 Jan 2007 16:11:39 -0600

Hi JP,

> From: JP Vasseur [mailto:[email-masked]] 
> Sent: Wednesday, January 24, 2007 11:38 AM
> To: [email-masked]
> Subject: [Pce] Compliance with the PCECP Requirement Document
> 
> Dear WG,
> 
> As discussed in San Diego, there are still a few requirements 
> stated in RFC 4657 that PCEP does not satisfy (see Appendix A 
> of the PCEP ID) for which we'd like your feed-back:
> 
> 
> Appendix A
> 
> The aim of this section is to list the set of requirements 
> set forth
> in [RFC4657] that are not satisfied by the current revision of this
> document.  This only concerns the requirements listed as MUST
> according to [RFC2119].
> 
> 
> Here is the list of currently unsatisfied requirements:
> 
> o  Allow to select/prefer from advertised list of standard 
> objective functions/options
> 
> o  Allow to customize objective function/options
> 
> o  Support "unsynchronized" & "synchronized" objective functions
> 
> 
> Comment> The Proposal is to work on this item in the context 
> of a separate ID that will cover the set of requirements, IGP 
> PCED extensions and PCEP extensions since these functions are 
> not required for the base protocol specification.
> 
> o  Protocol recovery support resynchronization of information &
> requests between sender & receiver.
> 
> 
> Comment> We can see two potential avenues here:
> 1) Upon loosing the PCEP session, pending requests are 
> considered as lost, and the PCC has the initiative to resend 
> the set of pending requests. The main benefit of such 
> approach is to be extremely simple and IMO well suited to 
> most of the cases since path computation requests are not 
> likely to be pending for a long period of time.
> 2) Specify a set of re-synchronization procedures. We came up 
> with similar solutions for many other protocols (in very 
> different contexts and set of requirements) and our 
> experience clearly tells us that this will likely to be a 
> fairly complex issue. We could see some benefit in statefull 
> contexts though; thus if such functions is required for 
> particular context, we would propose not to include in the 
> base protocol specification and leave it for further should 
> the WG think that such function will be required.

Approach #1 seems very crude and puts much of the burden on PCC to
'recover'.  I can appreciate that #2 is more complex but would seemingly
allow recovery to occur more quickly and smoothly.  Assuming that PCE is
a critical network function, smoothing over a failed session in as short
a time as possible (or perhaps with no hiccup whatever) would be very
important IMO.

Thanks,
Jerry
 
> 
> Thanks for your feed-back.
> 
> 
> JP, Jean-Louis et al.
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 29 Jan 2007 14:21:06 -0500

Hi Jerry,

On Jan 28, 2007, at 5:11 PM, ASH, GERALD R ((JERRY)), SBCLABS wrote:

> 'recover'.

Two comments there:
1) Note that the probability for such a failure to happen while  
requests are pending is not likely to be very high in most cases.  
Still we've got to handle and discuss it but it is worth being  
considered when looking at the solution.
2) In term of PCC implementation, there is a trade-off between having  
to resend all lost pending requests and have to re-sync with the PCE  
after loosing a PCEP session. Not sure resending is more burden  
compared to adding more complexity to the FSM.

> I can appreciate that #2 is more complex but would seemingly
> allow recovery to occur more quickly and smoothly.

Also not very easy to evaluate until we've got a better idea on what  
#2 might look like. Indeed, the PCC may decide to implement fairly  
quick retransmission once the PCEP session is restored thus leading  
to potentially comparable recovery time compared to #2.

For the PCE side, we would increase the overall complexity also,  
allocated resources.

> Assuming that PCE is

Thanks for the feed-back.

We've got 3 options here:
1) We add #2 to the base protocol specification
2) We decide to work on #2 but we leave it out of the base protocol  
specification
3) We decide not to work on #2 for the time being.

WG ?

My personal opinion is not to go with 1) since there are many  
situations where such feature would not be required thus it is  
probably a good idea not to overload the base protocol spec.

Let's see what others think ?

Thanks.

JP.