Last Modified: 2005-01-17
|Feb 05||Submit first draft of PCE architecture document|
|Feb 05||Submit first draft of PCE discovery requirements and protocol extensions documents|
|Apr 05||Submit first draft of the PCE communication protocol requirements|
|May 05||Submit first draft of the definition of objective metrics|
|Jul 05||Submit first draft of the PCE communication protocol specification|
|Aug 05||Submit PCE architecture specification to the IESG to be considered as Informational RFC|
|Nov 05||Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering)|
|Nov 05||Submit first draft of the MIB module for the PCE protocol|
|Dec 05||Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC|
|Dec 05||Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard|
|Dec 05||Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard|
|Feb 06||Submit the applicability and metrics documents to the considered as Informational RFCIESG to be|
|Feb 06||Evaluate WG progress, recharter or close|
Path Computation Element (PCE) Working Group - 03/07/2005 - IETF-62 - Minneapolis
Thanks to Jaudelice De Oliveira and Zafar Ali for having taken the minutes.
Work group established, WG should concentrate on first milestones: G/MPLS TE and Simple configurations (Inter-area TE) first
Milestones have very aggressive timeline
Applications for PCE: Encouraged to continue to work on applications for PCE (though out of scope for the moment). Not to expect to become WG document, but encouraged to work on future applications.
Work in progress to be presented today:
- Draft on PCE architecture
- Draft on PCE discovery requirements and protocol extensions
- Draft on PCE communication
Immediate next work:
Draft on PCE communication protocol specification
Draft on PCE discovery protocol
Draft on objective metrics
End of chair report
Question from audience on objective metrics: Metrics to evaluate PCE.
JP gave a few examples of metrics of interest:
E.g., How fast you can respond to topology changes, etc.
First presentation: draft-ash-pce-architecture-01.txt, Jerry Ash
Drafts discusses terminology, assumptions, motivation, architectural considerations, security & confidentiality and evaluation metrics.
Issued raised on the list - already responded (text added to several sections with respect to every comment)
added to 6.4: PCE should advertise capabilities
added to 6.6: Path computation request include if near-disjoint paths acceptable
added to 6.7: TED information can include info from sources other than IGP
added to 6.8: elaborate on advantages of stateful PCE & pitfalls of using stateful PCE in a distributed PCE environment
added to 7: Further metrics proposed to evaluate PCE solutions
next steps: propose draft as PCE WG draft
Question: Concern raised on how feasible is the considered approach (stateful PCE).
An element performing optimal computational might take infinite time to do so. Concern about delegating the distributed control plane responsibility to PCE.
Question on possibility of unsolicited requests
PCC-to PCE request/PCE-PCC reply or also unsolicited requests possible?
PCE-PCE communication: communicating paths exchange only or other is it possible to communicate other info as well?
Are there specific requirements on response time of PCE? (for global optimization)
JP: will be part of the evaluation metrics.
Kireeti: need to be careful with pce, not trying global optimal solution stateful x stateless: can't keep all info on lsps (costly)
Dimtri asked a question on stateful vs. stateless PCE in the document; how feasible is stateful PCE? Is it reasonable to assume stateful PCE?
Jerry: yes for some applications.
Dimitri: Is this can be assumed manageable? Given control to PCE that is otherwise done by a distributed control plan.
JP added: Itís applicable for some applications requiring global optimization.
Kireeti: (Global Optimality) is NOT a good target. Stateful PCE provides lot of complexity, while nice- not feasible.
Dimitri: Concerning global optimization, raises issue about the trigger and maintenance of this process (responsibility) that is now pulled outside of the local node and delegated to a third party -> therefore there is now a system impact in terms of performance of the global system
JP: Evaluation Metric is to be used for this purpose.
Dimitri: but these are not evaluation metrics in terms of computation results these are specific metrics for evaluating the correct behaviour of the system
JP agreed on the fact that it is out of the scope to make algorithmic evaluation.
Igor: Similar comments for stateful vs. stateless.
Adrian: ITU-T also requires similar functionality. Liaison Statement to ITU-T is completed. We think SG-15 would be a good start.
J. Sadler: Yes, there is similar work pursued at ITU-T. G7715 on ITU-T has similar function.
JP Polled the audience for the Architecture document.
JP: Majority in favor it as a WG document. We will confirm at the mailing list.
Second presentation: draft-leroux-pce-discovery-reqs.txt, Jean-Louis
PCE Discovery requirements
The draft addresses PCE discovery within and across domain(s).
Address comments received in the next version
* Need to improve security particularly for Inter-AS PCE discovery
* Discovery of dynamic parameters such as the PCE CPU state
* PCE aliveness detection
Consensus for a WG doc?
Kiretti: Discovery of PCEs: better rely on PCC-PCE communication?
comment2: If there is a need, routing is a better place than signalling.
JP reminded that the document is just identifying requirements but not solutions.
Confusion on slide showing ABR acting as PCEs (PCEs seem not needed). How did the 60 seconds rule was defined? Need to include how that was decided.
Dimitri: Are we not already overloading the PCEs? Need to define the right level of abstraction... It is an open question. Needs further discussion. Correct architecture design is required to address the overload problem before hand.
Adrian: Reminder that the draft is in its first version.
Kireeti: Re: flooding dynamic state of the PCE, if PCE discovery includes CPU load factor, it will complicate the PCC system.
Dimitri: you havenít design the system and are worried about the overloaded system. General problem of the overload should be solved at the root (architecture). The sense in which i used the term architecture is not exactly the same as the one used per this doc. here i do refer to the set of the protocol mechanisms and underlying operations - not the global framework architecture
Tony Li: As far as process is concerned, start off with a good requirement document, enumerate minimum set of requirements. What you got right now is iteration from the solution space. Focus on minimal requirements and what is the basic problem we are trying to solve.
Adrian: This was only first revision of the document.
Igor: We need to advertise backup PCE, why backup PCE and not load-balanced.
Jean-Louis: The SP thinks that having a dedicated backup could also be useful. But this is optional.
JP: Few sensitive topics like advertisement of dynamic capability needs more discussion on the mailing list.
Richard Rabbat: Not all ABR are PCE in your Figure.
Jean-Louis: It is just an example case used for illustration purpose only.
Richard Rabbat: How did you come up with 60 second requirement?
Jean-Louis: There are number of SP on the ID and we think 60 sec is a good target. Will provide more details on this.
Dimitri: Does these requirements covers inter-AS case?
Dimitri: Today, overloading cases may occur as part of a label switch router - and we just start discussions concerning the overload problems - as we have after several years of active work the conditions where the (distributed) overload occurs, therefore should we worry about PCE overload instead of focusing on the right level of detail at this point in time. We need to make sure that right level of details are provided in the document. The basic stuff like, how to find reachable addresses is not there in the document. We donít have basic stuff in the document.
Jean-Louis: No reachability stuff is detailed in the document. There is mention of domain ID-es: area-ID & AS number.
JP: This is not a flushed out version. Thanks to DT for their effort in putting this together. Requires more discussion in the mailing list before asking to adopt this ID as a WG document.
Third presentation: draft-ash-pce-comm-protocol-reqs-00, Jerry Ash
PCE/PCE Communication requirements (PCC-PCE & PCE-PCE)
Various issues raised on the list: for example extensive discussions about re-use of RSVP object encodings
Arthi: Is there a requirement of unsolicited PCE to PCC communication.
Zafar: Yes, there are cases where unsolicited PCE to PCC communication is required.
Many: Is it suitabe to list candidates on this documents?
JP: candidates are out of the scope of this protocol. Document is a very first cut.
Kireeti: Stateless x stateful. There are needs and there are benefits.
Comment: Contradiction, scalability reqirements.
Dimitri: on QOS/ CAC in the slides, do you also expect PCE to make decision that is related to the forwarding plan?
Jerry: The intension was to mention requirement to include some QOS parameters in the PCC-PCE messages.
JP: clarified that the intention was to include possibility of QoS considerations in path computation.
JP/ Jerry: I.e., Path Computation Constraints related parameters.
Kireeti: On GR of PCE: When it comes to GR, there is a huge difference between stateful and stateless PCE. Recommend to put it in an applicability statement.
JP: Yes, complexity analysis is meant for this purpose.
Adrian/ JP: Estimates some work to flush-out details. Itís a huge list of requirements. We want to handle simple problem first. Candidate protocols are not considered or within scope.
Zafar: Relationship with other WG-es.
Adrian: Initial thought is to get such input from CCAMP. E.g., GMPLS usage of PCE, inter-domain stuff is example of cases where input from CCAMP is needed.
Dimitri: what about the reachability of PCE location(s) for non-IP terminating nodes.
Adrian: GMPLS requirements from CCAMP.
Conclusion: Needs more discussion on the list. This document will be the basis of the work.
CCAMP was to provide areas where PCE would be useful. There is already a draft on the GMPLS use of PCE.
JP mentioned that many of the drafts were posted recently and did not have a slot in this meeting mostly because the focus was on the main documents and to flesh out the requirements.
JP/ Adrian: Many of the drafts were put in and right now we are flushing out first milestone. Other applications will be addressed later. Charter at present does not include candidate (solutions). Questions like what layer PCE should work on? Should PCC-PCE be based on a reliable transport? TCP is reliable, is it a candidate? are among the question charter addresses.
Discussion on statement on the requirement of reliability.
Dimitri: The biggest question is if we can use RSVP for PCC-PCE communication.
Zafar: Itís funny that when we talk about IGP-es, people settle with what we have today, and when it comes to signaling we tend to have such a large diversion. In my opinion signaling is a very small piece of the overall architecture and we should make use of what we have today.
Dimitri: But RSVP is designed for end-to-end (session) signaling and not a PCC-PCE client-server exchange. Instead, what about considering communication relying on the transport layer (TCP)
Zafar: Letís be clear on what we mean here. We are talking about use of RSVP for encoding. At the transport level we can still rely on TCP.
Kireeti: Not for RSVP as PCC-PCE protocol. Itís not defined for this purpose.
Zafar: We know that PCC is going to signal using RSVP-TE, why not provide information encoded in RSVP format to minimize useless copying of the data (from one format to the other).
Kireeti: Not all objects are defined for RSVP today.
Zafar: The new objects can be defined. There are also other applications for the use of the objects require by PCE.
Dimitri: considering these objects on the PCE does not provide more rationale for considering RSVP as communication protocol between the PCC and the PCE
Kireeti: Well, this is convoluted; we donít have support for all so letís extend RSVP, which is not designed for this purpose.
Mathew: PCC-PCE is a client server protocol. Weíve a lot of other client server based protocols. I recommend taking a look at such protocols.
Concern/Comment on RSVP usage and PCC-PCE communication
JP: Mention discussion of the design team on using RSVP encoding without using RSVP itself
JP: Opinions about future candidates are welcome and the final coomunication will of course be the result of the WG consensus
* Comment/confusion on PCC being a node/client
* Comment agreeing with Dimitri
* Constraint that you can communicate using RSVP today. Agreeing with Dimitri that we should first specify the needs/requirements.
* Comment on not excluding options that are not available today
Conclusion: To Continue on the mailing list
Dimitri: Question on the discovery of the PCE (possibility of proliferation mechanism for PCE discovery).
JP and Adrian.