Draft of the PCE Working Minutes - IETF-64 - Vancouver, November 2005

Chairs: JP Vasseur, Adrian Farrel	

Thanks to Richard Rabbat and Scott Brim for the notes.

1) Agenda/admin (Chairs-5mn)

2) PCE WG Milestone update (Chairs-10mn)

JP> discussed status of drafts 

See the slides for content.

3) PCE Policy Architecture,
draft-berger-pce-policy-architecture-00.txt (Lou Berger - 10mn)

See the slides for content.

Lou>
- Most of the text could be incorporated in the architecture
reference scenarios; some text could be put in PCE framework document,
- Non exhaustive list of scenarios,
- Looking for more scenarios from the participants

George Swallow> policy will be the dominant part of architecture for PCE to take off.

JP> Policy is certainly a MUST for some scenario, not for all. For example, 
for inter-area: no need for policy, for inter-provider: clear need.

Adrian> on slide 2, slides only cover communication; what do you have to say about discovery?

Lou> policy may guide which PCE to use; discovery has to support policy 
but how this is done is outside the scope

Dimitri> question for JP; you may use it in intra-domain as well

JP> the policy module may not be required in every case; it was just an example

Adrian> fold some of it in architecture and other in framework

Next steps: 

Authors think that they don't want to continue with an independent draft. Suggestion to 
integrate parts within the architecture ID with scenarios in a framework document

4) Path Computation Policy 
draft-bryskin-pce-policy-enabled-path-comp-00.txt (Igor Bryskin- 20mn)

See slides for content.

Igor> it is not requirements, but the goal is to introduce the need for policy 
in path computation (e.g.: one path may require minimum delay; other would require shorted path)

Richard Rabbat> we may need to re-visit last-called drafts

Igor> which ones?

Adrian> true, we may need to do due diligence on pce discovery requirements and architecture ID.

Igor & JP agreed

Lou> we think there should be minimal impact.

Lou> note PDP, PEP and COPS are just examples.

Dimitri> can you tell us how we're going to make progress on pcim?

Igor> we will meet with pcim people

JP> Who has read the draft ? 

10 people have read Igor's draft.

Next steps:

JP> that concludes the discussion; we need to work on framework

Adrian> we talked about updating architecture; we need to look at requirements documents 
and make sure they take policy into consideration. Generate a framework document.

Adrian> consider the scenarios and solutions independently

5) Discussion on the PCE Discovery protocol (Jean-Louis Le Roux - 15mn)
draft-leroux-pce-disco-proto-igp-00.txt

See slides for content

JP> one of the strengths is that you use existing ISIS Router capability TLV and 
OSPF Router Information LSA with no change in term of elements of procedures.

JP> it's fair to make the assumption that it could be easily used

Dimitri> we may need another protocol for extensions?

JL> in inter-area application, it's a good solution

JP> we need feedback from working group

JP> are we happy to use IGP as discovery mechanism?

Igor> discovery can be used to learn about policy

JP> have more discussion on the ML

JP wants feedback from the WG.  Is this useful?  Is it to good to
use the IGP to do that?  

Someone> Does the PCE have to run IGP ?

JL> yes, assumes PCE is LSR or server running an IGP instance.

JP> Who is in favor of *allowing* the use of an IGP for PCE discovery?

Adrian> are we happy to standardize the use of IGPs as a discovery mechanism?  

Igor> using IGP is just one way.

Consensus in the room to start using the IGP for PCE discovery
Next steps

WG document adoption to be confirmed on the list.

6) PCECP discussion and next steps (Adrian)

See slides for content

Lou> it would be very useful to separate out the transport aspects of the protocol 
to the functionality needed; we care about what information is passed back & forth 
from the actual transport protocol; if there are concerns we can fix either.

Adrian> is this the transport area that you're talking about?

Lou> it would be useful if we knew what information we need to carry

Adrian> you don't think the reqs document has this information?

Lou> it is not clear. There are parts that need to be in the solution draft; 
they are in the pcep document all over the place

Adrian> is this an editorial comment?

Lou> no. if we're clear on the problem we're solving, that's great.

Lou> what have we heard from the app area?

Adrian> entire communication with one response from one individual

Lou> take whatever decision we make and tell them about

Adrian> we will communicate with them but not be blocked by them

Lou> Agree

Dimitri> within selection process, would one solution fit all? we need the flexibility 
to use tcp so we can communicate with whatever kind of pce we envision. Wrt to cops, there 
was pushback but no understanding why. Is this a concern of the transactional model?

Adrian> heard 2 things:
	1. applicability-driven question: hard to assess applicability sometimes; a good 
           motivation is that this option is really good for this application; let's not 
           optimize for a particular application
	2. you felt there was a pushback against an option; I invited people to push 
           forward for their solution; but I only heard back once

Dimitri> we can't respond without knowing why there was pushback?

Adrian> I didn't see pushback for any protocol; didn't see support for protocol x except PCEP.

Dimitri> the proposal from Lou makes sense

JL> we try to solve simple problems; not sure we should de-correlate the 2 sections

Adrian> You can look at rsvp at transport protocol

Lou> Application protocol is a better term

JL> I'm not sure we can de-correlate the 2

Adrian> we need to remodel the pcep document

JL> we don't have the state machine; it will be added

Adrian> follow the RFC that explains how to write protocols in following the list

Andrew Dolganow> most of the comments were for pcep protocol to fix

Adrian> if we have an option on the table that fits all of what I said on my slide, 
that would be great

Igor> if we're talking about encryption and authentication, we should be able to 
change the transport without the information we carry

Dimitri> we are all in agreement that we want to work on the solution. e.g. udp vs tcp? 
if we look at the protocol needed in a modular way, we can then make decisions on each module 

JL> we do that already

Adrian> both requirements and solution need to be restructured?

Dimitri> requirement document could have been written another way but focus is solution

Next steps

Adrian> Consensus?  Who would be upset if we chose to progress PCEP with the necessary 
restructuring and recasting that we have  discussed?  

Nobody.  

Adrian> Does anyone want to ask a different question?

No.  

Adrian> To be confirmed on the list.

7) Inter-area PCECP requirement draft (Jean-Louis Le Roux - 10mn)
	draft-leroux-pce-pcecp-multiarea-reqs-00.txt

See slide for content.

JL> Need working group feedback.  Will produce shorter version for end of November; 
move generic requirements to generic I-D.  

Richard> you talk about FRR. Can you make the draft consider GMPLS as well?

JL> yes

JP> by how much are you willing to reduce the draft?

JL> target is reduce to 10 pages

JP> Thanks, please only keep the inter-area specific aspects and move other requirements 
in the generic requirement ID

Dimitri> are these requirements related to the procedure that you will follow? 
Are you going to be path-coupled or decoupled?

JP> decoupled.  

Dimitri> you're expecting that you will get the whole path, not a partial path. 
It has been suggested to use this or that pce if you're going to compute the path

JP> you raise a good point. please open up the discussion on the list.

JP> Is this a good basis to start the discussion?

Substantial number of people raised their hand in support.

Next steps

JP> I see large support and will take it to the list of course 

8) Inter-AS/Provider PCE requirement draft (Nabil Bitar - 10mn)
	draft-bitar-interas-PCE-req-00.txt

See slides for content

Richard> language from RFC 2119 is used very liberally. 

JP> we need to split that ID
1. Pieces that relate to Inter-domain PCE discovery requirements
2. Quite a few sections relate to applicability, not requirements

Dimitri> are we going to put inter-as and inter-provider or not in the discovery?

JP> it should cover both; Nabil and JL would discuss things on the mailing list

JP> can we ask for an applicability ID ? Good time to start working on it?

JL> yes

JP> can you look at your draft and integrate applicability sections in this ID ?

JL> yes

JP> keep some in this document

JP> some could be incorporated in the generic id

Nabil> we decided to be exhaustive then move things to appropriate sections, IDs

JP> Please talk to Lou about policy

Lou> framework should consider all requirements

Dimitri> in inter-as, especially inter-provider, it's difficult to block resources to successfully set up a path

JP> we should probably consider it in an applicability ID

Nabil> there is a requirement for CAC?

Dimitri> yes, but we need to make sure that all pieces fit

Nabil> some of these issues relate to path computation requirements and don't have a home right now

Next Steps

JP> Too early for WG document adoption.

JP proposed to split the documents in multiple pieces:
- Inter-AS PCE discovery (see also with JL)
- Inter-AS policy (see framework ID with Lou)
	- Inter-AS PCECP requirements (should stay in this document)
	- Applicability statement

9) Discussion on inter-layer deployment scenario, similarities with inter-area/AS, 
application specific requirements
draft-oki-pce-inter-layer-req-00.txt (Eiji Oki - 10mn)

See slides for content

JP> who read the draft?
About 20 people raised their hand

JP> who supports it becoming a WG draft?
About the same number

JP> good consensus; we'll take it to the list

10) Cost object
draft-dolganow-pce-cost-object-00.txt (Andrew Dolganow - 10mn)

See slides for content

JL> good to separate rsvp processing and pcep processing.  We have in ccamp another draft 
that is similar in purpose but for the backward direction. may need to put things together

Igor> I object to this work; you may need to come up with a huge number of elements 

Andrew> in most implementations, there is a desire to achieve an optimal path based on cost metrics. 

Lou> you have cost as part of rsvp and pcep (separate). what's the purpose of it in RSVP ? 

Andrew> you need it for path optimization

Lou> having accumulated cost doesn't help you

Andrew> it's out of scope

JP> take it to the list

Lou> we don't define things without use

JP> any work about RSVP belongs to CCAMP, not in the PCE WG.

Andrew> an example application is to refuse a connection if the cost goes too high

JP> a lot of work to be done

11) Next Steps (JP - 10mn)

Final: next steps:

Finalize the PCE architecture ID (with policy) and issue a WG LC

Select a PCECP

JL will respin the PCE discovery ID (with small update to cover policy and inter-domain) 
followed by incremental WG LC

Confirm the use of IGP as one PCE discovery technique 

PCECP generic requirements - JL will respin.  

PCEP inter-area specific - good consensus to adopt as WG document to be confirmed on the mailing list. 
JL will then respin

PCEP inter-layer document - good consensus to adopt as WG document be confirmed on the mailing list.