idnits 2.17.00 (12 Aug 2021) /tmp/idnits52404/draft-petrescu-relay-route-pd-problem-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational L. Yeh 5 Expires: April 24, 2014 Freelancer Technologies 6 A. Petrescu 7 CEA 8 October 21, 2013 10 Route Problem at Relay during DHCPv6 Prefix Delegation 11 draft-petrescu-relay-route-pd-problem-00.txt 13 Abstract 15 The operation of a prefix delegation procedure with the DHCPv6 16 protocol may need route setup and maintenance at the Delegating 17 Router, Requesting Router and on the entity on which the Relay agent 18 is implemented. This document describes the problem of routing 19 during DHCPv6 prefix delegation, and is illustrated by ADSL-type and 20 cellular-type of topologies which may use Relays; we refer to section 21 14 of RFC 3633 which mentions the need of 'a protocol or other out of 22 band communication to add routing information for delegated 23 prefixes'. Based on this problem, a number of requirements from the 24 service providers are described. 26 A small set of documented solutions are separately mentioned 27 (snooping, route injection, etc.), together with their pros and cons 28 according to a particular judgment. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 24, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Problem and the Related Topologies . . . . . . . . . . . . . . 3 66 3.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.2. Relay vs. non-Relay Topologies . . . . . . . . . . . . . . 4 68 3.3. Relay Topologies for Large-scale Deployments . . . . . . . 6 69 4. Issues and Requirements . . . . . . . . . . . . . . . . . . . 8 70 5. Potential Solutions, Solution Space . . . . . . . . . . . . . 10 71 5.1. DHCPv6 message snooping for PD-prefix . . . . . . . . . . 10 72 5.2. ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix . . . . . 10 73 5.3. draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix 74 pool of PD . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.4. draft-joshi-dhc-dhcpv6-aggr-route-opt for aggregation 76 route of PD . . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 13 84 Appendix B. Software . . . . . . . . . . . . . . . . . . . . . . 13 85 Appendix C. draft-stenberg-pd-route-maintenance-00 . . . . . . . 13 86 Appendix D. Snooping only . . . . . . . . . . . . . . . . . . . . 13 87 Appendix E. ICMP Redirect . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 The operation of a prefix delegation procedure with the DHCPv6 93 protocol may need route setup and maintenance at the Delegating 94 Router, Requesting Router and on the entity on which the Relay agent 95 is implemented. This document describes the problem of routing 96 during DHCPv6 prefix delegation, and is illustrated by ADSL-type and 97 cellular-type of topologies which may use Relays; we refer to section 98 14 of RFC 3633 which mentions the need of 'a protocol or other out of 99 band communication to add routing information for delegated 100 prefixes'. Based on this problem, a number of requirements from the 101 service providers are described. 103 A small set of documented solutions are separately mentioned 104 (snooping, route injection, etc.), together with their pros and cons 105 according to a particular judgment. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 PE router stands for 'Provider Edge' router. It is a router in the 114 provider's network, situated at its edge. It is connected directly 115 to the CE router ('Customer's Edge') which is situated within the 116 customer's network, at its edge. 118 3. Problem and the Related Topologies 120 3.1. Problem 122 This is a problem mentioned in the context of the specification of 123 the Relay Agent behaviour, in DHCPv6 Prefix Delegation [RFC3633]. If 124 the network topology in which running Prefix Delegation is run 125 involves a Relay Agent, then the delegating router may need a 126 protocol or other out-of-band communication to add routing 127 information for delegated prefixes into any router through which the 128 requesting router may forward traffic. That protocol or out-of-band 129 communication are left unspecified. 131 A more detailed interpretation of that problem is described next. 133 Intuitively, the Prefix Delegation operation consists in a request 134 and a delegation phase (more precisely, a prefix allocation is 135 performed by the software in the Server, and messages such as 136 Solicit/Advertise/Request/Reply are used, see [RFC3315]). In the 137 request phase, the Requesting Router requests an IPv6 prefix (not 138 just an IPv6 address). In the delegation phase, the Delegating 139 Router allocates (reserves) a prefix for use by the Requesting 140 Router; this prefix is then sent by the Delegating Router to the 141 Requesting Router. 143 Allocating a prefix is an operation different than allocating simply 144 an address. In IPv6, one of the differences relates to the way in 145 which the routing is set up with respect to the allocated parameter. 146 The routing for the allocated address is pre-set ((1) the address is 147 part of a prefix, and the routing is pre-set for that prefix and (2) 148 the address is allocated by the Server and may be resolved on-link); 149 whereas the routing for a prefix can not be pre-set ((1) it is next 150 to impossible to pre-aggregate several /64 allocated prefixes into a 151 single pre-set /64 prefix and (2) the IP address of the next-hop is 152 not known at the Server during the prefix allocation phase, being 153 pre-configured on the Client, and not relayed in the messages sent by 154 the Relay; yet this address is needed for route setup). The concepts 155 of numbered and unnumbered interface may also play a distinctive 156 role. 158 An alternative explanation: in the case of allocating an address, the 159 routing is pre-set for one particular prefix, during network setup 160 operation. Due to the imposed length of the Interface ID on the 161 widely used Ethernet-type of links, that pre-set prefix has length 162 64. That particular prefix covers the entire set of addresses which 163 may be dynamically allocated by DHCP. On the contrary, dynamically 164 allocating a prefix does not benefit of this pre-setting of routing, 165 because of that 64 limit. One can not pre-set a prefix of length 64 166 which covers other prefixes of same length /64. There is thus a need 167 to dynamically set a route for the allocated prefix (because it is 168 not possible to pre-set routes for allocated prefixes). 170 3.2. Relay vs. non-Relay Topologies 172 In practice, some topologies may accommodate easily the deployment of 173 Prefix Delegation, yet other topologies may pose problems with 174 respect to PD. A topology where the Requesting Router is a neighbor 175 to the Delegating Router, and the Requesting Router's default route 176 is the Delegating Router, may easily accommodate the Prefix 177 Delegation operation (in this case too, the delegating router needs 178 the operation of route set-up for network reachability). This 179 topology is pictured below. 181 /----------\ 182 | Internet | 183 \----------/ 184 | 185 +------------+ 186 | Delegating | 187 | Router | 188 +------------+ 189 | 190 +------------+ 191 |Requestting | 192 | Router | 193 +------------+ 194 | +--------+ 195 \------------| Host PC| 196 +--------+ 198 On another hand, a topology where the Requesting Router is not an 199 immediate IP neighbor to the Delegating Router, and/or RR's default 200 route is not the DR, the operation of allocating a prefix must 201 necessarily involve an operation of route set up. This topology is 202 illustrated below. 204 /----------\ 205 | Internet | 206 \----------/ 207 | 208 | +------------+ 209 ...--------| Delegating | 210 | | Router | 211 | +------------+ 212 | 213 +------------+ 214 | DHCP Relay | 215 +------------+ 216 | 217 +------------+ 218 | Requesting | 219 | Router | 220 +------------+ 221 | +--------+ 222 \------------| Host PC| 223 +--------+ 225 The operation of Prefix Delegation in the topology illustrated above 226 needs to provoke the setting up of a route at the DHCP Relay during 227 the Prefix Delegation operation. Otherwise, the DHCP Relay will not 228 be able to forward packets addressed to Host PC (which is configured 229 with an address in the range of the allocated prefix). 231 This problem statement if related exclusively to the operation of the 232 Relay Agent and the computer (Router or Host) on which this Agent 233 runs. These entities are direct neighbors (in the sense of the 234 Neighbor Discovery protocol) with the interface on which the 235 Requesting Router emits the DHCPv6 Request message. On another hand, 236 a similar problem, is considered in a more generic manner: upon 237 delegation, use a routing protocol to maintain routing state at 238 Delegating Routers, at other intermediary routers (for routers not 239 necessarily direct neighbors to the RR), and at the Requesting 240 Router; this is described in section 2.3.4 of 241 [I-D.stenberg-pd-route-maintenance]. 243 3.3. Relay Topologies for Large-scale Deployments 245 The Figure 1 in [RFC3633] illustrates a network architecture in which 246 prefix delegation could be used. That architecture is relating 247 directly to the use of DSL deployments. 249 The following topologies pertinent for large-scale deployments are 250 considered. A topology for home deployments, and a topology of 251 mobile hotspots (tethering smartphone) are pictured. 253 +------+------+ DHCPv6 Server 254 | DHCPv6 | 255 | Server | 256 | | 257 +------+------+ 258 | 259 _________|_________ 260 / \ 261 | ISP Core Network | 262 \___________________/ 263 | Network-facing interface 264 | 265 +------+------+ 266 | Provider | 267 | Edge | DHCPv6 Relay Agent, DHCPv6 Requestor 268 | Router | 269 +------+------+ 270 | Customer-facing interface 271 _________|_________ 272 / \ 273 | Access Network | 274 \___________________/ 275 | 276 | 277 +------+------+ 278 | Customer | DHCPv6 Client 279 | Edge | DHCPv6-PD Requesting Router 280 | Router | 281 +------+------+ 282 | 283 _________|_________ 284 / \ 285 | Customer Network | 286 \___________________/ 287 +-------------+ 288 ___________________|Correspondent| 289 | | Node | 290 | +-------------+ 291 /--------\ (peer node, RFC6275) 292 |Internet| 293 \--------/ 294 | 295 /--------\ +------------+ 296 |Cellular|_____________| DHCP Server| 297 |Network | +------------+ 298 \--------/ Delegating Router 299 | 300 +--------+ 301 | Access | 302 | Router | 303 | DHCP | 304 | Relay | 305 +--------+ 306 | 307 cellular radio link 308 | 309 +-----------+ 310 | Tethering | Requesting 311 | Smartphone| Router 312 +-----------+ 313 | +-----------+ 314 |-- wifi ---| 'tethered'| 315 | PC | 316 +-----------+ 318 In the above figure, the cellular network is considered to be similar 319 to an ISP network. 321 4. Issues and Requirements 323 As a reminder, the main requirement from service providers is the 324 following: 326 o Need for deterministic and dynamic means to drive route aggregates 327 and associated route announcement actions to be undertaken by PE 328 routers while ensuring a consistency with prefix assignment 329 states. In particular: 331 * Optimizing the size of routing and forwarding tables must be 332 supported. As such, route aggregation must be supported by 333 these routers. 335 * Failures to deliver incoming packets to a customer serviced 336 behind a given PE router must be avoided. Dedicated routing 337 actions must be achieved to ensure incoming traffic will be 338 forwarded to the appropriate customer's device. Nevertheless, 339 triggers to drive the level of route aggregation and required 340 route announcement actions must be supported. 342 * Prefix assignments and routing actions must be correlated 343 otherwise delivery of connectivity service will fail. 345 These requirements can be fulfilled by a variety of solutions that 346 have their limits. For instance: 348 o Current practices rely on static configuration. This practice is 349 prone to errors. 351 o The level of route aggregation cannot be driven by PE routers 352 without any hint(s) from an entity that has the visibility on 353 aggregation policies and the status of prefixes, etc. 355 o Relying on proprietary means to trigger the injection of routing 356 entries may lead to undesired behavior: increase the size of 357 routing table and forwarding table due to injecting very specific 358 routes, etc. 360 Note: 362 o Prefix assignment policies can be configured to DHCP servers 363 including topological aware considerations (e.g., regional-based 364 assignment, per-service assignment, etc.). Refer to Section 4 of 365 [I-D.lemon-dhc-topo-conf]. 367 o Status of active (prefix) states is maintained by DHCP servers. 369 o The use of DHCP for this purpose does not require an additional 370 interface to pass the state maintained by the DHCP server to a 371 routing controller which will then undertake appropriate actions. 373 Finally, it is worth mentioning that other standards development 374 organizations consider the use of DHCPv6 Prefix Delegation in 375 particular contexts: 377 o at the Broadband Forum ('BBF'), a technical report titled "IPv6 in 378 the context of TR-101", dated November 2010, [bf], lists a number 379 of requirements derived from the problem that "hosts receiving 380 IPv6 addresses from the RR are not known to the BNG, i.e. the BNG 381 is not aware of what addresses/prefixes are assigned to hosts 382 attached to the RG acting as RR." 384 o at 3GPP, the specification [3gpp-ref] describes the use of DHCPv6 385 prefix delegation using S2c. It is for a "User Equipment acting 386 as a Mobile Router". 388 5. Potential Solutions, Solution Space 390 5.1. DHCPv6 message snooping for PD-prefix 392 The Provider Edge (PE) router acting as relay snoops every reply 393 message from the server with valid lease. Per the parameters, such 394 as valid-lifetime and preferred-lifetime, shown the IA_PD option, PE 395 router knows the lease of each delegated prefix. Then the PE can add 396 and withdraw the associated route per the lease of each delegated 397 prefix. 399 Pros: no new messages and options defined, no additional function on 400 the relay. 402 Cons: but PE router need to snoop each DHCPv6-PD message, then take 403 action for routing per the lease of each delegated prefix. 405 In the real deployed network, PE router always need to handle each 406 protocol message in the control plane including DHCPv6 message. That 407 makes snooping sounds not a problem for PE router. Almost every 408 implementation of PE router today in the Telecom's network adopts the 409 method of snooping to get the lease of each delegated prefix. 411 5.2. ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix 413 [I-D.ietf-dhc-dhcpv6-agentopt-delegate]. 415 The relay use OPTION_ORO to request the assigned address or the 416 delegated prefixes for the client from the server. But the draft has 417 not mentioned in which DHCPv6 message the OPTION_ORO will always be 418 employed. 420 Pros: no new messages, just define a new RAAN option 421 (OPTION_AGENT_NOTIFY) to convey OPTION_IAADDR and OPTION_IAPREFIX, 422 sounds it can de-couple with the DHCPv6-PD mechanism. 424 Cons: sounds only for the route @ relay (or PE router) co-related 425 with the delegated prefix, have no route aggregation. 427 Due to PE router need to interpret and handle each protocol message 428 in the control plane, it can get the assigned address or the 429 delegated prefixes directly from the DHCPv6 message. That makes RAAN 430 option unnecessary. 432 5.3. draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix pool of PD 434 [I-D.ietf-dhc-dhcpv6-prefix-pool-opt]. 436 PE router acting as relay use OPTION_ORO in the relay-forward of 437 DHCPv6-PD message to request the information about the prefix pool 438 (and its status). After the PE got the OPTION_PREFIX_POOL in the 439 Relay-reply message, it can add the aggregation route per the status 440 (or lease) of the prefix pool. The aggregation route can 441 dramatically reduce the size of the routing table in the ISP network. 443 Pros: no new messages, just define a new option (OPTION_PREFIX_POOL) 444 to convey the information about prefix pools. 446 Cons: lightweight but piggyback on the UDP-based DHCPv6 message. 448 This draft hasn't achieve Consensus yet, but may need to simplify the 449 mechanism to gain more support. 451 5.4. draft-joshi-dhc-dhcpv6-aggr-route-opt for aggregation route of PD 453 [I-D.joshi-dhc-dhcpv6-aggr-route-opt] 455 PE router acting as relay tries to employ new messages exchange 456 between relay and server, including new function of information- 457 request, renew and reply, reconfigure. That make the communication 458 between the relay and server to be the communication between hosts. 460 Pros: de-coupled from the DHCPv6-PD mechanism, communication between 461 hosts could employ the reliable TCP. 463 Cons: introduce new functionality defined for the relay and server, 464 define new messages and option (OPTION_AGGR_ROUTE), have problem of 465 synchronization for the status of aggregation route or for the leases 466 of delegated prefixes. 468 This draft may be incomplete work, maybe further discussion may be 469 needed. 471 6. Security Considerations 472 7. IANA Considerations 474 8. Acknowledgements 476 The authors would like to acknowledge Mikael Abrahamsson 478 9. References 480 9.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 486 and M. Carney, "Dynamic Host Configuration Protocol for 487 IPv6 (DHCPv6)", RFC 3315, July 2003. 489 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 490 Host Configuration Protocol (DHCP) version 6", RFC 3633, 491 December 2003. 493 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 494 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 495 September 2007. 497 9.2. Informative References 499 [3gpp-ref] 500 "3GPP TS 23.402 V12.2.0 (2013-09), Technical 501 Specification, 3rd Generation Partnership Project; 502 Technical Specification Group Services and System Aspects; 503 Architecture enhancements for non-3GPP accesses (Release 504 12), http://www.3gpp.org/ftp/Specs/archive/23_series/ 505 23.402/23402-c20.zip accessed on October 7th, 2013". 507 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 508 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 509 Assignment Notification (RAAN) Option", 510 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 511 progress), July 2009. 513 [I-D.ietf-dhc-dhcpv6-prefix-pool-opt] 514 leaf.yeh.sdo@gmail.com, l., Lemon, T., and M. Boucadair, 515 "Prefix Pool Option for DHCPv6 Relay Agent on the Provider 516 Edge Routers", draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 517 (work in progress), April 2013. 519 [I-D.joshi-dhc-dhcpv6-aggr-route-opt] 520 Joshi, S., "Aggregate Route Option for Dynamic Host 521 Control Protocol version 6 (DHCPv6)", 522 draft-joshi-dhc-dhcpv6-aggr-route-opt-01 (work in 523 progress), September 2011. 525 [I-D.lemon-dhc-topo-conf] 526 Lemon, T., "Customizing DHCP Configuration on the Basis of 527 Network Topology", draft-lemon-dhc-topo-conf-01 (work in 528 progress), April 2013. 530 [I-D.stenberg-pd-route-maintenance] 531 Stenberg, M. and O. Troan, "IPv6 Prefix Delegation routing 532 state maintenance approaches", 533 draft-stenberg-pd-route-maintenance-00 (work in progress), 534 October 2006. 536 [bf] "Broadband Forum, Technical Report, TR-177, "IPv6 in the 537 Context of TR-101, Issue: 1, Issue date: November 2010", 538 document freely available at the URL http:// 539 www.broadband-forum.org/technical/download/TR-177.pdf 540 accessed on October 4th, 2013.". 542 Appendix A. ChangeLog 544 The changes are listed in reverse chronological order, most recent 545 changes appearing at the top of the list. 547 From draft-relay-route-pd-problem-00.txt to 548 draft-authors-relay-route-pd-problem-00.txt: 550 o first version. 552 Appendix B. Software 554 Prototype implementations. 556 Appendix C. draft-stenberg-pd-route-maintenance-00 558 Appendix D. Snooping only 560 not sure. 562 Appendix E. ICMP Redirect 564 One possible solution to inform an entity in the network about a 565 better route to a destination is to use the message ICMPv6 Redirect, 566 as specified in [RFC4861]. This message is used by Routers to inform 567 hosts about better routes. 569 Some DHCPv6 Prefix Delegation deployments consider that the DHCPv6 570 Relay functionality is co-located within a Router. In this case, it 571 is not possible to use the ICMP Redirect message. 573 However, in other possible deployments, the DHCPv6 Relay 574 functionality is co-located in a Host; in this case the use of ICMPv6 575 Redirect may be possible. An example topology of this use of DHCP 576 Relay on a Host is depicted in the following figure: 578 ________ ---------- 579 | |DHCPServer| 580 ... ---------- 581 | 582 ---------- --------- 583 | Host | | Access | 584 | DHCPRelay| | Router | 585 ---------- --------- 586 | | 587 ----+--------------+ 588 | 589 ---------- ---- 590 |Requesting| | PC | 591 | Router | | | 592 ---------- ---- 593 | | 594 ----+------------+-- 596 Authors' Addresses 598 Mohamed Boucadair 599 France Telecom 600 Rennes, 35000 601 France 603 Email: mohamed.boucadair@orange.com 604 Leaf Y. Yeh 605 Freelancer Technologies 606 P. R. China 608 Email: leaf.yeh.sdo@gmail.com 610 Alexandru Petrescu 611 CEA 612 France 614 Phone: 615 Email: Alexandru.Petrescu@cea.fr