Inter-AS PCE Requirements draft-bitar-zhang-interas-PCE-req-01.txt

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

2. Objectives • Illustrate the application of inter-AS PCE via use cases • 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 mechanisms • Path Computation Element Communication Protocol (PCECP) • Path Computation Discovery (static and PCEDP) • Path computation • Policies and confidentiality • Management • Security

3. Approach • 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 • Requirements organized into intra-provider inter-AS requirements and additional requirements for inter-provider inter-AS

4. 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 <==AS1=> <====AS2======> <=====AS3===> • 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

5. Inter-AS PCE Problem Statement • 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. • Reduce the possibility of crankbacks or retries

6. Inter-AS (G)MPLS-TE Operations and Interoperability Requirements • 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 • Solution MUST interoperate with other mechanisms for path computation to setup a path across ASes with and without PCE capabilities. • Solution SHOULD allow the setup of an inter-AS TE-LSP by provisioning the head end only

7. PCECP inter-AS Requirements • 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 • 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 resources • Configured policies that apply to the AS of requesting PCE

8. PCECP Inter-AS Requirements (cont.) • 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 inter-AS PCE.

9. PCE Discovery inter-AS Requirements • 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 PCECP • Type of the remote PCE (e.g., inter-AS) • Authentication information for PCECP • A 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 policies • Capability 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 PCE • Number of path computation requests it can simultaneously accept from the remote inter-AS PCE

10. PCE Discovery inter-AS Requirements • 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

11. Inter-AS Path Computation Requirements • 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 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. • 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 path • 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

12. Inter-AS Path Computation Requirements • 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. • Inter-AS PCE-based solutions SHOULD provide capability of computing diversified paths for the same LSP • Inter-AS PCE-based solutions SHOULD provide the capability of • MPLS fast reroute around a link or node failure. The link or node could be internal to an AS or at an AS boundary. • Hierachical MPLS • The inter-AS PCE solution SHOULD allow for tunneling inter-AS LSPs within other intra-AS and inter-AS LSPs.

13. Management • 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 • The new MIB module must provide trap functions when thresholds are crossed or when important events occur for inter-AS PCEs. • The new MIB module should support the status of PCECP related to inter-AS PCE communications

14. Additional PCE InterProvider Requirements • 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. • 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)

15. InterProvider Policy Requirements • 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 paths • Constrain the capabilities advertised for an inter-AS PCE to an Another AS • FRR capabilities for inter-AS paths • Re-optimization capabilities • 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 • 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.

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

17. 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.) • May need to have new document for path computation requirements? • Any additional WG comments?