Fatai Zhang zhangfatai@huawei Quintin Zhao qzhao@huawei Oscar Gonzalez de Dios

1. Extensions to PCEP for Hierarchical Path Computation Elements PCEdraft-zhang-pcep-hierarchy-extensions-00 Fatai Zhang zhangfatai@huawei.com Quintin Zhao qzhao@huawei.com Oscar Gonzalez de Dios ogondio@tid.es Ramon Casellas ramon.casellas@cttc.es Daniel King daniel@olddog.co.uk IETF 79 - Beijing

2. Objective of the document • This document defines the PCEP extensions for the purpose of implementing Hierarchical PCE (H-PCE) procedures described in [PCE-HIERARCHY-FWK]. • Specifically, the document describes the following new PCEP extensions and procedures to support H-PCE: • Capability Discovery • Domain Connectivity Collection • Objective Functions • RP Objects • Error Handling • Endpoint localization/reachability [PCE-HIERARCHY-FWK] draft-king-pce-hierarchy-fwk-05 IETF 79 - Beijing

3. H-PCE Refresher • The parent PCE maintains a topology map. • The nodes are the child domains. • The map contains the inter-domain links. • The TE capabilities of the links are also known. • The parent PCE knows the identity and location of the child PCEs responsible for the child domains. • Statically configured or dynamically discovered. • Responsible child PCE’s will compute: • Source-to-edge (e.g., Domain 1) • Edge-to-edge (e.g., Domain 2) • Edge-destination (e.g., Domain 3) • Domain confidentiality. • A parent PCE is aware of the topology and connections between domains, but is not aware of the contents of the domains. • Child domains are completely confidential. IETF 79 - Beijing

4. Capability Discovery • A PCE (child or parent) domain is a single domain with one or more associated PCE. It is possible for a child PCE to be responsible for multiple domains. • The PCE (child or parent) domain may be an IGP area or AS. • The child PCE and parent PCE relationship will be configured statically. • During the PCEP session establishment procedure, the child PCE needs to verify that the parent PCE is capable of H-PCE computations. • No further automated discovery is required, or desired. IETF 79 - Beijing

5. Domain Connectivity Collection • A parent PCE can populate its topology map either from static configuration or from information received from each child PCE. • There are two types of domain borders for inter-domain connectivity: • Domain border is a TE link, e.g., the inter-AS TE link which connects two ASs. • Domain border is a node, e.g., the IGP ABR which connects two IGP areas. • If a child PCE needs to notify the parent PCE of its inter-domain link connectivity, the relevant information is required to be sent to the parent PCE. IETF 79 - Beijing

6. Objective Functions • Deriving the optimal end-to-end domain path sequence is dependent on the policy applied during domain path computation. • An Objective Function (OF) [RFC5541], or set of OFs, may be applied to define the policy being applied to the domain path computation. • There are three new objective functions which are defined in [PCE-HIERARCHY-FWK]: • Minimize the number of boundary nodes used. • Limit the number of domains crossed. • Disallow domain re-entry. • The child PCE can specify which existing, or new, objective function code(s) to use. [PCE-HIERARCHY-FWK] draft-king-pce-hierarchy-fwk-05 IETF 79 - Beijing

7. RP Objects • Domain Path Request bit • If a child PCE requests the domain sequence for a multi-domain path computation, it can set the Domain Path Request bit in the RP object carried in a request within a PCReqmessage. • The parent PCE which receives the request will attempt to compute a domain sequence. • Destination Domain Query bit • If the parent PCE wishes to get the destination domain ID it will use this bit. • Alternative: “CIDR Prefixes announcement” • If the domain path computation succeeds, the parent PCE sends a PCRepmessage, which carries the domain sequence in the ERO to the child PCE . • Domain Connectivity Information notification-type • Once the session between the child PCE and parent PCE is established, the following notification can be used to maintain topology and connectivity information. IETF 79 - Beijing

8. RP Objects (Continued) • Inter-domain Link TLV • Each inter-domain link is identified by a combination of its advertised router ID and the link local IP address or link local unnumbered identifier. • Inter-domain Node TLV • The Inter-domain Node TLV carries only the two adjacent domain ID and the router (IGP ABR) ID.  Note: a node may belong to 3 or more domains. Alternative: (D1, N), (D2, N), (D3,N)N Belongs to D1, D2, D3 • Domain-ID TLV • This TLV can be carried in a NOTIFICATION or OPEN object to indicate the domain ID of the PCE who sent the PCNtf/Open message. • PCE-ID TLV • This TLV can be carried in a NOTIFICATION or OPEN object to indicate the PCE ID of the PCE who sends the PCNtf/Open message. IETF 79 - Beijing

9. Error Handling • PCEP Error-Type 11 • A parent PCE may not be not be configured to accept H-PCE requests from a specific child PCE. IETF 79 - Beijing

10. Next Steps • This is a 00 draft, we would gladly like feedback. • All areas remain open for discussion, but especially: • Do we need adjacencies between child PCEs? • Should the child and parent PCE have persistent PCEP session? • The format of PCEP extensions, including PCE-IDs and Domain-IDs (IPv4 and IPv6). • Endpoint location: polling or announcement? • The construction of a TED at the parent PCE. • Additional error cases and procedures. • Anyone else implementing? • We are aware of two early implementations. • Awaiting WG recharter to include H-PCE work. IETF 79 - Beijing