Hi Young,
On Jan 29, 2007, at 6:00 PM, Young Lee wrote:
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.
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).
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.
Your draft could then refer to the newly ID discussed below.
Thanks.
JP.
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
