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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
