Hi J-P, Regarding your proposal on the objective function/options not to be defined in the PCEP-Version 1, I suggest to define the objective function object in the PCEP-Version 1. Unless there's base object definition, it would be a little harder to be consistent across different applications and/or PCEP extensions.
For instance, in the PCE Global concurrent optimization I-D, the global objective functions need to be defined. The authors have decided to define the Global Objective Function (GOF) Object. I can see each application or extension would define its own Objective Function Object, which could result in inconsistency moving forward. Regards, Young > 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. I -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, January 26, 2007 11:00 AM To: [email protected] Subject: Pce Digest, Vol 29, Issue 13 Send Pce mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic (JP Vasseur) 2. Fwd: [Pce] Compliance with the PCECP Requirement Document (JP Vasseur) ---------------------------------------------------------------------- Message: 1 Date: Fri, 26 Jan 2007 11:02:18 -0500 From: JP Vasseur <[EMAIL PROTECTED]> Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Begin forwarded message: > From: [EMAIL PROTECTED] > Date: January 26, 2007 12:00:02 AM EST > To: [email protected] > Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF > Meeting in Prague, Czech Republic > > > There are two (2) Internet-Draft cutoff dates for the 68th > IETF Meeting in Prague, Czech Republic: > > February 26th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 26th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 19th at 9:00 AM ET. > > March 5th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 5th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 19th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > [EMAIL PROTECTED] > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 68th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_68.html. > > _______________________________________________ > IETF-Announce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070126/c11a8762/attachment- 0001.html ------------------------------ Message: 2 Date: Fri, 26 Jan 2007 11:09:44 -0500 From: JP Vasseur <[EMAIL PROTECTED]> Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document To: [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" Dear WG, In absence of negative reply we'll go ahead with the proposed plan below. Let us know within 1-2 weeks max if you have comments. Thanks, JP. Begin forwarded message: > From: JP Vasseur <[EMAIL PROTECTED]> > Date: January 24, 2007 11:38:04 AM EST > 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. > > Thanks for your feed-back. > > JP, Jean-Louis et al. > _______________________________________________ > Pce mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070126/2dc60500/attachment- 0001.html ------------------------------ _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 29, Issue 13 *********************************** _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
