----------------------------------
PCE Working Group meeting minutes 
----------------------------------

IETF-63 - Paris, France - Tuesday, August 2, 2005.

(Thanks to Jaudelice and Deborah for having taken the minutes)

------------------
1. Agenda (Adrian)
------------------
1) Agenda/Admin (10mn)
2) Progress against milestones (5mn)
3) Drafts (55mn)
	- draft-ietf-pce-architecture-01.txt (Farrel - 10mn)
	- draft-ietf-pce-discovery-reqs-01.txt (Le Roux -  10mn)
	- draft-ietf-pce-comm-protocol-gen-reqs-01.txt (Ash - 10mn)
	- draft-zhang-pce-comm-app-model-01.txt (Zhang - 5mn)
	- draft-vasseur-pce-pcep-01.txt (Vasseur - 10mn)
	- draft-choi-pce-metric-protocol-02.txt (Choi - 10mn)
4) Working Group next steps (20mn)

-----------------------------------
2. Progress against Milestones (JP)
-----------------------------------

1. Submit first draft of PCE architecture document: done
2. Submit first draft of PCE discovery requirements and protocol extensions documents
   (half-done: PCE discovery requirements ID is done)
3. Submit first draft of the PCE communication protocol requirements (done)
4. Definition of the objective metrics (to be done later - more progress required on other
IDs first)
5. PCE communication protocol specification (decision to be made by the WG soon)

-----------------------------------------------------------------
PCE Architecture ID: draft-ietf-pce-architecture-01.txt (Adrian)
-----------------------------------------------------------------

Adrian thanked everyone that contributed to help get this version out
Mainly editorial revisions resulting from Minneapolis meeting have been done (Clarifications, but nothing major)
More a framework, and an architecture overview and deployment scenarios. 
Describes the architectural overview and building blocks
Many mailing list comments and private comments
Not any major substantial changes
Plan to add discussion of policy, will separate exchange of policy info in the PCE communication and the use of policy within the architecture

Question (?): present a functional view as well as component view?
Adrian: currently view point is third dimension

Arthi: policy: how will it be addressed in the document?

Adrian: the current doc will only have something high level. Lou will provide draft text

Igor: when I issue a path request, can I disallow paths requiring distributed computation, 

Adrian: that's something for the computation

Dimitri: is this the only document for policy or we will do something else ?

JP: we need requirements and solution detailed in a separate ID.

Lou: we had discussion, as Adrian said, we will have later a standalone document with more details after we have more discussion in the WG

Dimitri: Other WG have shown that the main pre-occupation for RSVP-TE as inter-domain signaling protocol is the policy at the domain boundaries therefore is it an essential element this WG must address
Adrian: agree

Igor: I disagree with the current definition of the distributed path computation.

In the document:
centralized path computation = computation performed by a single PCE
distributed path computation = computation performed by multiple PCEs

In my opinion:
centralized path computation = path computation that returns all requested
paths in the *explicit* form in the first response, so that no more
requests will be needed neither from the original requestor nor from any
other PCCs for the service in question

distributed path computation is when the original path computation request
is responded with at least one non-explicit path, so that more path
computations will be issued from the original or some other PCCs.

In other words from the original requestor point of view (which is
ultimate user of the PCE service) it does not matter how many PCEs will be
involved to satisfy its request, what is important is how many additional
path computations is needed (0 -centralised
path computation, >0 - distributed path computation).

Plans: architecture is believed to be stable but needs discussions resulting from emails on the list.

----------------------------------------------------------------------------------
Requirements for PCE Discovery: draft-ietf-pce-discovery-reqs-01.txt (Jean-Louis)
----------------------------------------------------------------------------------

Set of requiretments for automatic pce discovery

comments and discussions on the list have been addressed in the new version -01
* multi-area example
* application scenario
* reorganized PCE info to be disclosed (mandatory versus optional)

It must be noted that this is optional in the pce discovery mechanism, not necessarily optional for pce architecture, 
* extensibility section
* security requirements
* PCE capabilities definition is out of the scope (should be in a separate document)

Open issues:
- two stage discovery ? should limit to basic or include more detailed - all as part of this document
- security trust model- need to detail requirements
- need feedback on discovery of pce power and congestion status- should be part of this discovery mechanism or as part of a more detailed requirements phase?

Next steps:

* address open issues

Discussion

Dimitri: the question on one or two stages, for me it's the question how many PCCs will subscribe to the initial PCE advertisement- if only a small group of PCCs at each point in time, then a certain number of sessions, with more detailed information, can be supported. Hence, there is a tradeoff, with a small set, a two stage approach with a dedicated for exchanging more detailed information can be used.
JP: could use a flooding based mechanism

Dimitri: but what is expected then on the use of this information ?

Arthi: It is premature to talk about solution. Do we have a sense of what direction we might be taking? On the section on scalability: number of pce pccs are factors but also should consider the load on a pce.
The details that you have might not be relevant to a PCE.

Dimitri: should say if the info is of interest to all the PCCs or not

Arthi: I'm less concerned with the PCE if the PCE is itself a PCC

Igor: Flooding is good, but it has problems: scalability and security. You still want to know the capabilities of pce so you may need to establish a session.

JP: we may now be discussing solutions on how to do basic capabilities and additional capabilities

Igor: we will need this discussion though

JP: I don't see this as pce discovery, this is a capabilities exchange

JL: Do you have an idea of a communication protocol

Igor: It should not be flooding.

JL: For general discovery we should use flooding.

JL: You must be able to control to which pcc you will be disclosing the information: all pccs in an area, etc.

Adrian: the draft though today does include some capabilities

Dimitri: can you provide more detailed requirements on the dynamics needed for these capabilities?

JP: A limited number of capabilities such as the congestion parameter is likely to be dynamic

Richard: propose discuss possible solutions over email exchange, even though it's not to be included in the requirements, the discussion helps to understand

Arthi: agree should discuss to an extend some of the solutions

JP: thanks to quickly resolve the set of open issues. The draft should then be ready for Working Group LC.

------------------------------------------------
PCE Communication Protocol- Generic Requirements
draft-ietf-pce-comm-protocol-gen-reqs-01.txt
(Jerry)
-----------------------------------------------

Generic requirements applicable to all PCEs

application-specific requirements to be addressed in separate requirements documents

A table with a summary is included.

Open Issues

* requirements for less constrained path requests/response
* requirements for responsiveness & session maintenance
* detailed requirements on throttling messages under overload
* specify 'boundary' numbers on scalability
* clearly state supported policy models & corresponding requirements/implications
* avoid feature creep
* need to progress application-specific requirements
* PCE  protocol proposal needs to identify how generic & application-specific requirements are met

Discussion:

JP: Detailed scalability issues are related to implementation.

Adrian: we need a range as don't want protocol to provide the limit

JP: on the less-constrained path computation topic, we don't have a consensus yet, we should have a separate document

Arthi: we had a discussion in the pwe group that there may be requirements for pce

Adrian: by us splitting the document between generic and extended reqs (more application specific) we could handle this better

Arthi: also though may not be in scope

Adrian: yes we should say if it's out of scope

Arthi: Some new requirements may come up for PCE, we need to have a plan on how to address that.

Adrian: The document is extensible.

Arthi: We might see other consumers of PCE

JP: Sure and the protocol should be designed to handle extensions so as to meet new requirements but we may need to recharter

---------------------------------------------
PCE Communication Protocol Application Model
draft-zhang-pce-comm-app-model-01.txt
(Zhang)
--------------------------------------------

* how to avoid contention with TE link fails
* how to load balance among PCEs
* how to update the PCEs about resource allocation

JP asked who has read the draft: good show of hands

Adrian: rather than saying this is the way forward, would prefer emphasis on what are the requirements

Li defeng: this draft addresses a way to ...

Adrian: yes, this draft has requirements on an implementation, would like first to see top level requirements and architecture

Igor: one of the requirements for the protocol is getting updates, etc, 

Adrian: first need requirements

Igor: my view this is not a signaling protocol, not rsvp, we shouldn't go thru the process of using a signaling protocol

JL: I have a major concern on scalability with the draft's approach, one major bottleneck is on the PCC-PCE signaling, we should minimize the signaling, the objective is to have distribution to reduce this, whereas this draft re-introduces this overhead for synchronization. You are redefining the concept of cluster. Why not rather use a single PCE and clusterize the PCE engine?
One major bottleneck on the PCE architecture is the pcc-pce signalling. To ensure path computation, reduce the number of path computation requests received by a pce. 

Author: it does not consume much bandwidth.

JL: It is not a problem of bandwidth but communication overhead.

JP: I have similar concerns. Have you tried to evaluate what would be the overhead in term of extra signaling due to this mechanism? One way to roughly evaluate would be by using simulations.

Adrian: best for us to discuss over email to provide adequate time for the discussion.

-------------------------------------------------------------
Path Computation Element (PCE) communication Protocol (PCEP)-
draft-vasseur-pce-pcep-01.txt
(JP)
--------------------------------------------------------------

PCC-PCE and between PCEs communication

There were two proposals in the past which were discontinued and a completely new protocol has been designed (PCEP) highly driven by the PCE WG requirement document. Chief objective was to make it extensible to cope with future requirements.

Major changes from 00 to 01:
* rewritten for clarity
* few sections removed
* new section on protocol model
* added security consideration
* very rough manageability consideration section added (to be fleshed out)
* two new objects defined

Unique communication protocol for PCC-PCE and PCE-PCE.
Summary: pcep meets most of the requirements.

Open issues (need inputs from the working group)

* Objective functions needs to be defined (next revision)
* Protocol recovery: requires more detailed requirements
* Policy: requires more discussion

Discussion

Bijan Jabbari: What was the reason for TCP?

JP: reliability and flow control. TCP was a very good candidate for that.

Bijan: Question of scalability of TCP.

JP (vendor hat): We do not see any scalability issue with TCP. Current TCP implementations can support a very high number of TCP sessions.

Richard Rabbat: You are creating a new protocol. Did you do an analysis on existing protocols and reasons for not using them?

Adrian: yes we did , but here formal requirement for the WG to take reqs to other groups to ask if have anything, so this draft progressing depends on answer.

Lou: Many protocols have been worked on. Instead of reinventing the weel, why not use one already existing. What we are doing here in path computation is a new application, but session application (keep alive, discovery) have been resolved before and it would be great to concentrate on what is related to pce.

Adrian: great if we can learn lessons

Lou: and reuse

Adrian: agree

Dimitri: agree as Lou said

Lou: session management, keep alives, etc have been done already

JP: the question is, is there anything specifics to PCE that we need a new protocol

Dimitri: With a new solution we will have to pass all the stages the others have passed to achieve a robust solution. Therefore, protocol solutions already developed by other WGs should be considered and evaluated wrt requirements provided by this working group so as to concentrate on the PCE specifics

JP: That's why we have the question here. 

Adrian: yes, this protocol in this draft has not been selected

Bijan: If this is IP only, was DNS discussed?

Adrian: this is IP only

Bijan: have we looked at DNS ?

Adrian: bring it to the list to suggest

Lou: Comment on need to go back and use an existing mechanism whenever you can.

JP: yes, whenever you can.

Loa: if we have TCP, then we have a basis, to do more, we need justification,

JP: agree

Jerry: can you include what is met and not met on requirements into the draft ?

JP: ok, will do.

Jerry: Jerry: if we do not have a list of requirements *including application-specific requirements*, how can we proceed *with pcep*?

JP: PCEP has been designed to be easily extensible to cope with future application-specific requirements.

Yakov: Comment on the need for protocol specific keep-alive: we need a PCE specific keep-alive protocol since TCP will not take care of it.

JP: fully agree.

Lou: You need keep-alive (TCP-based solutions already have keep-alives). Find out what's the requirement, then lift the existing solution.

Lou: my comment is to look at experience e.g. if need keepalives, it's a mistake to look at this again without considering previous work, and do all the requirements all over again, should look at existing protocols, transaction semantics

Adrian: yes, persistency should be addressed in the requirements

Sue: keepalives in a protocol is needed in addition to tcp, need to pay careful attention to the state machine interaction between the two - pcc-pce. Need to ensure handle failure scenarios, noticed missing here some of what protocol has to solve, should feed back into requirements

JP: Sometimes you do not want a permanent session, and sometimes you do. Do we need two modes? 

Adrian: question should be asked to the requirements team.

JL: we should be more flexible and support both request and permanent as it will depend on the request, and number of pces to maintain, may have a full mesh and may not want to maintain a permanent

JP: this is what we heard: may only need on request, other times will need permanent, so may want both modes, and negotiate upon session establishment.

Adrian: when doing the solutions and have a question, should take back to the requirements folks

JP: Less-constrained path computation aspects will be removed from this draft and be worked out in a separate ID.

------------------------------------------------
Path Computation Element Metric Protocol (PCEMP)-
draft-choi-pce-metric-protocol-02.txt
(Dipnarayan Guha)
------------------------------------------------

PCE metric protocol (PCEMP): generic routing and path computation protocol targeted towards inter-domain pce peers.
Reviewed slides
JP: we encourage you to provide simulation results to the mailing list it will help

No discussion

Comment from Igor: neither of them satisfies the requirement of the extensibility. Introducing new constraints, objection functions, diversity types, etc will be extremely painful. Hence a meta-language style protocol should be considered

------------------------------
working group next steps (JP)
------------------------------

- new revision of the PCE architecture ID to be published soon (WG last call soon after this ietf)
- new revision of the generic pce communication requirement ID (WG last call soon after this ietf)
- submit a new ID for pce discovery protocol extensions (minor protocol work only)

Start application-specific requirements IDs for PCE based computation

*Inter-area: Jean-Louis
*Inter-As: Raymond, Nabil

JP: note that such ID must be PCE-specific (take into account RFC4105 and inter-as requirements ID produced by the TE WG).

Adrian: WG to decide on which pce communication protocol solution to pursue 
- two proposals presented
- selection of one solution as a basis now does not imply rejecting good points of other solution nor accepting bad points of selected solutions. 
If pick one, that does not prevent us from taking the best of other one also, and also other ietf protocols. email will be sent to the application ADs to ask their input.

- New ID on the less contrained path problem comprising the requirement + solution

- Need to verify the solution model for inter-domain pce with CCAMP, MPLS working groups

Adrian: other application specific requirements IDs (interlayer, p2mp) should continue their work, just realize other work needs to be done first:
	inter-layer: Eiji, Kenji
	P2MP: Seisho (currently out of scope of PCE WG charter)