idnits 2.17.1 draft-dugeon-pce-ted-reqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-farrel-interconnected-te-info-exchange-02 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-te-metric-extensions-05 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-08 -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element Working Group O. Dugeon 3 Internet-Draft J. Meuric 4 Intended status: Informational Orange 5 Expires: August 18, 2014 R. Douville 6 Alcatel-Lucent 7 R. Casellas 8 CTTC 9 O. Gonzalez de Dios 10 Telefonica Investigacion y Desarrollo 11 February 14, 2014 13 Path Computation Element (PCE) Database Requirements 14 draft-dugeon-pce-ted-reqs-03 16 Abstract 18 The Path Computation Element (PCE) working group (WG) has produced a 19 set of RFCs to standardize the behavior of the Path Computation 20 Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. 21 In the PCE architecture, a main assumption has been done concerning 22 the information that the PCE needs to perform its computation. In a 23 fist approach, the PCE embeds a Traffic Engineering Database (TED) 24 containing all pertinent and suitable information regarding the 25 network that is in the scope of a PCE. Nevertheless, the TED 26 requirements as well as the TED information have not yet been 27 formalized. In addition, some recent RFC (like the Backward 28 Recursive Path Computation procedure or PCE Hierarchy) or WG draft 29 (like draft-ietf-pce-stateful-pce ...) suffer from a lack of 30 information in the TED, leading to a non optimal result or to some 31 difficulties to deploy them. This memo tries to identify some 32 Database, at large, requirements for the PCE. It is split in two 33 main sections: the identification of the specific information to be 34 stored in the PCE Database and how it may be populated. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 18, 2014. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. PCE Assumption and Hypothesis . . . . . . . . . . . . . . 3 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. PCE DataBase Requirements . . . . . . . . . . . . . . . . . . 6 80 2.1. Intra-Domain . . . . . . . . . . . . . . . . . . . . . . 6 81 2.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 6 82 2.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 6 83 2.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 7 84 2.3. TE LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 2.4. Operational Information . . . . . . . . . . . . . . . . . 8 86 3. PCE-DB model . . . . . . . . . . . . . . . . . . . . . . . . 8 87 3.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 8 88 3.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 89 3.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 8 90 3.2. Inter-domain . . . . . . . . . . . . . . . . . . . . . . 8 91 4. PCE-DB Population . . . . . . . . . . . . . . . . . . . . . . 10 92 4.1. Intra-domain . . . . . . . . . . . . . . . . . . . . . . 10 93 4.1.1. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 10 94 4.1.2. GMPLS . . . . . . . . . . . . . . . . . . . . . . . . 11 95 4.2. Inter-Domain . . . . . . . . . . . . . . . . . . . . . . 11 96 4.2.1. Information exchange . . . . . . . . . . . . . . . . 12 98 4.3. TE-LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 4.4. Complementary information . . . . . . . . . . . . . . . . 13 100 4.5. Operationnal and synchronisation constraints . . . . . . 13 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 6.1. Intra-domain information . . . . . . . . . . . . . . . . 14 104 6.2. Inter-domain information . . . . . . . . . . . . . . . . 15 105 6.3. Operational information . . . . . . . . . . . . . . . . . 15 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 107 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 108 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 109 8.2. Informative References . . . . . . . . . . . . . . . . . 16 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 112 1. Problem Statement 114 Looking to the different RFCs that describe the PCE architecture and 115 in particular RFC 4655 [RFC4655], RFC 5440 [RFC5440], RFC 5441 116 [RFC5441] and RFC 6805 [RFC6805], the Path Computation Element (PCE) 117 needs to acquire a set of information that is usually store in the 118 Traffic Engineering Database (TED) in order to perform its path 119 computation. Even if intra-domain topology acquisition is well 120 documented and known (e.g. by listening to the IGP-TE protocol that 121 runs inside the network), inter-domain topology information, PCE peer 122 address, neighbor AS, existing MPLS-TE tunnels... that are necessary 123 for the Global Concurrent Optimization, Backward Recursive Path 124 Computation (BRPC) and the Hierarchical PCE are not documented and 125 not completely standardized. 127 The purpose of this memo is to inventory the required information 128 that should be part of the PCE Database and the different mechanisms 129 that allow an operator to populate it. 131 1.1. PCE Assumption and Hypothesis 132 In some cases, both the path computation and the Database operations 133 are slightly coupled: border node identification, endpoint 134 localization, TE-LSP learning and domain sequence selection... to 135 name a few in which an IGP-based TED may not be sufficient. It is 136 also important to differentiate several environments with different 137 requirements, especially for the multi-domain problem. The PCE is 138 scoped for any kind of network, from transmission networks (TDM/WDM) 139 with a rather limited number of domains, few interconnections, and 140 few confidentiality issues; transmission networks with a large number 141 of domains; MPLS networks with several administrative domains; and 142 big IP/MPLS networks with a large number of domains with peering 143 agreements. For each of them, a different solution for the multi- 144 domain path computation may apply. A solution may not be scalable 145 for one, but perfectly suitable for another. 147 Up to now, PCE WG has based its work and standard on the assumption 148 and hypothesis that the TED contains all pertinent information 149 suitable for the PCE to compute an optimal TE-LSP placement, over one 150 or several domains a PCE has visibility on or over a set of PCE- 151 capable domains (e.g. using BRPC procedure). We could identify 152 several major sources of information for the TED: 154 o The intra-domain routing protocol like OSPF-TE or IS-IS-TE 155 (including extensions for inter-domain links), 157 o The inter-domain routing protocol, i.e. BGP, 159 o TED synchronization protocols, e.g., BGP-LS, 161 o Through manual and or management configuration. 163 If the first source gives a precise and synchronize view of the 164 controlled network, i/eBGP typically just provides network 165 reachability with only one AS path (unless using recent add path 166 option). Now, the TE information traditionally flooded by the IGPs 167 can also be communicated through a BGP sessions, as described in 168 "North bound distribution of Link-State and TE Information using BGP" 169 [I-D.ietf-idr-ls-distribution]. Nevertheless, to optimize inter- 170 domain path computation, route diversity and a minimum set of Traffic 171 Engineering information about the remote domains could be helpful. 172 Despite that it is possible to re-announce TE-LSP in the IGP-TE, the 173 PCE needs also to have a precise knowledge of previous TE-LSP, not 174 only for its stateful version [PCEP Extensions for Stateful PCE] 175 [I-D.ietf-pce-stateful-pce], but also when performing a global 176 concurrent optimization RFC5557 [RFC5557] of the previous TE-LSPs 177 place on a given domain. 179 The last source of information, mainly static, information can be the 180 management plane, e.g. using SNMP, Netconf, CLI... So, it is 181 necessary to classify the source of information by their frequency of 182 update: static or dynamic, e.g. a domain ID is unlikely to change, 183 while unreserved bandwidth of a link may be continuously changing. 184 Finally, all sources of information are pertinent and must be take 185 into account to fulfil the PCE database at large. 187 In this document, PCE Data Base (namely PCE-DB in the rest of the 188 document) is used not only to refer to the usual notion of Traffic 189 Engineering Database information, but also encompasses all relevant 190 information. E.g., the phrase also refers to the list of TE-LSPs 191 running in the domain, sometimes referred as LSP-DB in other 192 documents. Note that this PCE-DB may be implemented over multiple 193 independant DBs. 195 1.2. Terminology 197 ABR: Area Border Routers. Routers used to connect two IGP areas 198 (areas in OSPF or levels in IS-IS). 200 ASBR: Autonomous System Border Router. Router used to connect 201 together ASes of the same or different service providers via one or 202 more inter-AS links. 204 AS: Autonomous System 206 Boundary Node (BN): a boundary node is either an ABR in the context 207 of inter-area Traffic Engineering or an ASBR in the context of inter- 208 AS Traffic Engineering. 210 Domain: an Autonomous System or IGP Area 212 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 213 a determined sequence of domains. 215 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 216 a determined sequence of domains. 218 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 220 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 222 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 223 Both OSPF-TE and IS-IS-TE are identified in this category. 225 PCE: Path Computation Element. An entity (component, application, or 226 network node) that is capable of computing a network path or route 227 based on a network graph and applying computational constraints. 229 PCE(i) is a PCE with the scope of domain(i). 231 PCE-DB: Path Computation Element Data Base 233 TED: Traffic Engineering Database. 235 2. PCE DataBase Requirements 237 This section made a first inventory of the main requirements of the 238 PCE Data Base in term of information that the database should 239 contains. 241 2.1. Intra-Domain 243 This section describes the Intra-domain information that are suitable 244 for the PCE Database including both MPLS and GMPLS. 246 2.1.1. MPLS 248 A PCE is allowed to compute paths in one or several domains. Such 249 PCE MUST be aware of the precise details of the network topology (or 250 topologies) in order to compute optimal TE-LSP placements. The 251 information needed in this case includes: 253 o List of Internal Nodes identified by a reachable address: All 254 nodes of the networks with a particular mention for border node 255 (see next section), 257 o List of Internal Links that rely nodes (both internal and border 258 nodes), 260 o Traffic Engineering information of the different links i.e. RFC 261 3630 [RFC3630] and RFC 5305 [RFC5305](with e.g. recent metric 262 extensions proposal OSPF Traffic Engineering (TE) Metric 263 Extensions [I-D.ietf-ospf-te-metric-extensions]) 265 o Traffic Engineering information of the nodes. 267 The information above mentioned is usually exchanged using the IGP-TE 268 protocol (OSPF-TE or IS-IS-TE). 270 2.1.2. GMPLS 271 When dealing with a (G)MPLS network, the PCE MUST be aware of the 272 complementary information: 274 o Traffic Engineering information with GMPLS extensions of the 275 different links i.e. RFC 4203 [RFC4203] and RFC 5307 [RFC5307], 277 To be completed latter 279 2.2. Inter-Domain 281 A PCE can also be allowed to take part to inter-domain path 282 computation (e.g in per-domain path computation, BRPC or H-PCE 283 relationship). Some inter-domain information is mandatory when 284 operator intend to use the PCE to compute Inter-AS TE LSP path that 285 cross domain boundary. For that purpose, the PCE-DB SHOULD contains 286 all information that allow the PCE to determine the optimal inter- 287 domain path for the TE-LSP computation, which includes: 289 o Border Nodes (BNs) of the domain. A distinction could be made 290 between ALL domains and Neighbor domains only. In the document, 291 we consider ALL domains to be sure that the PCE has the complete 292 visibility of the path diversity. 294 o Links between BN, i.e. links between BN (n) to BN (n+1), including 295 Traffic Engineering information, 297 o Traffic Engineering performance between BN (n) to give performance 298 indication on remote domain n (See section 3.2 on PCE-DB model for 299 the inter-domain part) 301 o PCE (i) peer address associated with the domain number and 302 identity of the remote domain (i), 304 RFC 5316 [RFC5316] for IS-IS and RFC 5392 [RFC5392] for OSPF help to 305 provide required PCE-DB information in the case of inter-domain. 306 PCE-DB can also contain information about virtual links and abstract 307 information. 309 2.3. TE LSPs 311 For stateful operation and Global Concurrent Optimization, the PCE-DB 312 should also contain information on TE-LSPs already enforce in the 313 controlled domain. If some TE-LSP tunnels could be re-announce in 314 the IGP-TE, the PCE could not learn from the IGP-TE all details of 315 all TE LSPs: if TE information is known, detail of the ERO is lost as 316 well as initial QoS parameters. The following information will be 317 useful for the PCE-DB to describe the TE-LSP: 319 o Explicit Route Object (ERO), 321 o End-points objects, 323 o Initial and actual Metric objects, including extend metrics such 324 as delay, jitter, packet loss, 326 Recent PCEP Extensions for Stateful PCE [I-D.ietf-pce-stateful-pce] 327 provide new PCEP message to convey these kind of information. 328 However, this capacity could be used disregarding the behavior 329 (stateless or stateful) of the PCE. Indeed, if it is mandatory for 330 stateful PCE, these information are of great importance then 331 performing Global Concurrent Optimization, even with a stateless PCE. 333 2.4. Operational Information 335 This part of the TED contains all others information, and in 336 particular the PCE policy, pertinent for the PCE to compute TE LSP 337 path but that are provided through the management system. 339 3. PCE-DB model 341 This section inventory the database model(s) to store pertinent 342 information regarding the different source of information. 344 3.1. Intra-domain 346 3.1.1. MPLS 348 For intra-domain, there is no need to specify a particular model or 349 schema for the PCE-DB. Indeed, the model is directly based on the 350 IGP-TE. Of course there is a difference between IS-IS and OSPF, but 351 TE Link state are more of less similar in term of conveyed 352 information and database description. No particular requirements are 353 necessary as this stage. 355 3.1.2. GMPLS 357 To be provided later. 359 3.2. Inter-domain 361 Contrary to intra-domain where the PCE known the exact details of the 362 underlying network, it is not possible to achieve a similar detail 363 level for the inter-domain. And not only for scalability reasons, 364 but mostly for confidentiality of the networks. This memo propose a 365 basic schema that allows PCE to known sufficient details about the 366 remote domain while keeping confidential the internal information. 368 For this purpose, we propose to describe a domain as a "Grey-Box" 369 with inputs and outputs that correspond to the Border Nodes (BNs). 370 Then Grey-Boxes are interconnected through inter-domain links between 371 the BNs. Then, suitable performance indicators are given to cross 372 the Grey-Boxes from an input BN to and output BN. Figure below gives 373 as example of such model. 375 +----------------+ +----------------+ 376 | Domain (B) | | Domain (C) | 377 Inter | | Inter | (BN)-- Inter 378 Domain --(BN) | Domain | | Domain 379 Link | (BN)--------(BN) (BN)-+ Links 380 | | Link | | | 381 +-----(BN)-------+ +----------------+ | 382 | | 383 | Inter-domain Link | 384 +-----(BN)-------+ +------(BN)------+ | 385 | Domain (A) | | Domain (D) | | 386 Inter | | Inter | (BN)-+ Inter 387 Domain --(BN) | Domain | | Domain 388 Link | (BN)--------(BN) (BN)-- Links 389 | | Link | | 390 +-----(BN)-------+ +----------------+ 391 | 392 | Inter-domain Link 394 Example of the representation of 3 domains with the Grey-Box model 396 Domain C is reachable from domain A through domain B or domain D. 397 For a PCE, with such model, it becomes easy to compute a constraint 398 shortest path by combining the resources availability on Inter-Domain 399 links and cost to cross the different domain. For example, with 400 these figures (note that we take only one measured to illustrate the 401 purpose and that multiple constraints are used in reality): 403 o Crossing B cost 100, D cost 50, C cost 75, A cost 50 405 o Inter-domain links costs: A to B = 10, B to C = 20, A to D = 10, D 406 to C = 50 408 PCE A could not choose between B or D as the Inter-domain link costs 409 are equal. With the proposed model, it could compute that going 410 through B cost 130 (= 10 + 100 20) and through D cost 110 (= 10 + 50 411 + 50) and choose D path even if the last Inter-domain links is 412 costly. 414 Today, when trying to compute an inter-domain TE LSP, the PCE may 415 failed in its computation and used crank back facilities to find a 416 suitable path. With such inter-domain information, a PCE could look 417 into the different inter-domain path (as the sum of inter-domain 418 links and Grey-Box crossing performances) and select the most 419 suitable one regarding the PCReq avoiding crank back and achieve 420 possibly, better results as it explore all possible inter-domain 421 paths. 423 If the inter-domain links between BN that connect the Grey-Boxes 424 description are covered (see section 2.2), it is not the case for the 425 internal links between BNs inside the Grey-Box. 427 4. PCE-DB Population 429 This section aims to provide best current practices when mechanisms 430 are well-known and some hints when standard solutions exist to 431 populate the PCE TED, and so give directions to extend them. In 432 particular, we aim at providing input on whether the TED gets the 433 information from the routing protocol and how it gets it, which 434 specific routing protocols are suited, whether it gets it from an 435 NMS, at what frequency the TED is updated... and if it needs extra 436 information. 438 4.1. Intra-domain 440 4.1.1. MPLS 442 As the TED mainly contains the intra-domain topology graph, it is 443 RECOMMENDED to link the PCE with the underlying IGP-TE (OSPF-TE or 444 IS-IS-TE routing protocol). By adding the PCE into the IGP-TE 445 routing intra-domain, it is possible to listen to the routing 446 protocol and then acquired the complete topology graph as well as let 447 the PCE announce itself (see RFC5088 and RFC5089). In addition, the 448 TED will synchronize as fast as the routing protocol converges like 449 any router in the domain. Best current practices are also of 450 interest when a PCE compute path that spawn to several area / region. 451 In that case, the PCE must be aware of the topology details of each 452 area / region. 454 Note that linking the PCE with the underlying IGP-TE may also be 455 accomplished through receiving BGP-LS updates as described in "North 456 bound distribution of Link-State and TE Information using BGP" 457 [I-D.ietf-idr-ls-distribution]. Although joining the IGP is good 458 enough, BGP-LS is not precluded for use intra-domain and can be a 459 nice way to have a uniform mechanism to acquire the TED e.g. from a 460 Route Reflector that also listen to the IGP. 462 In addition, management tools may be used to complement the topology 463 graph provided by the routing protocol. 465 4.1.2. GMPLS 467 To be provided later. 469 4.2. Inter-Domain 471 If for inter-area aspect of the inter-domain, actual IGP protocol 472 provide in general the aforementioned information without any 473 particular extension, this is not the case for the inter-as scenario 474 and sometimes an issue for inter-area. 476 First of all, RFC 5316 or RFC 5392 MUST be activated in the IGP-TE 477 (respectively in IS-IS-TE or OSPF-TE) in order to advertise TE 478 information on the inter-domain links. This gives the advantage for 479 the PCE to determine what could be feasible, during path computation, 480 on the peering links. 482 In MPLS, AS path and network reachability are obtained from BGP and 483 routing tables. In addition, domain or sequence path could be 484 specified in the PCE Request. However, when inter-domain path is not 485 known or could not retrieve from an external entities, it could be of 486 interest for a PCE to have the possibility to compute the inter- 487 domain path prior to the intra-domain part. Again, the PCE needs 488 corresponding information in its PCE-DB. But, it is not 489 straightforward to collect route diversity or TE information (i.e. 490 bandwidth, transit delay, packet loss ratio, jitter ...) on a remote 491 domain. Of course, for confidentiality and scalability issues, the 492 PCE MUST NOT learn all details of the remote TED, it just needs an 493 abstract view like proposed in "Problem Statement and Architecture 494 for Information Exchange Between Interconnected Traffic Engineered 495 Networks" [I-D.farrel-interconnected-te-info-exchange]. 497 Right now, we have identified several methods, which have been tested 498 to fill in the PCE-DB with this kind of information: 500 o Use of the management plane; 502 o Use of the "North bound distribution of Link-State and TE 503 Information using BGP" [I-D.ietf-idr-ls-distribution] proposal to 504 exchange TE information about the remote domain; 506 o Use of PCNtf message to convey, inside vendor attribute (but in an 507 extended way), TE information of remote domain between PCE 509 As well as some potential alternative mechanisms that would need more 510 standardization effort: 512 o A Hierarchical TE that could help to advertise, at the AS level, 513 TE information on an abstract view of the remote AS topology; 515 o A PCEP extension to convey such TE information to the remote PCE. 517 4.2.1. Information exchange 519 The force of PCE is to be aware of the complete topology of the 520 underlying network where it is connected. With such knowledge, it 521 could place efficiently the tunnel even if it not follows the route 522 computed by the IGP routing protocol. Same principles apply also for 523 the inter-domain. But, in the Internet today, BGP summarize the 524 route and the PCE should not be aware of the route diversity. In 525 particular, it could not choose another AS path as the one selected 526 and announced by BGP. A way to bypass this restriction is to specify 527 the AS-path in the PCE Request IRO. In all other cases, the PCE will 528 not be sufficiently aware of the route diversity and can not select 529 the optimal AS path when computing an inter-domain LSP. To avoid 530 this and allow PCE to know route diversity to reach a given remote 531 domain, the inter-domain information must be propagated between all 532 PCEs without aggregation or summarization. In summary, PCEs need to 533 synchronize part of their Database i.e. the inter-domain part. 534 Disregarding the protocol, two different solutions emerged to 535 exchange inter-domain information: 537 o Direct Distribution: Exchange TE information using BGP is part of 538 this case. In this scenario, it is necessary to establish a BGP 539 session between the different domains (whatever the platform used, 540 a dedicated router, a PCE, another server ...). In the hierarchal 541 PCE scenario, operators that provide child PCE, agree to establish 542 a relation with remote domain that provides the parent PCE. But, 543 in BRPC, or in Hierarchical PCE where almost operators provide a 544 parent PCE, BGP session must be establish between networks that 545 have not necessary direct adjacency. However, operators should 546 not agree to accept relation from other's not directly attached to 547 their network. In addition, this scenario could conduct to 548 establish a full mesh of BGP session between PCE which could lead 549 into some scalability problems. 551 o Flooding Distribution: In this case, the inter-domain information 552 are flood between all PCE so that each PCE is aware about all 553 remote domain capabilities. This meets the requirement but 554 doesn't provide the flexibility of BGP in term of filtering. 555 Indeed, BGP allows through configuration to decide which 556 information are announced and to whom. As a per session relation, 557 a given operator is not oblige to announce the same capabilities 558 to its remote domain. With flooding distribution, where everybody 559 redistribute what it has learned without modify it, it is not 560 possible to specialize announcement based on remote domain. 562 So, the solution must provide the possibility to filter what is 563 announce per remote domain without authorized the summarization or 564 aggregation while keeping a distributed relation between domains. In 565 addition, a domain is responsible about the Grey-Box announcement and 566 the advertisement information must not be modified by intermediate 567 PCE. 569 4.3. TE-LSPs 571 Up to know, the PCE could learn the tunnel already enforce in the 572 controlled domain through dedicated NMS system. Recent works on 573 state full extensions for PCEP propose to add new messages in order 574 to collect information on TE-LSPs from the PCCs. 576 4.4. Complementary information 578 Most of the time, static information, including PCE Policy, are 579 provided through the management system of the operator or by means of 580 static configuration (e.g. command line option, configuration file 581 ...), but some could be automatically discovered. In particular, in 582 intra-domain, PCCs and PCEs can discover automatically reachable PCEs 583 (as well as computation domains) through the deployment of RFC 5088 584 [RFC5088], for OSPF-controlled networks, and RFC 5089 [RFC5089] for 585 IS-IS controlled networks. However, for the inter-PCE discovery at 586 the inter-AS level, no mechanism has been standardized (unless ASes 587 are owned by the same ISP). 589 4.5. Operationnal and synchronisation constraints 591 Even if acquired TE information is solved, it remains two major 592 problems from an operational point of view. 594 First of all, the PCE-DB MUST be synchronised with the underlying 595 network topology. This synchronisation is not only mandatory for the 596 efficiency of the answer of the PCE, but more to handle the graceful 597 restart step of the PCE as well as crash situation. Indeed, for 598 divert reasons (maintenance, scheduled operation, failure ...), when 599 the PCE start or restart, it MUST acquired the information of the 600 PCE-DB and then maintain it synchronised to the underlying network. 601 For the stateful version of the PCE, this synchronisation is 602 mandatory as TE-LSP tunnel could be setup manually or by the 603 management plane independently from the PCE. But, the PCE MUST be 604 aware of them as well as when the PCE restart is MUST be aware of TE- 605 LSP it previously setup. 607 The second point come from the distributed nature of the TED 608 information located in the underlying network. Indeed, TE 609 information are not located in one place, but distributed amongst all 610 the router of the network. Each router manage its links, and, 611 consequently, the TE information attached to these links. Thus, 612 modifying a TE information on large scale network could become 613 quickly a nightmare for operational without any tools to help them. 614 For that purpose, a TE Netconf model like proposed in "A YANG Data 615 Model for Network Topologies" [I-D.clemm-netmod-yang-network-topo] is 616 mandatory from an operation point of view to allow automatic tools 617 easily configure the TE parameters of a network on the routers. 619 5. IANA Considerations 621 This document makes no request of IANA for the moment. 623 Note to RFC Editor: this section may be removed on publication as an 624 RFC. 626 6. Security Considerations 628 Acquisition of information for the PCE TED is of course sensible from 629 a security point of view, especially when acquiring information from 630 others AS. This section aims at providing best practices to prevent 631 some security threat when the PCE try to acquire TED information. 633 6.1. Intra-domain information 634 Same security considerations must be applied to the PCE when it is 635 connected to an IGP-TE protocol as the routing protocol itself. Best 636 practices observed and deployed by operators must also be taken into 637 account when installing some PCEs. Indeed, even when deployed as a 638 standalone server, PCEs must be considered as a typical router from 639 the IGP-TE perspective. As a result, beyond OSPF or IS-IS 640 themselves, the usual security rules must be applied, e.g. login/ 641 passwd, authentication/digest... to protect the connectivity. 643 6.2. Inter-domain information 645 Inter-domain relation and so information exchange are subject to high 646 potential hijack and so need attention from the security point of 647 view. To avoid disclosing or expose confidential information that 648 two operators would exchange to fill in the TEDs of their respective 649 PCEs, the relation SHOULD be protected by standard cryptography 650 mechanism. E.g. using IPsec tunnel is RECOMMENDED to protect the 651 connectivity between PCEs and the TED exchanges. 653 6.3. Operational information 655 All operational information like PCE peer addresses are generally 656 added manually to the TED and so do not need any particular 657 protection nor subject to security. But, as this basic information 658 is needed to connected the PCEs to their peers, it could potentially 659 be associated to sensitive parameters like login and password. So, 660 standard Best Practices are RECOMMENDED to avoid basic security 661 exposition. 663 7. Acknowledgements 665 The authors want to thanks PCE's WG members and in particular Daniel 666 King for their inputs of this subject. 668 8. References 670 8.1. Normative References 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 676 Element (PCE)-Based Architecture", RFC 4655, August 2006. 678 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 679 (PCE) Communication Protocol (PCEP)", RFC 5440, March 680 2009. 682 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 683 Backward-Recursive PCE-Based Computation (BRPC) Procedure 684 to Compute Shortest Constrained Inter-Domain Traffic 685 Engineering Label Switched Paths", RFC 5441, April 2009. 687 8.2. Informative References 689 [I-D.clemm-netmod-yang-network-topo] 690 Clemm, A., Ananthakrishnan, H., Medved, J., Tkacik, T., 691 Varga, R., and N. Bahadur, "A YANG Data Model for Network 692 Topologies", draft-clemm-netmod-yang-network-topo-01 (work 693 in progress), October 2013. 695 [I-D.farrel-interconnected-te-info-exchange] 696 Farrel, A., Drake, J., Bitar, N., Swallow, G., and D. 697 Ceccarelli, "Problem Statement and Architecture for 698 Information Exchange Between Interconnected Traffic 699 Engineered Networks", draft-farrel-interconnected-te-info- 700 exchange-02 (work in progress), October 2013. 702 [I-D.ietf-idr-ls-distribution] 703 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 704 Ray, "North-Bound Distribution of Link-State and TE 705 Information using BGP", draft-ietf-idr-ls-distribution-04 706 (work in progress), November 2013. 708 [I-D.ietf-ospf-te-metric-extensions] 709 Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 710 Previdi, "OSPF Traffic Engineering (TE) Metric 711 Extensions", draft-ietf-ospf-te-metric-extensions-05 (work 712 in progress), December 2013. 714 [I-D.ietf-pce-stateful-pce] 715 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 716 Extensions for Stateful PCE", draft-ietf-pce-stateful- 717 pce-08 (work in progress), February 2014. 719 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 720 (TE) Extensions to OSPF Version 2", RFC 3630, September 721 2003. 723 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 724 of Generalized Multi-Protocol Label Switching (GMPLS)", 725 RFC 4203, October 2005. 727 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 728 "OSPF Protocol Extensions for Path Computation Element 729 (PCE) Discovery", RFC 5088, January 2008. 731 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 732 "IS-IS Protocol Extensions for Path Computation Element 733 (PCE) Discovery", RFC 5089, January 2008. 735 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 736 Engineering", RFC 5305, October 2008. 738 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 739 of Generalized Multi-Protocol Label Switching (GMPLS)", 740 RFC 5307, October 2008. 742 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 743 Support of Inter-Autonomous System (AS) MPLS and GMPLS 744 Traffic Engineering", RFC 5316, December 2008. 746 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 747 Support of Inter-Autonomous System (AS) MPLS and GMPLS 748 Traffic Engineering", RFC 5392, January 2009. 750 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 751 Computation Element Communication Protocol (PCEP) 752 Requirements and Protocol Extensions in Support of Global 753 Concurrent Optimization", RFC 5557, July 2009. 755 [RFC6805] King, D. and A. Farrel, "The Application of the Path 756 Computation Element Architecture to the Determination of a 757 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 758 2012. 760 Authors' Addresses 762 Olivier Dugeon 763 Orange 764 2, Avenue Pierre Marzin 765 Lannion 22307 766 France 768 Email: olivier.dugeon@orange.com 770 Julien Meuric 771 Orange 772 2, Avenue Pierre Marzin 773 Lannion 22307 774 France 776 Email: julien.meuric@orange.com 777 Richard Douville 778 Alcatel-Lucent 779 Route de Villejust 780 Nozay 91620 781 France 783 Email: richard.douville@alcatel-lucent.com 785 Ramon Casellas 786 CTTC 787 Av. Carl Friedrich FGauss n7 788 Castelldefels, Barcelona 08860 789 Spain 791 Email: ramon.casellas@cttc.es 793 Oscar Gonzalez de Dios 794 Telefonica Investigacion y Desarrollo 795 C/ Emilio Vargas 6 796 Madrid 797 Spain 799 Email: ogondio@tid.es