Inter-AS PCE Requirements draft-bitar-zhang-interas-PCE-req-01.txt Nabil Bitar (Verizon) Dean Cheng (Cisco) Kenji Kumaki (KDDI) Raymond Zhang (BT Infonet)

Objectives n Illustrate the application of inter-AS PCE via use cases n Extend on the requirements defined in draft-ietf-tewg- interas-mpls-te-req- 09.txt for inter-AS TE as they apply to PCE Interoperability with existing inter-AS TE mechanismsInteroperability with existing inter-AS TE mechanisms Path Computation Element Communication Protocol (PCECP)Path Computation Element Communication Protocol (PCECP) Path Computation Discovery (static and PCEDP)Path Computation Discovery (static and PCEDP) Path computationPath computation Policies and confidentialityPolicies and confidentiality ManagementManagement SecuritySecurity

Approach n Holistic consideration of the inter-AS PCE requirements – i.e., did not only focus on PCECP for instance –Goal was to define requirements on the various components to enable an inter-AS PCE-based solution n Requirements organized into intra-provider inter-AS requirements and additional requirements for inter- provider inter-AS

Reference Model Inter-AS Inter-AS Inter AS PCE1 PCE2 PCE3 :: :: :: R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 | | | | | | R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 :: Intra-AS PCE An inter-AS PCE must be able to cooperate with other intra-area PCEs and inter-AS PCEs to compute an inter-AS (G)MPLS-TE path

Inter-AS PCE Problem Statement n Compute an optimum path for an inter-AS (G) MPLS- TE LSP –An optimum path is one that has the “smallest cost”, according to a normalized TE metric (based upon a TE- metric or IGP metric adopted in each transit AS), among all possible paths that satisfy the LSP TE constraints. n Reduce the possibility of crankbacks or retries

Inter-AS (G)MPLS-TE Operations and Interoperability Requirements n Solution MUST be such that it will interoperate seamlessly with current intra-area and inter-domain (inter-area and inter-AS) (G)MPLS-TE mechanisms n Solution MUST interoperate with other mechanisms for path computation to setup a path across ASes with and without PCE capabilities. n Solution SHOULD allow the setup of an inter-AS TE-LSP by provisioning the head end only

PCECP inter-AS Requirements n Generic PCECP inter-AS requirements –An inter-AS PCE must be able to locally prioritize messages on an AS basis in addition to message-level priority. –An inter-AS PCE must be able to change the message priority when sending a path computation request from the priority it received for the same LSP. – An inter-AS PCE must be able to perform translation on class of service identifiers carried in a request/response for a DS-TE packet LSP –A PCE must be able to protect itself against DOS attacks initiated via PCECP n Inter-AS requirements on PCECP Requests –A path computation request to an inter-AS PCE must be able to specify ASBRs and ASes as strict and loose nodes in LSP path. –An inter-AS PCE must also be able to specify a preferred ASBR on the path to the next AS –An inter-AS PCE should be able to send simultaneous requests to inter-AS PCEs associated with ASes that announced reachability to the destination. The number of simultaneous requests should be configurable. –An inter-AS PCE must be able to identify the AS on whose behalf it is sending the request in the path computation request message –An inter-AS PCE must be able to specify in the request message various forms of path protection mechanisms as specified in requirements draft –Connection Admission control of a PCE request based on Requested constraints and available resourcesRequested constraints and available resources Configured policies that apply to the AS of requesting PCEConfigured policies that apply to the AS of requesting PCE

PCECP Inter-AS Requirements (cont.) n Inter-AS requirements on PCECP Responses –A path computation response must be able to include ASBRs and ASes –An inter-AS PCE, when it finds more than one path that satisfies the constraints for an LSP, must be able to return a number of these paths to the requestor along each path cost –The number of returned paths must be configurable at the requesting PCE and the responding PCE to limit the amount of computation and total returned paths to the original PCC –In its response, an inter-AS PCE must identify disjoint paths, when it is requested to compute such paths or path segments. –An inter-AS PCE must be able to send a reject message to the requesting PCE/PCC if it cannot cannot find a path that satisfies the TE-constraints –An inter-AS PCE or a PCC that receives a reject message SHOULD attempt an alternative path by sending a request to an alternative attempt an alternative path by sending a request to an alternative inter-AS PCE. inter-AS PCE.

PCE Discovery inter-AS Requirements n Static configuration requirements –An intra-AS inter-area PCE or a PCC MUST be configurable with one or more inter-AS PCEs that serve the respective PCE/PCC AS. –An inter-AS PCE MUST also be configurable with the set of other inter-AS PCEs that it can have a session with and the ASes that these inter-AS PCEs cover. –Additional attributes MUST also be configurable on a PCE/PCC and associated with the inter-AS PCE it needs to communicate with Local and remote PCE IP addresses used for PCECPLocal and remote PCE IP addresses used for PCECP Type of the remote PCE (e.g., inter-AS)Type of the remote PCE (e.g., inter-AS) Authentication information for PCECPAuthentication information for PCECP A map for the class type (CT) and TE-class translationA map for the class type (CT) and TE-class translation The priority with which an inter-AS PCE serves the messages from the remote inter-AS PCE and message priority mapping policiesThe priority with which an inter-AS PCE serves the messages from the remote inter-AS PCE and message priority mapping policies Capability of the remote inter-AS PCE of computing multiple paths and the number of paths it can returnCapability of the remote inter-AS PCE of computing multiple paths and the number of paths it can return The maximum number of paths that the PCE can accept from the remote inter-AS PCEThe maximum number of paths that the PCE can accept from the remote inter-AS PCE Number of path computation requests it can simultaneously accept from the remote inter-AS PCENumber of path computation requests it can simultaneously accept from the remote inter-AS PCE

PCE Discovery inter-AS Requirements n Dynamic case: PCEDP –An inter-AS PCE must be able to dynamically discover other types of PCEs in the ASes that fall within its scope –PCCs or PCEs must be able to discover an inter-AS PCE that serves them –An inter-AS PCE to identify itself as such and to identify the ASes that it supports –An inter-AS PCE must be able to identify its capabilities to the degree necessary for another PCE or PCC to decide to initiate a PCECP session to it or not. –The capability to limit the scope of an inter-AS PCE advertisement for the purpose of dynamic discovery by other PCCs/PCEs must be provided. –The ability to define the capabilities of an inter-AS PCE that can be advertised to another inter-AS PCE must be provided –A PCC/PCE must allow the configuration of local policies that control which inter-AS PCE it can communicate with when it discovers PCEs

Inter-AS Path Computation Requirements n Routing –Inter-AS PCE Selection: An inter-AS PCE must be able to determine based on routing information (and/or policies) which intra-AS PCEs and inter-AS PCEs it needs to cooperate with to compute the (G)MPLS-TE pathAn inter-AS PCE must be able to determine based on routing information (and/or policies) which intra-AS PCEs and inter-AS PCEs it needs to cooperate with to compute the (G)MPLS-TE path –Multipaths: For an inter-AS PCE to compute multiple inter-AS paths, it must be able to maintain all the BGP advertisements from each ASBR connecting to the neighbroing ASes and use this raw information to compute a path.For an inter-AS PCE to compute multiple inter-AS paths, it must be able to maintain all the BGP advertisements from each ASBR connecting to the neighbroing ASes and use this raw information to compute a path. –Procedures: The exact procedures that govern the interaction between an inter-AS PCE and intra/inter-area PCEs in the ASes within its scope for the purpose of path computation shall be specified and shall result in an optimum and scalable way of computing an inter-AS TE-LSP pathThe exact procedures that govern the interaction between an inter-AS PCE and intra/inter-area PCEs in the ASes within its scope for the purpose of path computation shall be specified and shall result in an optimum and scalable way of computing an inter-AS TE-LSP path n Optimality –Solutions must be able to compute an optimum path (lowest cost that satisfies TE constraints) –Solutions should be compared on the basis of computational efficiency hen they compute an optimum path

Inter-AS Path Computation Requirements n Path re-optimization –PCCs should have the capability to trigger path re-optimization –PCCs that initiate requests for path computation should implement mechanisms that pace path re-optimization requests and avoid network activity synchronization. –A re-optimization request to a PCE must be identified as such. –Policies on the PCE must be configurable to allow or prevent re- optimization to/from certain ASes, or based upon {class type, preemption} in the case of DS-TE –Re-optimization should be configurable to be enabled/disabled on a PCC basis, PCE-basis, and per-LSP. n Inter-AS PCE-based solutions SHOULD provide capability of computing diversified paths for the same LSP n Inter-AS PCE-based solutions SHOULD provide the capability of n MPLS fast reroute around a link or node failure. The link or node could be internal to an AS or at an AS boundary. n Hierachical MPLS –The inter-AS PCE solution SHOULD allow for tunneling inter-AS LSPs within other intra-AS and inter-AS LSPs.

Management n inter-AS PCEs should support a specific inter-AS traffic engineering MIB as specified in draft-ietf-tewg- interas-mpls-te-req- 09.txt for inter-AS n The new MIB module must provide trap functions when thresholds are crossed or when important events occur for inter-AS PCEs. n The new MIB module should support the status of PCECP related to inter-AS PCE communications

Additional PCE InterProvider Requirements n Confidentiality requirements –PCEDP should have the ability to hide all PCEs with provider internal scope and all capability information not required for inter-AS path computation for one or a set of peering AS(es) –An Inter-AS PCE should be able to compute the inter-AS TE LSP across AS boundaries without detailed knowledge of the list of hops, TE link metrics and paths within each transit AS. LSP across AS boundaries without detailed knowledge of the list of hops, TE link metrics and paths within each transit AS. –For each partial inter-AS LSP path a PCE computes, it should return to its peering PCE in the upstream neighbor AS an inter-AS TE LSP segment from its own AS without detailing the explicit intra-AS hops plus partial paths with an aggregated TE LSP cost it receives from its downstream PCE. This could create a challenge of how to expand a path to a loose hop at a domain boundary during signaling (PCE is generally on signally path)This could create a challenge of how to expand a path to a loose hop at a domain boundary during signaling (PCE is generally on signally path)

InterProvider Policy Requirements n Inter-AS Peering Policy requirements –Policies that apply to PCEDP PCE scope and path computation domains: one or a set of ASNs for which a PCE can compute inter-AS TE LSP pathsPCE scope and path computation domains: one or a set of ASNs for which a PCE can compute inter-AS TE LSP paths Constrain the capabilities advertised for an inter-AS PCE to an Another ASConstrain the capabilities advertised for an inter-AS PCE to an Another AS FRR capabilities for inter-AS pathsFRR capabilities for inter-AS paths Re-optimization capabilitiesRe-optimization capabilities n The PCE communications protocol SHOULD have the ability to enforce on the incoming PCE requests policies on a set of parameters listed in the inter-AS TE requirements draft n Reinterpretation policies on an inter-AS PCE –An inter-AS PCE must be able to re-interpret parameters received from another provider inter-AS PCE based on configured policies (DS-TE, preemption/setup priority, etc. reinterpretation (translation)) for use within its domain or to signal to other domains.

Security Requirements n Communication authentication between an inter-AS PCE and any other element it communicates with n The capability to hide intra-provider elements from other providers (e.g., not include them in a returned path)  confidentiality and security n inter-AS PCEs should be able to limit the amount of requests it receives from another inter-AS PCE n inter-AS PCEs, especially in InterProvider environment, should have functions that protect them from malicious DOS attacks.

Issues and Next Steps –Some people think that this draft is too wide in scope, thus, Requirements from this draft will be moved into other existing or new focused PCE requirements documents each document focused on an aspect of PCE (e.g., new inter- AS PCECP requirements document, existing PCE discovery document, etc.)each document focused on an aspect of PCE (e.g., new inter- AS PCECP requirements document, existing PCE discovery document, etc.) May need to have new document for path computation requirements?May need to have new document for path computation requirements? –Any additional WG comments?