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