Hi JP, > From: JP Vasseur [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 24, 2007 11:38 AM > To: [EMAIL PROTECTED] > 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 protected] https://www1.ietf.org/mailman/listinfo/pce
