PCE Working Group Meeting - IETF-65 - Dallas - March 2006 Thanks to Jaudelice, Adrian and Rich for the notes. Working Group progress (JP Vasseur) ----------------------------------- See WG Chairs slides. Manageability Considerations (Adrian Farrel) Proposal: Manageability consideration sections should be mandatory in all WG I-Ds in the same way that security considerations are. Motivation: - Manageability is left till the last thing - Retrofitting manageability is difficult draft-farrel-rtg-manageability-requirements-01.txt RFC 3933 (Allows for IETF Process Experiments) Proposal (not necessarily in order): - Convert existing manageability I-D into a process experiment (RFC 3933) - limit the scope to the PCE WG - get support from: chairs, WG, routing area ADs, IETF - run the experiment for current milestones - report to the IESG and routing area ADs at the end of the period - Some I-Ds already include extensive manageability consideration sections (e.g., architectural I-D) - manageability is important to the pce anyway (maybe it is not such an overhead) - more work for reviewers and chair to make sure there is conformance - Better end product ? : It should not be a gating item. WG consensus will do it. It should not be strong as we have to follow: think of security sections: the opt out was there. Every draft has to have a section but one can say that they do not address it. Bill Fenner: OK with the proposal Lou Berger: not compelling Alex Zinin: Let people do it. Then once you have the documents you can demostrate that it can be useful. By setting the good example, you can bring it to the wider community and say "maybe we should adopt it in a wider context". Adrian: I take your point and this is why I am bringing it to the WG. If the WG supports it, then the authors and editors do support it. Alex Zinin: It should be there not because it is mandatory but because it is important to pce JP: Asked for comments from providers. Jerry Ash: Support. The experiment should justify the change. No specific support from room No objections Next steps: WG needs to agree in principle. More on the list. JP: invited more people to give input on the list. Adrian: more input either privately or on the list. 3) Inter-area PCECP requirement draft - draft-ietf-pce-pcecp-multiarea-reqs-01.txt (Jean-Louis Le Roux - 5mn) Main changes: - draft was adopted as WG document just after vancouver meeting, - new co-author, - section related to various pce based inter-area path computation approaches were removed - moved all generic requirements to generic ID. - added a requirement on the notification on area crossing - added a requirement on area recording - clarified requirements on inter-area diverse path computation - rewording for clarity Next steps: - quite stable draft, WG feedback required. - New revision by end of April. - WG last call then ? - Time to work on the protocol solutions Comments -------- Lou: want to handle policy at this time JL: OK JP: Asked for WG feed-back on the next revision before WG last call JL: Aim to receive comments by the end of april to be included in the last revision ?: Had a brief off line conversation with Nabil. It would be good to consolidate the policy discussion so they cover both inter area and intra area cases. JL: clarified what the person meant ?: There are other policy documents in the group and need to make sure there is alignment between them. This person(?) is a co-author of another document and would be happy to work with them towards that goal. 4) Discussion on the PCE Discovery protocol - draft-ietf-pce-disco-proto-igp-01.txt (Jean-Louis Le Roux - 5mn) IGP extensions for pce discovery Main changes: - draft was adopted as WG document just after vancouver meeting, - new co-author, - clarified the definition and applicability of pce preferences, - Added protocol elements and procedures for the advertisement of pce congestion status, - rewording for clarity, - new TLV defined: PCE status TLV JP: clarified the congestion duration. JL: agreed. Next Steps: - need to work on the advertisement of supported link/path constraints, - advertisement of supported objective functions (minimum cost path, widest cost path computation), - WG feedback is required Comments -------- JP: invited comments on the new item Adrian: On the congestion - how many advertising PCE ? JL: 5-10 PCEs in an area Adrian: it is not an extension that every node has to advertise. Another point: include some recommended behavior that the PCE "should" follow in the draft Adrian: advice/recommendation for dampening and thresholds JL: Started discussion related to hysteresis behavior and IGP dampening... Adrian: It is a normative test and you need it (at least SHOULD) JL: clarified what was needed to be included. Recommended behavior. JP: What is the plan for the new version JL: Waiting for feedback. New version by the end of May. JP: It would be useful to send an email summarizing the three new items for which action is required 5) Discussion on the need for Inter-AS PCE discovery (All - 10mn) JP: 10 min open mic: Do we need to have protocol extensions to discover PCEs across multiple ASs? Background: Some service providers said static configuration is good enough (no need for discovery mechanism) and others said that it was necessary. Adrian: Can you explain why you are only talking about inter AS and not inter area? JP: because the intra-area is already resolved by the igp. JL: PCE discovery draft there are few lines that point out the requirements for inter-as PCE discovery. Two cases: 1. There is a requirement at least within a single service provider: security issues 2. PCE discovery across service provider networks: static discovery would be enough. Raymond Zhang: wants to see this for ASs in the same SP: will start on a draft Nabil: also agrees with the need for it. JP: Asked whether JL would be interested in working on new ID and flash out the requirements. JL: Agreed 6) Inter-Layer Traffic Engineering - Applicablity draft-oki-pce-inter-layer-app-00.txt Supplements the generic PCECP requirements Became WG document in Vancouver Main changes: - Text related to the applicability of PCEs for inter-layer path computation was moved to applicability draft. - New requirements on control of the type of path to be computed were added. - section 5.1.2: new requiremetns on control of the type of path computed Next steps: - start work on interlayer protocol extension for pcep Comments -------- JP: need to get more feedback before working on extension. Have not seen much discussion about this draft on the list. -draft-oki-pce-inter-layer-app-00.txt (Eiji Oki) Inter-layer path computation models - Single PCE inter-layer path computation - Multiple PCE inter-layer path computation Inter-layer path control models - Higher-layer signaling trigger model -Cooperation model between PCE and Virtual Network Topology Manager Next steps: - Adopt as WG document ? - Existing protocol evaluation to see whether protocol extentions are required to support inter-layer path control models - Request for feedback Comments -------- JP: Usually applicability ID comes later on, when we have more experience. Suggestion: rename it as a framework document. JP: It is a big piece of work and need more feedback from the WG. Suggestion: First rename it and make it a framework document, then send an email to the list to request more comments JP: Polled the room for who has read it: Roughly 20 people in the room have read it. JP: Polled the room for who thinks it is worth pursuing: Roughly the same number of people think it is worth pursuing it. JP: Suggestion: rename it and ask for feedback. At the next IETF meeting decide about considering it for WG document. 7) Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) - draft-bitar-zhang-InterAS-PCECP-reqs-00.txt (Nabil Bitar / Raymond Zhang - 10mn) - Was submitted in ietf-64 vancouver - Addressed all PCE-related requirements for inter-as applications In IETF64, it was decided to break up that draft into existing or new drafts: - Path computation: inter-domain path computation applicability (in progress) - Discovery: Discovery draft . Only dynamic inter-AS PCE discovery requirements were moved to discovery draft . Static PCE discovery still has no home - out of scope of PCE discovery draft - Policies: attempt to consolidate generic policies within the policies draft by Berger et. al. but that was not a requirements doc - Inter-AS PCECP requirements as a new draft: draft-bitar-zhang-interas-pcecp-reqts-00.txt - Move generic PCECP requirements in the draft to the generic PCECP requirements Updates/Open Issues on the new draft: - Wordings on a few sections on inter-AS PCE path computation requirements do not belong here - The relevance of section 4: application scenario as it relates to PCECP - Inter-AS PCE implementation specific wordings : should not be part of this draft - Be consistent with RFC 2119 Next steps: - incorporate all comments on draf-01 - notify PCE, MPLS mailing lists to invite comments - at the next WG meeting, ask for draft to become WG document Comments -------- JP: there are a lot of very important components in this draft. Suggest the same approach as inter layer: Framework document and maybe later on, start to work on applicability ID. Some parts that are more implementation specific and it is dificult to decide where it should go: sometimes it does not have to be standardized. Nabil: Whatever was intended as applicability statement will be put as generic interdomain path computation framework document. JP: Still need some simplifications Nabil: In progress 8) Path Computation Element (PCE) communication Protocol (PCEP) - draft-ietf-pce-pcep-01.txt (JP Vasseur - 10mn) This ID moved to WG document status right after Vancouver Main changes: - editorial: must, may and other semantic inconsistencies - Initially introduced two modes: permanent versus per-request. Actually not needed. Removed. - Close message + close object added - Dynamic negotiation of the keepalive and deadtimer with support of assymetrical values of keepalive and deadtimer - Introduction of two bandwidth object types (for reoptimization) - Delay object removed and replaced by a METRIC object - SVEC object: added to ability to send synchronized path computations in multiple PCReq messages - The B and N bits of the LSPA object have been removed - Support of optional suggested values in case of unsuccessful path computation - Changed the end-points object to be optional since there are path computation procedures where end-points are unknown. In further revision we may want to have a source (mandatory) and destination (optional) objects? Next step and Open issues: - new ID related to the use of non PCEP objects in a PCE context: PCEP code points and contextual adaptation - Add an FSM (soon after this IETF) - Handling of PCEP version number - Editorial comments on rev-01 received on the list, to be addressed. - Do we want to add an OBJECTIVE function object? (e.g. minimum cost path, widest path, minimize the sum of path costs, etc.) Comments -------- JL: you mentioned the case where you include a specific way of treatment for protection object... you plan to do a better path request on single request case, because there could be some applications where it would be better to compute the paths in a single way to optimize the route for both paths. JP: two examples: I want you to compute the request for 10M from a to b and another for 15M from c to d. They are not related but need to be computed at the same time for optimality; and the second case: they are correlated. Dave McDyson: objective function needs normalisation of parameters: *do* need objective function object Jerry Ash: Identified requirements which are not met? JP: Appendix ? JP: Asked whether it should be an appendix to the specification? Adrian: No, it should be on the main document. JP: Want to limit to what is the basics of PCEP, though people would like to see other things in the draft. Draft would roughly be 50 pages. With FSM, 60 pages. Andrew: Once we have the FSM, duplications can be removed. Expect the document to have 30-40 pages once done. JP: Don't think so but the ID is not so big compared to usual protocol spec. Dimitri: is it size per se or specific unneeded material Adrian: no issue with size if needed, but must remove unneeded material. Perhaps good to have it now, but must take it out as we progress 9) A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path draft-vasseur-ccamp-brpc-00.txt (JP Vasseur - 5mn) History: presented at IETF 56 Scenario 1: per-AS TE LSP Path computation Scenario 2: distributed path computation server Where does it fit in the charter: - It is about inter-domain TE LSP path computation, which belongs to CCAMP but using PCE discussed in the PCE WG - Proposal: discuss this ID in PCE with a review of CCAMP Adrian: It is an application of PCE, so it belongs in PCE but CCAMP should hear about it. JP: The aim is for an informational draft Summary - requirements for optimal (shortest) constrained inter-domain path and inter-domain diverse paths - draft-ietf-ccamp-inter-domain-pd-path-comp does not address these requirements - no changes in term of procedure compared to scenario 2 - defines a procedure allowing .(1) for the computation of such optimal path and .(2) diverse inter-domain paths using a PCE-based path computation procedure Next steps: - More discussion on the list - Is there a need for OAM/MIB to troubleshot procedure - Adopt as WG document? Comments -------- Jerry Ash: How do you compute a path if you don't specify the end points ? JP: I'll get to that later in the presentation Dimitri: Clarified that the 'next steps' slide is about the draft. What needs to troubleshooted? JP: The document defines the procedure to compute a path. you may need to ping all the pces involved prior to computing the path. Confirm that PCEs will be capable of computing the path. Dimitri: PCC delegates the request to PCE. there is nothing maintaining a PCC to PCE relationship to troubleshoot JP: Just to make sure that there is no downstream PCE which is broken and cannot compute the path. Would you need to do that aprioiri? Just a question for the WG? Dimitri: Why is it specific to this model? Is there something specific that needs to be troubleshooted? JP: No. Agree. Nothing specific about it. Could be generic to Multi-PCE path computation procedures. Jaihyung: there is an assumption that AS sequence is decided in advance JP: yes and no. If you know the sequence of ASs/PCEs you can impose it but you can also discover next hop AS (i.e. not imposed) Jaihyung: if sequence is not decided then how get to next AS? JP: example: if you have a mesh and three AS paths to reach the destination. You may compute all paths sending parallel requests and choose the optimum. You can rely on some other mechanism to discover the next pce. Dimitri: how do you know you got the right PCE? JP: You just need to know one PCE per domain with BRPC. The PCEs will work together to find a path across domains Dimitri: You make the assumption that you will have always a PCE associated with ASs and a discovery process needs to be completed to be achieved. How do you guarantee it? It may depend on the discovery policy. Need to add conditions. JP: It may fail. Will add a paragraph to explain it. JL: JL good I-D but there are pieces of protocol elements that are missing: don't see the need for VSPT object (only encode the destination address). Why not rather use the end-point object? the source address could be a new address (related to Jerry Ash's comment). It makes more sense to rely on the end-point address. Why not use flag to say inter-as path request? JP: We could indeed re-use the END-POINT object. This was one option. JL: Do you plan to address inter-area requirements (area crossing indication) in this draft? JP: Yes, it makes sense to address it. JL: First part of the document is very good, need to develop a bit the protocol extensions JP: Agreed. Adrian: more discussion and progress needs to be done in the draft. Decide about wg document later. 10) Protocol Extensions for Signaling Confidential Path Segments in Multiprotocol Label Switching Traffic Engineering - draft-rbradfor- ccamp-confidential-segment-00.txt - (Rich Bradford - 10mn) CPS-ID preserves optimal/diverse paths without compromising confidentiality. Why PCE WG? - Adds Privacy to complete EROs returned by PCE - Allows PCE to return Diverse Paths without discarding the details which make them diverse (i.e. Loose-Hops) - Current ID may need to be split into CCAMP and PCE specific drafts. Two Alternatives for how CPSs are Encoded?: - Path Key SubObject (PKS) .PCE replaces the CPS with a key. .PCE maintains database tokens .LSR Queries PCE during LSP Setup. - Private Route SubObject (PRS) .PCE (or LSR) Encrypts the CPS .LSR Decrypts the CPS during LSP Setup Next steps: - Is this of interest to the WG? - Continue with both solutions or focus on one? Comments -------- JP: Polled how many read the draft and how important the WG thinks it is. Good support (20 have read, 20 in support). JP: Suggested to send an email to the list seeking for comments and wait for feedback on whether we should support 1 solution (which one ?) or both. 11) Policy-Enabled Path Computation Framework - draft-bryskin-pce- policy-enabled-path-comp - (Igor Bryskin - 10mn) Changes since Vancouver: - Large piece of first document was incorporated into draft-ietfpce architecture-04.txt - Rest was merged with second document: draft-bryskin-pce-policy-enabled-path-comp-00.txt The merged document contains - Background: motivations, representative scenarios, usage cases - Requirements for policy enabled path computation framework - Policy enabled path computation framework components - Introduction of PCPIM - Policy application and configuration scenarios - Inter-component communications - Name change: Policy-Enabled Path Computation Framework Next steps: - Path computation policy information model .PCIM sub-model .Extension of QPIM - Detailed specification of functions performed by each framework component - WG document? - Invite volunters with experience on policies. Comments -------- Richard: Thinks it is important and supports it. Dimitri: Asked how far do we want to go with this work? Adrian: Those who are happy to say that this is important should volunteer to help. JP: Asked for show of hands if consider it important: good support. Lou: Clarification on the "show of hands" meaning. Does that mean that this draft will be the foundation for a WG document? JP: Yes but work may be needed 12) PCC-PCE Communication Requirements for Point to Multipoint Traffic Engineering - draft-yasukawa-pce-p2mp-req-00.txt - (Seiho Yasukawa - 10mn) - No reason why P2P should use PCE and not P2MP - P2MP is a hard computation: Off-loading to PCE may be appropriate - Multi-area/AS issues are equally applicable Next steps: - Review and opinions from WG - Discussions with P2MP implementers - WG document? Comments -------- Dimitri: When you mentioned full specification of P2MP trees (multi-AS case). How do you know that you will have all information for the tree based on the dynamic registration that you can have to the end points? it means that the PCE will have to maintain information about who just joined the tree or are willing to join the tree and synchronize... Adrian: It is not intended to say that we must specify the full tree. It is intended to say that the protocol must support specifying it if we know it. These are requirements on the protocol not on the application of the protocol. For example, in a single domain you would have the whole three and you would want to be able to specify, in the protocol, the full tree. Dimitri: The destination is also registered as part of the PCE information. It's a requirement that should be processed ? Adrian: The request has to handle multiple destinations. Dimitri: Re-stating the question: In the context of P2P LSPs, do we assume that all P2MP LSPs that you want to compute here.. do you need to register all the destinations or can you add dynamically? Adrian: Yes you must be able to specify a bunch of destinations in one request and yes you must be able to dynamically add a destination. JL: You have a session related to path modification but you may want to expand it. When I want to add a leaf in the three, shall I send a request for P2P path or P2MP path? It would be good to clarify. Seiho: Will clarify and include more details. JP: need more progress on open items first before considering as WG document. Dimitri: Need corresponding signaling mechanism. The details need to be specified. JP: Continue discussion on the list. Read through "Next Steps for the working group" slides.