Subject: [Pce] PCE WG meeting: draft minutes

From: JP Vasseur <[email-masked]>
Date: Fri, 18 Mar 2005 11:04:17 -0500

Hi,

Please find below the draft minutes of the PCE WG meeting. Let us know  
if you have comments:

A special thank to Jaudelice and Zafar for having taken the minutes.

PCE WG meeting minutes – IETF-62 - Minneapolis
---------------------------------------------------------------

CHAIR REPORT
----------------------

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

Questions raised:
------------------
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)

message sent to ITU-T about PCE working group. What is in the ITU-T?
Audience member said that G7715 on ITU-T has similar function.

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: Re; global optimization, what is responsible?

JP: Evaluation Metric is to be used for this purpose.

Igore: 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 god start.

J. Sadder: Yes, there is similar work pursued at ITU-T.

JP Pooled 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).

Remaining issues:

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?

Questions raised:
---------------------

Kiretti: Discovery of PCEs: better rely on PCE-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 the overload problem before hand.

Concern: Enumeration of the set of minimum requirements. Right now it
shows an enumerations of possible solutions. Need to focus on minimal
requirements.

JP: 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).

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 minimum  
requirement 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.

JL: 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 Rabbot: Not all ABR are PCE in your Figure.

JL: It is just an example case used for illustration purpose only.

Richard Rabbot: How did you come up with 60 second requirement?

JL: 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?

JL: Yes.

Dimitri: If today a router may be overloaded and we don’t do anything  
specific, should we worry about PCE overloaded cases? 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.

JL: 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

Questions raised:
----------------------

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: on Head-less optical nodes.
GMPLS requirements from CCAMP.

Conclusion: Needs more discussion on the list. This document will be the
basis of the work.

Other discussions:
-----------------
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 flash 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 tent 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 design for label exchange and not PCC-PCE  
communication. What about transport.

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.

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
proxification mechanism for PCE discovery).

JP and Adrian.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 18 Mar 2005 18:34:24 -0000

Thanks to the note takers and to JP for editing.

Seems to be some duplication.

Comments in-line.

Adrian

> PCE WG meeting minutes – IETF-62 - Minneapolis

[SNIP]

> Audience member said that G7715 on ITU-T has similar function.

"Audience member" was Jonathan Sadler as shown when identical point
appears in the minutes later.

[SNIP]

> Igore: Similar comments for stateful vs. stateless.

That's "Igor"

[SNIP]

> ITU-T is completed. We think SG-15 would be a god start.

Or maybe a "good start" :-)

[SNIP]

> JP Pooled the audience for the Architecture document.

"Polled"

[SNIP]

"Kireeti"
I think he said "PCE-PCC communication"

[SNIP]

> shows an enumerations of possible solutions. Need to focus on minimal

I think that this was Tony Li as when the identical issue appears later in
the minutes.

> JP: Reminder that the draft is in its first version.

That was me (as when the identical point appears later in the minutes)

[SNIP]

> Richard Rabbot: Not all ABR are PCE in your Figure.

That's "Rabbat"

[SNIP]

> what we have today, and when it comes to signaling we tent to have such

"tend"

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 19 Mar 2005 10:47:26 +0100

hi jp - some edits/comments in-line:

JP Vasseur wrote:

> 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
> An element performing optimal computational might take infinite time to  do
> so.  Concern about delegating the distributed control plane  responsibility
> to PCE.
> 

-> replace by "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.

-> add "dimitri: but these are not evaluation metrics in terms of 
computation results these are specific metrics for evaluating the 
correct behaviour of the system"

note: if i well remember you agreed with this - please confirm

> 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

-> replace "correct ..." by "correct architecture design is required to 
address the overload problem before hand"

> overloaded system. General problem of the overload should be solved at  

-> adding the following note here: 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"

> specific, should we worry about PCE overloaded cases? 

-> replace by "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  

-> question was "dimitri: what about the reachability of PCE location(s) 
for non-IP terminating nodes"

i think that the below corresponds to the reply of Adrian that did point
out to the GMPLS requirements from CCAMP WG

> 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

-> please replace the above by:

"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)"

> applications for the use of the objects require by PCE.

-> add "dimitri: considering these objects on the PCE does not provide 
more rationale for considering RSVP as communication protocol between 
the PCC and the PCE"

---

From: JP Vasseur <[email-masked]>
Date: Sat, 19 Mar 2005 10:28:46 -0500

hi Dimitri,

On Mar 19, 2005, at 4:47 AM, dimitri papadimitriou wrote:

>> Please find below the draft minutes of the PCE WG meeting. Let us  
>> know  if you have comments:
>> ---------------------------------------------------------------------- 
>> -- ----
>> Dimtri asked a question on stateful vs. stateless PCE in the  
>> document;  how feasible is stateful PCE? Is it reasonable to assume  
>> stateful PCE?

will update

> note: if i well remember you agreed with this - please confirm

I indeed agreed on the fact that it is out of the scope to make  
algorithmic evaluation.

Thanks for your comments.

JP.

>> Adrian: ITU-T also requires similar functionality. Liaison Statement  
>> to  ITU-T is completed. We think SG-15 would be a god start.
>> ---------------------------------------------------------------------- 
>> -- ------------
> -> replace "correct ..." by "correct architecture design is required  
> to address the overload problem before hand"
>
>> overloaded system. General problem of the overload should be solved  
>> at  the root (architecture).
>
> 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  
>> JL: 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.
>> 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.
>> JL: 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.
>> ---------------------------------------------------------------------- 
>> -- ----------
>> Zafar: Yes, there are cases where unsolicited PCE to PCC  
>> communication  is required.
>> 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.
>> 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.
> -> question was "dimitri: what about the reachability of PCE  
> location(s) for non-IP terminating nodes"
>
>>  on a reliable transport? TCP is reliable, is it a candidate? are  
>> among  the question charter addresses.
>> what we have today, and when it comes to signaling we tent 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.
>> 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.
>> provide information encoded in RSVP format to minimize useless  
>> copying  of the data (from one format to the other).