Subject: [Pce] RE: Pce Digest, Vol 29, Issue 13

From: Young Lee <[email-masked]>
Date: Mon, 29 Jan 2007 17:00:31 -0600

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-masked] [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 11:00 AM
To: [email-masked]
Subject: Pce Digest, Vol 29, Issue 13

Send Pce mailing list submissions to
	[email-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

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-masked]>
Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the
	68th	IETF Meeting in Prague, Czech Republic 
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Begin forwarded message:

> From: [email-masked]
> Date: January 26, 2007 12:00:02 AM EST
> To: [email-masked]
> 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-masked].
>
> 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-masked]
> 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-masked]>
Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document
To: [email-masked]
Message-ID: <[email-masked]>
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-masked]>
> Date: January 24, 2007 11:38:04 AM EST
> 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.
>
> Thanks for your feed-back.
>
> JP, Jean-Louis et al.
> _______________________________________________
> Pce mailing list
> [email-masked]
> 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-masked]
https://www1.ietf.org/mailman/listinfo/pce

End of Pce Digest, Vol 29, Issue 13
***********************************

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

---

From: JP Vasseur <[email-masked]>
Date: Tue, 30 Jan 2007 08:06:13 -0500

Hi Young,

> little harder to be consistent across different applications and/or  

There is definitely a need for a base spec for an ID related to the  
objective function,
which does not mean that it should belong to the base protocol  
specification. The PCEP
authors (ad discussed with you) decided to have it in a separate ID  
(in the works) since
this is not a "core" function of PCEP (in other words, not required  
for the protocol to
operate in many circumstances).

> in inconsistency moving forward.

Your draft could then refer to the newly ID discussed below.

Thanks.

JP.