Last Modified: 2004-10-28
|
Path Computation Element BOF (pce)
Wednesday, November 10 at 1530-1730 CHAIR: JP Vasseur (jvasseur@cisco.com) Adrian Farrel (adrian@olddog.co.uk) Minute takers Richard Rabbat, Jonathan Sadler and Andrew Malis Slides and charter available on the Routing Area web site. http://rtg.ietf.org They will be made available at the IETF Proceedings site after the meeting. 1) Introduction, admin, statement of objectives of this second BOF (5 minutes) Adrian/JP Adrian: In the interest of getting to the charter, slides are on the web site. Went over the agenda. No questions were raised. At the mic, please limit yourselves to clarifications. JP: Scope of the Potential PCE WG Specify a set of mechanism for PCE-based path computation of MPLS Traffic Engineered LSPs in the context of a specific application. There is no intent to come up with a new Inter-domain routing protocol. The scope is very clear and is for TE LSPs Based on discussions with SPs, are we trying to come up with a mesh of 1000 LSPs? Answer is no. So we start by trying to find techniques to compute limited number of TE LSPs. We will have 2 or 3 ASes. For the same SP, 4 or 5 ASes likely. JP: Objectives of this BOF - Jerry will go over proposed architecture - Recap different perceived requirements - Agree a proposed charter for a working group 2) Quick summary of the conclusion of the first BOF held in San Diego (5 minutes) JP JP: - Clear statements of requirements from many providers (Infonet, KDDI, AT&T, FT, NTT, MCI) - To be able to compute shortest path in multiple domains - Diverse path computation (intra and inter domain) - Dealing with multiple (complex) constraints - If you have to try to solve a problem with multiple constraints, it is NP-complete. So off-line computation is necessary. - Asked to write an architecture I-D. - Common theme at SD PCE BOF was need for (G)MPLS TE LSP path computation - Need to develop a draft charter - We want to narrow the scope of work Adrian: - Kireeti asks that MPLS be changed to say GMPLS in all instances - Agreement that this work needs to cover MPLS-TE and GMPLS - Asked questions on the CCAMP ML. - Is this an appropriate technology to solve inter-domain TE? - Does it look like it may solve a problem that CCAMP is charted to work on? - Answers were positive, especially from SPs - CCAMP will commit to help provide requirements to a future PCE WG for the inter-domain TE problem space - Comments made on the CCAMP list were that the architecture needs polishing. Comments are good and were expected 3) Problem space: recap of the PCE architecture ID draft-ash-pce-architecture-00.txt (15 minutes) Jerry Ash Jerry Ash: - Main architects are JP, Adrian and Jerry - Good amount of discussion. Will summarize issues discussed on list Terminology: What is a path computation element (PCE) - entity (component, application or network node) capable of computing a network path based on network graph & computational constraints - e.g., PCE computes path of a TE LSP by using TED & bandwidth/other constraints What is path computation client (PCC)? - any client application requesting a path computation by the PCE What is a domain? - any collection of network elements within a common sphere of address management or path computational responsibility - e.g., IGP areas, AS, multiple ASs within a SP network, multiple ASs across multiple SP networks What is single PCE path computation? - single PCE computes a path in a domain Defining multiple PCE path computation: - multiple PCEs compute a path in a domain Defining centralized computation model: - all paths in a domain computed by a single, centralized PCE Defining distributed computation model: - computation of paths in a domain shared among multiple PCEs Assumptions that are made: - PCE may or may not be located at head-end - e.g. nodes on path contribute to path computation (e.g., loose hops) making them PCEs - Path computation may be made by PCE physically distinct from the computed path - The path computed by PCE may be: - complete: full explicit path of strict hops - partial: mix of strict & loose hops (may be an abstract node such as an AS) PCE path computation can be used in conjunction with other path computation models - e.g., inter-AS TE LSP may be computed using PCE in some domains but not others We make no assumptions made about PCE implementation - e.g., could be implemented on a router, LSR, dedicated network server, etc. PCE function is independent of the forwarding capability of the node on which it is implemented The motivation for this are: - inter-area/AS optimal path computation (node has partial visibility) - computation of inter-area/AS diverse path (node has partial visibility) - CPU-intensive path computation/global optimization - backup path computation for bandwidth protection with backup capacity optimization - multi-layer networks e.g. TDM network provides connectivity for client-layer (IP, MPLS, L2, etc.) - absence of TED or use of non-TE-enabled IGP - where the node is outside routing domain (e.g., CE to PE path computation) - where the network element lacks control plan or routing capability Jerry then presented the composite PCE architecture. It is embedded in the router. It could also be external to be queried for a path. It could also be a headend LSR, where you query along the way. We can have multiple PCEs with inter-pce communication. It looks like it's computed by one PCE. He listed some considerations discussed in the draft: - Synchronization - non-synchronized (e.g., PCE makes multiple individual path computations to generate set of paths) - synchronized (e.g., single PCE invokes computations by other PCEs before supplying result to PCC - PCE discovery & load balancing - Detecting PCE liveness - PCC-PCE & PCE-PCE communication - PCE TED synchronization - Stateful vs. stateless PCEs - We need to monitor the state of the PCE A major issue is that of policy & confidentiality - we must preserve confidentiality across multiple SPs - we must ensure confidentiality & security of PCC-PCE & PCE-PCE messages For security & confidentiality: On the PCC-PCE communication - Snooping not a significant issue but requires authentication - might want to encrypt - Spoofing is a very serious issue as it would allow for traffic intercept - must offer strong authentication - protocol is P2P so this is relatively easy - DoS important because of 'centralized' nature of PCE PCE-PCE communication - same as for PCC-PCE, but add confidentiality Confidentiality (protection of domain topology information) - Policy and confidentiality issues must be handled in the information returned by the PCE - Could be done through the use loose routes - PCE encrypts ERO segments - decrypt on entry to domain - Replace ERO segment with cookie, keeping confidentiality. JP: Manageability is probably also something that should be added Jerry: PCE Evaluation Metrics - optimality - scalability - load sharing - multiple path computation - reoptimization - path computation time - network stability - synchronization - between TED & network topology/resource states - speed of TED synchronization - impact of synchronization on data flows There's been a good amount of discussion on the list. He listed them as shown on the slide - PCE should advertise its capabilities (constraints that can be handled, etc.) - PCE request should handle near-disjoint as well as mandatory disjoint - TED can include info from sources other than IGP - Evaluation metrics should include TED sync speed, and impact on data flows - Architecture should elaborate on advantages of stateful PCE and pitfalls of stateful PCE in a distributed PCE environment We've already spoken about TED synchronization speed & impact on the data flows JP: Please give comments about 1st cut at PCE architecture Mark Handley: Which part of the architecture are we talking about standardizing? Adrian: Please wait for the charter discussion as the charter lists this Dimitri Papadimitriou: The name "entity" broadens the scope instead of focusing Appears that we are standardizing an entity, not a protocol. So what is expected to be standardize here? LSR behavior internally is not standardized. Adrian: You are saying if we co-locate a PCE with an LSR there is nothing to do Dimitri: Right ???? (MCI): Please clarify what can be done through dynamic stuff and what can be done statically Hani ???: Does the architecture allow for PCEs to initiate rerouting in the network? JP: Stateful PCE may allow such behavior 4) Summary of existing/future drafts (5 minutes) Adrian/JP JP: We'll go very quickly through the drafts - Techniques for establishing and controlling (G)MPLS LSPs in multi-domain networks - Presents PCE as a possible approach - Procedural and operational considerations for PCE in inter-domain TE - Use of PCE for MPLS Fast Reroute - GMPLS considerations for PCE (multi-region, MPLS/GMPLS) - Generalized Traffic Engineering Protocol - Proposal for communications between LSRs and PCE based on GTEP - Use of ring-based SRLG for back-up path computation Since the last IETF, we had something like 8 new drafts. This shows interest in the area. No time to go over them. Please go to the slides on the web site. Let's go to the key questions. Clear requirements have been expressed by many Service Providers during the last BOF in San Diego, on the mailing list, - Is there agreement on this point? - No dissent was expressed. Can we say that this work belongs to the IETF (under the IETF scope of expertise)? - Scope is limited to (G)MPLS-TE LSPs Alex Zinin: Are there are any comments on JPs question? Mark Handley: Still haven't figured out what we're doing (standardizing). We can't answer this question. JP: The charter slide does provide more definition, but has not been presented yet. So ordering of slides was probably suboptimal. We'll go back to your point during the discussion of the charter. Is there enough interest on this architecture? - No answer Adrian: Let's move on to the charter 5) Proposed charter (15 minutes) The charter is on the slides and separately on the web site. JP: (Picking out key points) The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. The Working Group will determine requirements for extensions to existing routing and signaling protocols in support of such functions as PCE discovery and the secure and confidential signaling of inter- domain paths. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The goal is what kind of protocol we should end up with. We came up with an architecture but it is not the objective to standardize the architecture. Signalling extensions is for a reply/response protocol, not for other changes. Note that the communications protocol between PCC and PCE is not signaling and should not be referred to as signaling. Currently there are 6 proposals on the table for the protocol. New protocols, and existing protocols. Adrian: We'll not standardize all of them. We will have just one protocol. JP: In some cases, it might not be completely desirable to have automatic discovery of PCE to communicate with and otherwise, fall back to policy or static configuration Routing extensions are for auto discovery of PCE. Loa Andersson: On this slide, I can't parse the 2nd paragraph. It doesn't come to conclusion. What do you want to cooperate with other WGs about? JP: It means that we may need to extend OSPF Loa: On the previous slide, there is a very general comment about extending/using routing protocols. Do you include PNNI? I want to exclude LDP. JP: We need to be more explicit Adrian: You're not going to ask us to list all the exclusions? Loa: No, a list of inclusions would be good enough JP: When we come up with new protocols, we come up with protocol- independent metrics to evaluate the protocol. You want to hide internal topology when you provide path computation If you return a loose hop, when you signal the LSP, you may not preserve path diversity We will need extensions to RSVP Need security Arthi Ayyangar: Are extensions for policy, security and confidentiality specifically for diverse path computation? JP: No general requirement. Mark Handley: You talk about specifying techniques. We don't standardize techniques. We do protocols. Don't do protocols or techniques when you don't need to have interop. JP: In some techniques, you have 2 ABRs that are acting as PCEs, you may need communication between PCEs and agreed techniques. Algorithms are not specified but inputs/outputs need to be specified. George Swallow: You should not specify an algorithm but the outcome of the algorithm Choi: Some of the NEs don't have signaling / traffic engineering capabilities Adrian: You're describing a situation where legacy (optical) equipment does not have a control plane, and PCE is able to choose a route in the network on behalf of that equipment. I understand. Kireeti Kompella: Show the interactions and tell what is going to be standardized. You need multiple PCEs for reliability. If I'm a PCC, I discover the PCE, ask it for a path, get it back from it. If I run the PCE as a distributed computation, that's something we don't need to have standardized. Use of distributed or centralized computation should be an implementation detail -- not a standardized item. Please draw a picture to show what is going to be worked on. Adrian: Clearly, it is none of our business to specify what they do when they implement. Distributed computation is within scope. If in multi-AS with PCE to PCE communication, is that distributed computation, and shouldn't it be standardized? Kireeti: The behavior of a PCE should be standardized, but the way that the PCE is used to develop an end-to-end route is not necessarily something that should be standardized. If I take a problem and hierarchically decompose it, then we do need to standardize this. If I'm the one holding the database, another is doing the computation, no need to standardize. JP: What we try to mention is in the PCE id Anna C: If we do have distributed computation do we need to standardize the inter-PCE communication method? Adrian: Somewhat Richard Rabbat: Distributed algorithm (not hierarchical decomposition) is an implantation decision, so it shouldn't be standardized. Alex Zinin: Please continue through the milestones. Adrian: List is where we will start rather than a complete set JP: 1st submit a requirements draft. Kireeti, how about CCAMP? Kireeti: Previously other groups do the requirements and CCAMP does the work; this is the other way around. This discusses inter-area/domain/region work. The other part of the problem is protection. We've been working on both of these so CCAMP will have some requirements. You also need to take input from other WG. JP: How about MPLS working group for P2MP requirements? George: Not quite there yet for P2MP; getting the base thing done so can't specify PCE requirements yet. Doing the unicast case is a good start. Adrian: Not an attempt to force other WGs to do significant work or to deliver requirements. Rather a statement that PCE does not develop requirements. Dimitri: Previous MPLS work was on signalling/routing protocols, not behaviors. PCE work should still not be about behaviors even though computational complexity is increasing. Kireeti: One of the things in the charter I read was mp2mp LSPs. This makes me shiver. Adrian: That was an early version of the charter. It's gone now. JP: Submit requirements draft. We need to start with requirements. Submit draft describing the PCE arch Try to flesh out PCE architecture I-D. Need to define more precisely to explain what we mean by distributed computation. Submit draft specifying communications protocol requirements between PCC and PCe and PCEs. Submit draft of a SINGLE communication protocol for use between a PCC and a PCE and between PCEs. Submit an applicability draft Nice to have an applicability draft describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions. Kireeti: Do we need a MIB? Adrian: If we have a protocol, we must have a MIB. Not immediately obvious that we need one, but that's the rules. Kireeti: Agree that we need management, I'm just wondering if we need a MIB. Adrian: Until the IESG changes the rules, we need a MIB. Richard Rabbat: Does this include Load balancing between PCEs? JP: MPLS PCE Load balancing draft has been created already, need to have GMPLS extensions Richard: Doesn't this mean that PCE needs to provide information on its Computation power, etc? Does that cause confidentiality problem? JP: There are ways around this... Kireeti: We should walk before we run, but I would like to see in the charter the use of PCE for Optical VPNs. Alex: This is the 2nd BOF. We don't normally have more than 2 BOFs. You need to take into consideration whether there is enough interest in this work and whether we have a good idea, whether we have good candidates for this work. Are there any questions on the key questions? There are two questions: Is there a need for a WG? Who believes the WG should be chartered? Many hands raised Are there any people that don't believe there is a need for a WG? No hands raised Hmm. Not all hands raised for those two questions. Who isn't thinking? Some hands Ok. Seems to be consensus in the room. I will take it to the IESG for consideration and we will work on the proposed BOF charter Keep discussion going on PCE mailing list. Find the mailing list for PCE on the routing area web pages. All discussions on PCE will happen on that list. Thanks for coming JP: Thanks. |