PCE WG Minutes IETF-66 Montreal July-66 Many Thanks to Sherif Awad and Zafar Ali for having taken the minutes. 2) Working Group progress (Chairs - 10mn): see slides Comment from Jean Louis Le Roux (JL) : PCE Inter-area requirements ID is quite stable and last call is coming up. The policy section has been updated and the ID is ready for WG last call. 3) Update on Manageability Considerations (Adrian - 5mn) Adrian> After last IETF we talked about making a requirement for the IDs to have a Manageability considerations section. We received good feedback. Some resistance, as it makes process too heavy. We are talking to ADs about it in OPS. We have supports from them for this but we need to nail down the "what and how". Next step is to write an ID. Still needs to be discussed since might be to processes heavy. Adrian asked if some one thinks this is a bad idea. No objection raised. 4) Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) - draft-bitar-zhang-interas-pcecp-reqs-01.txt (Nabil - 10mn) Nabil requested for draft to be a WG draft and for WG feedback. JP> This a major rework since the previous revision had several sections that had to be reworded or removed (out of the scope). Now the draft is much better scoped. Show of hand on who read the doc. Very good. Who in favor; Good support. Anyone in opposition? No one opposed. Good support, we will confirm on the list. 5) Update on Path Computation Element (PCE) Communication Protocol (PCEP) draft-ietf-pce-pcep-02.txt (JL Le Roux - 10mn) Major update to this version is addition of the FSM. JL described the FSM. JL Asked for WG feedback especially on the recent updates. JP> We had some discussion on scoping of this document and the goal here is to freeze PCEP document changes at this stage to consolidate the basics before adding further extensions. There are 3-4 on going implementation. We would like to get interops results hopefully before LC. Adrian> The protocol spec is reaching a level of stability, on going implementations may find some holes. Dimitri asked for clarification on usage of P/ I flag. JL> this is clearly stated in the document. JP asked for more discussions on the Mailing List. Richard Rabat asked for some explanation on potential race condition on Two TCP connection requests at the same time. Explanation was provided. Adrian/JP suggested extensive WG review on the next revision. 6) Update on PCE Discovery protocol - draft-ietf-pce-disco-proto-igp-02.txt (Jean-Louis Le Roux - 10mn) JL> Requirement ID is stable and in final stage. JP: There is an implementation. JL requested WG LC. JP asked Ross (AD) for feedback on splitting the document into two: one for ISIS and one for OSPF. Ross> What are the possible deltas; if this doc is 40 pages, will we end up with two doc of 35 pages, each? JP> Delta is small, e.g., semantics are common. We expect two doc of approx. 25 pages each. Lou> There has to be two documents; when we claim implementations for the RFC-es, implementing for one protocol cannot claim implementation for other protocols. Ross> This is a good reason for the split. Makes more sense to Split. JL> Shall we make changes and do the split at the end? Or shall we split now. JP> Splitting at the very end makes more sense. Adrian> Split also makes it easier to do cross WG review easier. Emile Stefan> Split will impact the MIB document and lead to some duplicate work. Adrian> We have done similar split for the GMPLS Signaling Document in the past. Emile still showed concerns. Adrian asked to talk more off-line. 7) Definitions of Managed Objects for Path Computation Element Discovery Protocol (PCEDP) inside a Path Computation Client (PCC) draft-stephan-pce-pcedp-pcc-mib-00 JL> Congestion seems to be for PCE and not PCC MIB modules. Adrian> We should not flood the notification process. Adrian suggested moving textual conventions to a separate document and MIB module so they can be re-used. Emile brought up the point that have a new MIB module RFC for two textual convention might be a bit strange but Adrian pointed out this was fine and more textual conventions are still coming. Adrian asked that since the PCE might discover other PCE's in the same domain why not run the MIB module on the PCE. Emile commented that this scenario was possible and not excluded by his ID. JL commented that a PCC can run the MIB module. Adrian> Have you considered how this should or should not hook in to the IGP MIBs? Emile commented that not really although he was following the IGP MIBS closely and his MIBS are neutral with respect to the IGP protocol. Not requested to become a WG document. JL> splitting in two document should be started out pretty soon. Emile thinks MIB should be mandatory for protocol specifications. Its better done by protocol owner since they know exactly what to watch. JP> You did not ask the WG to take this as a WG doc. It will be a nice target to have protocol document and the MIB document together. No one objected. 8) Update on "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths" - draft-vasseur-pce-brpc-01.txt (JP Vasseur - 5mn) JP> This ID has a long history (presented and discussed many times). Implementation already exists; so only expect the editorial changes. Next steps is to add more details such as path diversity, GMPLS support and manageability. JP requested to adopt the ID as a WG document. Adrian> We will poll the WG (on the list). 9) Update on Inter-Layer Traffic Engineering (Eiji Oki - 10mn) - drat-ietf-pce-inter-layer-frwk-01.txt - draft-ietf-pce-inter-layer-req-02.txt 10) Definition of Virtual Network Topology Manager (VNTM) for PCE-based Inter-Layer MPLS and GMPLS Traffic Engineering - draft-oki-pce-vntm-def-00.txt (Eiji Oki - 5mn) Eiji Requested for WG feedback/ Q&A. No Q&A. JP> There was NOT much discussion on Multilayer on the mailing list. Please review the documents and provide your feedback. Eiji requested for feedback on these ID-es. Adrian> Are there any open issues with the draft or you only need review comments? Eiji> No open issues, just looking for comments. Dimitri> re: VNT This is not in the context of this WG. This group does not define PCE-VNT communication. PCE WG is only scoped to define PCE-PCC Communiction. JP Agreed. Anything related to VNT manager specification is out of the scope of the WG Dimitri> My comment also applies to VNT definition. Before considering it, we need to discuss the associated tradeoff. E.g., an LSR may communicate directly to VNT and NOT via PCE, which is not in scope of PCE WG. It's not good to have multiple architectures. Adrian> Clearly work to mange inter-layer management is done in CCAMP work. The scope here is to see how VNT fits in the context of PCE. Dimitri> If there is an interaction between VNT and PCE, we never scoped it. Eiji> VNT Manager description is in the context of PCE. Dimitri> On slide 6, what do you mean by lower layer setup? Eiji> PCE judges if lower layer path is needed. Same element is needed to setup a lower layer LSP. Dimitri> It's a policy decision; VNT can be triggered by signaling. Eiji> Framework document describes two triggered methods- Triggered signaling and non-triggered signaling. None-triggered signaling is VNT manager. Dimitri> Need to clearify if/ why VNT Manager should be open IF. Adrian> We are not clear if there is a requirement for a protocol. This is an exploration phase. Dimitri> If only exploration, why is this work not in CCAMP? Adrian> Generic exploration is welcomed in CCAMP, but I cannot force anyone to write an ID. Dimitri> MLN requirements also take into account VNT. JP> Full agreement that this is a exploration phase. There may not be any work needed in PCE. 11) Preserving Topology Confidentiality in Inter-Domain Path Computation and Signaling - draft-bradford-pce-path-key-00.txt (Adrian Farrel - 10mn) Adrian> Rich is the editor. Dimitri> On ERO extension, this work is to be done in CCAMP. Adrian> Yes, we need an ERO subobject, which should be in CCAMP. Lou> Your slide still show encryption as an option. Adrian> This is a typo. This option has been dropped. JL> Push model is to improve LSP setup time, but there is a price to pay as we need to push information to all ASBRs. Adrian> Yes, there is an associated tradeoff. Show of hand who thinks this is a good idea. Any objection to work? Some people thinks it's a good idea. No one objected. Adrian> We take it further to the list. Question (?): How do you identify which PCE generated which path key. Adrian> You encode the originating PCE in the path key. 12) Discussion on Policy-Enabled Path Computation Framework policy-enabled-path-comp - (Igor Bryskin, Lou Berger, Dimitri Papadimitrioui (TB C) - 10mn) Lou asked this doc to be accepted as a WG ID. Adrian asked the room, ~5 hands. Adrian asked for any objection/ if someone thinks it's a bad idea. No one objected. Adrian> We will take it to the list. 13) Framework for the Policy-Based Recovery Mechanism in GMPLS Network - draft-lee-ccamp-pce-policy-recovery-framework-00.txt (Young Lee - 10mn) Dimitri> Did you ask yourself why we worked for four years and did not go into usability of the tools? It's because usability is complex and up to the operator. Why should we do it now? No operator needs it and they told us they have their own tools. All these capabilities are already there and provided within the tools. This is outside the scope. Lee> This recovery policy is in the context of PCE and for communication between PCE and PCC. Lou> What is presented here does not modify the framework of policy within PCE. What is being talked about is a possible application of this framework. Whether it's a good one or now these guys disagree. JL> PCE computes path, it does not allocate bandwidth so why would the PCE need this information? Lee> PCE needs to update DB to mark that bandwidth has been assigned. PCE does not know if the signalling request has gone through. PCE needs accurate link information but agreed that some policy might not be applicable to PCE. Dimitri> Would we also need a provisioning policy. We were focusing the work on path computation and path computation polices. Are we entering into application that will make use the PCE. Second point is the policies were just an agreement within a given recovery domain. It's up to the operator to select the recovery policy for the domain. Igor> We are not taking about recovery policies but rather polices that effect path computation calculations. No updating PCE DB. Dimitri> We are assuming some sequences to be assumed from work on CCAMP. JL> This is a good start for discussion on the mailing list. Lou> We should ask service providers who would like to see this as a WG document. Adrian> Ask for room feed-back: 5 liked to see this as a WG document. Issue will be taken to the mailing list.