idnits 2.17.1 draft-dwpz-pce-domain-diverse-07.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 (May 17, 2017) is 2534 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-dhody-pce-of-diverse-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Q. Wu 4 Intended status: Experimental U. Palle 5 Expires: November 18, 2017 X. Zhang 6 Huawei Technologies 7 May 17, 2017 9 PCE support for Domain Diversity 10 draft-dwpz-pce-domain-diverse-07 12 Abstract 14 The Path Computation Element (PCE) may be used for computing path for 15 services that traverse multi-area and multi-AS Multiprotocol Label 16 Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) 17 networks. 19 Path computation should facilitate the selection of paths with domain 20 diversity. This document examines the existing mechanisms to do so 21 and further propose some extensions to Path Computation Element 22 Protocol (PCEP). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 18, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Domain Diversity . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Per Domain Path Computation . . . . . . . . . . . . . . . 4 63 3.2. Backward-Recursive PCE-based Computation . . . . . . . . 4 64 3.3. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 5 65 3.3.1. End to End Path . . . . . . . . . . . . . . . . . . . 5 66 3.3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . 5 67 4. Extension to PCEP . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. SVEC Object . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Minimize Shared Domains . . . . . . . . . . . . . . . . . 7 70 4.3. Relationship between SVEC Diversity Flags and OF . . . . 7 71 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Transit Domain Identifier . . . . . . . . . . . . . . . . 8 73 5.2. Diversity v/s Optimality . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 76 7.1. Control of Function and Policy . . . . . . . . . . . . . 9 77 7.2. Information and Data Models . . . . . . . . . . . . . . . 9 78 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 79 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 80 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 81 7.6. Impact On Network Operations . . . . . . . . . . . . . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 The ability to compute shortest constrained TE LSPs in Multiprotocol 93 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 94 multiple domains has been identified as a key requirement. In this 95 context, a domain is a collection of network elements within a common 96 sphere of address management or path computational responsibility 97 such as an Interior Gateway Protocol (IGP) area or an Autonomous 98 Systems (AS). 100 In a multi-domain environment, Domain Diversity is defined in 101 [RFC6805]. A pair of paths are domain-diverse if they do not 102 traverse any of the same transit domains. Domain diversity may be 103 maximized for a pair of paths by selecting paths that have the 104 smallest number of shared domains. Path computation should 105 facilitate the selection of domain diverse paths as a way to reduce 106 the risk of shared failure and automatically helps to ensure path 107 diversity for most of the route of a pair of LSPs. 109 The main motivation behind domain diversity is to avoid fate sharing, 110 but it can also be because of some geo-political reasons and 111 commercial relationships that would require domain diversity. for 112 example, a pair of paths should choose different transit Autonomous 113 System (AS) because of some policy considerations. 115 In case when full domain diversity could not be achieved, it is 116 helpful to minimize the common shared domains. Also it is 117 interesting to note that other scope of diversity (node, link, SRLG 118 etc) can still be applied inside the common shared domains. 120 This document examine a way to achieve domain diversity with existing 121 inter-domain path computation mechanism like per-domain path 122 computation technique [RFC5152], Backward Recursive Path Computation 123 (BRPC) mechanism [RFC5441] and Hierarchical PCE [RFC6805]. This 124 document also considers synchronized as well as non-synchronized 125 dependent path computations. Since independent and synchronized path 126 computation cannot be used to apply diversity, it is not discussed in 127 this document. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Terminology 137 The terminology is as per [RFC5440]. 139 3. Domain Diversity 141 As described in [RFC6805], a set of paths are considered to be domain 142 diverse if they do not share any transit domains, apart from ingress 143 and egress domains. 145 Some additional parameters to consider would be - 147 Minimize shared domain: When a fully domain diverse path is not 148 possible, PCE could be requested to minimize the number of shared 149 transit domains. This can also be termed as maximizing partial 150 domain diversity. Other scope of diversity (node, link, SRLG etc) 151 can still be applied inside the common shared domains. 153 Boundary Nodes: Diversity in boundary node selection can be achieved 154 by node diversity. 156 3.1. Per Domain Path Computation 158 The per domain path computation technique [RFC5152] defines a method 159 where the path is computed during the signaling process (on a per- 160 domain basis). The entry Boundary Node (BN) of each domain is 161 responsible for performing the path computation for the section of 162 the LSP that crosses the domain, or for requesting that a PCE for 163 that domain computes that piece of the path. 165 Non-Synchronized Path Computation: Path computations are performed 166 in a serialized and independent fashion. After the setup of 167 primary path, a domain diverse path can be signaled by encoding 168 the transit domain identifiers in exclude route object (XRO) or 169 explicit exclusion route subobject (EXRS) using domain sub-objects 170 defined in [RFC7898] and [RFC3209] in RSVP-TE. Note that the head 171 end LSR should be aware of transit domain identifiers of the 172 primary path to be able to do so. Also a head end label switching 173 router (LSR) can signal a path by using a domain diverse domain 174 sequence known in priori and encoded in explicit route object 175 (ERO) in path message. 177 Synchronized Path Computation: Not Applicable. 179 3.2. Backward-Recursive PCE-based Computation 181 The BRPC [RFC5441] technique involves cooperation and communication 182 between PCEs in order to compute an optimal end-to-end path across 183 multiple domains. The sequence of domains to be traversed maybe 184 known before the path computation, but it can also be used when the 185 domain path is unknown and determined during path computation. 187 Non-Synchronized Path Computation: Path computations are performed 188 in a serialized and independent fashion. After the path 189 computation of the primary path, a domain diverse path computation 190 request is sent by PCC to the PCE, by encoding the transit domain 191 identifiers in XRO or EXRS using domain sub-objects defined in 192 [RFC7897] and [RFC3209] in PCEP. Note that the PCC should be 193 aware of transit domain identifiers of the primary path to be able 194 to do so. Also a PCC can request a path by using a domain diverse 195 domain sequence known in priori and encoded in include route 196 object (IRO) in path request message. 198 Synchronized Path Computation: Not Applicable. [Since different 199 transit domain PCEs may be involved , there is difficulty to 200 achieve synchronization for domain diverse path computation]. 201 Note that [RFC5440] describes other diversity parameters (node, 202 link, SRLG etc) that may be applied. 204 3.3. Hierarchical PCE 206 In H-PCE [RFC6805] architecture, the parent PCE is used to compute a 207 multi-domain path based on the domain connectivity information. The 208 parent PCE may be requested to provide a end to end path or only the 209 sequence of domains. 211 3.3.1. End to End Path 213 Non-Synchronized Path Computation: Path computations are performed 214 in a serialized and independent fashion. After the path 215 computation of the primary path, a domain diverse path computation 216 request is sent to the parent PCE, by encoding the transit domain 217 identifiers in XRO or EXRS using domain sub-objects defined in 218 [RFC7897] and [RFC3209] in PCEP. Note that the PCC should be 219 aware of transit domain identifiers of the primary path to be able 220 to do so. The parent PCE should provide a domain diverse end to 221 end path. 223 Synchronized Path Computation: Child PCE should be able to request 224 dependent and synchronized domain diverse end to end paths from 225 its parent PCE. A new flag is added in synchronized vector (SVEC) 226 object for this (Refer Section 4.1). 228 3.3.2. Domain-Sequence 230 Non-Synchronized Path Computation: Path computations are performed 231 in a serialized and independent fashion. After the primary path 232 computation using H-PCE (involving domain-sequence selection by 233 parent PCE and end-to-end path computation via BRPC or Per-Domain 234 mechanisms), a domain diverse path computation request is sent to 235 the parent PCE, by encoding the transit domain identifiers in XRO 236 or EXRS using domain sub-objects defined in [RFC7897] and 237 [RFC3209] in PCEP. Note that the PCC should be aware of transit 238 domain identifiers of the primary path to be able to do so. The 239 parent PCE should provide a diverse domain sequence. 241 Synchronized Path Computation: Child PCE should be able to request 242 dependent and synchronized diverse domain-sequence(s) from it's 243 parent PCE. A new flag is added in SVEC object for this (Refer 244 Section 4.1). The parent PCE should reply with diverse domain 245 sequence(s) encoded in ERO as described in [RFC7897]. 247 4. Extension to PCEP 249 [Editor's Note: It has been requested to move this section to the 250 HPCE-Extension document - draft-ietf-pce-hierarchy-extensions. This 251 section would be removed from this document once that is done.] 253 4.1. SVEC Object 255 [RFC5440] defines SVEC object which includes flags for the potential 256 dependency between the set of path computation requests (Link, Node 257 and SRLG diverse). This document proposes a new flag O for domain 258 diversity. 260 The format of the SVEC object body is as follows: 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved | Flags |O|P|D|S|N|L| 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Request-ID-number #1 | 268 // // 269 | Request-ID-number #M | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 1: SVEC Body Object Format 274 Following new bit is added in the Flags field: 276 * O (Domain diverse) bit: when set, this indicates that the computed 277 paths corresponding to the requests specified by the following RP 278 objects MUST NOT have any transit domain(s) in common. 280 The Domain Diverse O-bit can be used in Hierarchical PCE path 281 computation to compute synchronized domain diverse end to end path or 282 diverse domain sequences as described in Section 3.3. 284 When domain diverse O bit is set, it is applied to the transit 285 domains. The other bit in SVEC object (N, L, S etc) is set, should 286 still be applied in the ingress and egress domain. 288 4.2. Minimize Shared Domains 290 In case when full domain diversity could not be achieved, it maybe 291 helpful to minimize the common shared domains. It's interesting to 292 note that diversity (node, link etc) can still be applied inside the 293 common shared transit domains as well as for ingress and egress 294 domain via the bits in SVEC object (N, L, S etc). 296 A new Objective function (OF) [RFC5541] code for synchronized path 297 computation requests is proposed: 299 MCTD 301 * Name: Minimize the number of Common Transit Domains. 303 * Objective Function Code: TBD 305 * Description: Find a set of paths such that it passes through the 306 least number of common transit domains. 308 The MCTD OF can be used in Hierarchical PCE path computation to 309 request synchronized domain diverse end to end paths or diverse 310 domain sequences as described in Section 3.3. 312 [Editor's Note: A new document is created for the OF for minimizing 313 shared node, links, SRLGs inside the domain - 314 [I-D.dhody-pce-of-diverse].] 316 For non synchronized diverse domain path computation the X bit in XRO 317 or EXRS [RFC5521] sub-objects can be used, where X bit set as 1 318 indicates that the domain specified SHOULD be excluded from the path 319 computed by the PCE, but MAY be included subject to PCE policy and 320 the absence of a viable path that meets the other constraints and 321 excludes the domain. 323 4.3. Relationship between SVEC Diversity Flags and OF 325 [RFC5440] uses SVEC diversity flag for node, link or SRLG to describe 326 the potential disjointness between the set of path computation 327 requests used in PCEP protocol. This document further extends by 328 adding domain-diverse O-bit in SVEC object and a new OF Code for 329 minimizing the number of shared transit domain. 331 Further [I-D.dhody-pce-of-diverse] defines three new OF codes to 332 maximize diversity as much as possible, in other words, minimize the 333 common shared resources (Node,Link or SRLG) between a set of paths. 335 It may be interesting to note that the diversity flags in the SVEC 336 object and OF for diversity can be used together. Some example of 337 usage are listed below - 339 o SVEC object with domain-diverse bit=1 - ensure full domain- 340 diversity. 342 o SVEC object with domain-diverse bit=1 and node/link diverse bit=1 343 - ensure full domain-diversity, as well as node/link diverse in 344 ingress and egress domain. 346 o SVEC object with domain-diverse bit=0 and OF=MCTD - domain- 347 diversity as much as possible. 349 o SVEC object with domain-diverse bit=0;node/link diverse bit=1 and 350 OF=MCTD - domain-diversity as much as possible, as well as node/ 351 link diverse in ingress, egress and shared transit domains. 353 o SVEC object with domain-diverse bit=1 and OF=MCTD - ensure full 354 domain-diversity. 356 5. Other Considerations 358 5.1. Transit Domain Identifier 360 In case of non-synchronized path computation, Ingress node (i.e. a 361 PCC) should be aware of transit domain identifiers of the primary 362 path. So during the path computation or signaling of the primary 363 path, the transit domain should be identified. 365 A possible solution for path computation could be a flag in RP object 366 requesting domain identifier to be returned in the PCEP path reply 367 message. 369 [Editor's Note: There should be a mechanism in signaling and path 370 computation to obtain the domain information. Further details - TBD] 372 5.2. Diversity v/s Optimality 374 In case of non-synchronized path computation, PCE may be requested to 375 provide an optimal primary path first and then PCC requests for a 376 backup path with exclusion. Note that this approach does not 377 guarantee diversity compared to disjoint path computations for 378 primary and backup path in a synchronized manner. 380 A synchronized path computation with diversity flags and/or objective 381 function is used to make sure that both the primary path and the 382 backup path can be computed simultaneously with full diversity or 383 optimized to be as diverse as possible. In the latter case we may 384 sacrifice optimal path for diversity, thus there is a trade-off 385 between the two. 387 An implementation may further choose to analyze the trade-off i.e. it 388 may send multiple request to PCE asking to optimize based on 389 diversity as well as say, cost and make an intelligent choice between 390 them. 392 6. Security Considerations 394 This document add a new bit to SVEC object and define a new object 395 function. The security of the procedures described in this document 396 depends on PCEP [RFC5440]. [RFC6007] describe security 397 considerations when SVEC are supported. 399 7. Manageability Considerations 401 7.1. Control of Function and Policy 403 In addition to [RFC5440], the PCC should construct the SVECs to 404 identify and associate domain diverse SVEC relationships. 405 Considerations for use of objective functions are mentioned in 406 [RFC5541]. 408 7.2. Information and Data Models 410 The PCEP MIB Module defined in [RFC7420], there are no additional 411 parameters identified in this document. 413 7.3. Liveness Detection and Monitoring 415 The domain-diverse path computation in this document allows PCEs to 416 compute optimal sets of diverse paths. This type of path computation 417 and cooperation may require more time to obtain its results. 418 Therefore, it is recommended for PCEP to support the PCE monitoring 419 mechanism specified in [RFC5886]. 421 7.4. Verify Correct Operations 423 [RFC5440] provides a sufficient description for this document. There 424 are no additional considerations. 426 7.5. Requirements On Other Protocols 428 There should be a mechanism in signaling and path computation to 429 obtain the domain information during primary path computation. 430 Details to be added in future revision. 432 7.6. Impact On Network Operations 434 Mechanisms defined in this document do not have any impact on network 435 operations in addition to those already listed in [RFC5440] and 436 [RFC6007]. 438 8. IANA Considerations 440 TBD. 442 9. Acknowledgments 444 We would like to thank Qilei Wang for starting this discussion in the 445 mailing list. 447 10. References 449 10.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 457 Per-Domain Path Computation Method for Establishing Inter- 458 Domain Traffic Engineering (TE) Label Switched Paths 459 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 460 . 462 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 463 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 464 DOI 10.17487/RFC5440, March 2009, 465 . 467 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 468 "A Backward-Recursive PCE-Based Computation (BRPC) 469 Procedure to Compute Shortest Constrained Inter-Domain 470 Traffic Engineering Label Switched Paths", RFC 5441, 471 DOI 10.17487/RFC5441, April 2009, 472 . 474 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 475 VECtor (SVEC) List for Synchronized Dependent Path 476 Computations", RFC 6007, DOI 10.17487/RFC6007, September 477 2010, . 479 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 480 Path Computation Element Architecture to the Determination 481 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 482 DOI 10.17487/RFC6805, November 2012, 483 . 485 10.2. Informative References 487 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 488 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 489 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 490 . 492 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 493 Path Computation Element Communication Protocol (PCEP) for 494 Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 495 2009, . 497 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 498 Objective Functions in the Path Computation Element 499 Communication Protocol (PCEP)", RFC 5541, 500 DOI 10.17487/RFC5541, June 2009, 501 . 503 [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of 504 Monitoring Tools for Path Computation Element (PCE)-Based 505 Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, 506 . 508 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 509 Hardwick, "Path Computation Element Communication Protocol 510 (PCEP) Management Information Base (MIB) Module", 511 RFC 7420, DOI 10.17487/RFC7420, December 2014, 512 . 514 [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 515 for the Path Computation Element Communication Protocol 516 (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, 517 . 519 [RFC7898] Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, 520 "Domain Subobjects for Resource Reservation Protocol - 521 Traffic Engineering (RSVP-TE)", RFC 7898, 522 DOI 10.17487/RFC7898, June 2016, 523 . 525 [I-D.dhody-pce-of-diverse] 526 Dhody, D. and Q. Wu, "PCE support for Maximizing 527 Diversity", draft-dhody-pce-of-diverse-06 (work in 528 progress), October 2016. 530 Appendix A. Contributor Addresses 532 Ramon Casellas 533 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 534 Av. Carl Friedrich Gauss n7 535 Castelldefels, Barcelona 08860 536 Spain 538 EMail: ramon.casellas@cttc.es 540 Avantika 541 Huawei Technologies 542 Divyashree Techno Park, Whitefield 543 Bangalore, Karnataka 560066 544 India 546 EMail: s.avantika.avantika@gmail.com 548 Authors' Addresses 550 Dhruv Dhody 551 Huawei Technologies 552 Divyashree Techno Park, Whitefield 553 Bangalore, Karnataka 560066 554 India 556 EMail: dhruv.ietf@gmail.com 558 Qin Wu 559 Huawei Technologies 560 101 Software Avenue, Yuhua District 561 Nanjing, Jiangsu 210012 562 China 564 EMail: bill.wu@huawei.com 566 Udayasree Palle 567 Huawei Technologies 568 Divyashree Techno Park, Whitefield 569 Bangalore, Karnataka 560066 570 India 572 EMail: udayasreereddy@gmail.com 573 Xian Zhang 574 Huawei Technologies 575 Bantian, Longgang District 576 Shenzhen 518129 577 P.R.China 579 EMail: zhang.xian@huawei.com