idnits 2.17.1 draft-ietf-l2vpn-vpls-ldp-applic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 952. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 4) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([VPLS-BGP], [VPLS-LDP], [L2VPN-REQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 539: '...ng PE. The frame MUST not be forwarded...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Loops in the core VPLS network are prevented by creating a full mesh of transport circuits between PEs and by applying a split-horizon rule. The split-horizon approach prevents a frame received from the backbone network from being sent out anything other than the customer facing ports belonging to that VPLS instance on the receiving PE. The frame MUST not be forwarded out other PW connecting the receiving PE to other PEs participating in the VPLS instance. This provides the necessary protection, network bandwidth optimization and scalability in the carriers' network as it does not rely on link blocking technologies, like spanning tree type protocols. This forwarding mechanism allows PEs to effectively protect the core network from data loops. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2005) is 6981 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VPLS-BGP' is mentioned on line 312, but not defined == Missing Reference: '2547bis' is mentioned on line 139, but not defined == Missing Reference: 'RADIUS-DIS' is mentioned on line 284, but not defined == Missing Reference: 'RFC-2547' is mentioned on line 650, but not defined ** Obsolete undefined reference: RFC 2547 (Obsoleted by RFC 4364) == Missing Reference: 'IF-MIB' is mentioned on line 873, but not defined == Missing Reference: 'LSR-MIB' is mentioned on line 873, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 888, but not defined == Missing Reference: 'BFD' is mentioned on line 888, but not defined == Missing Reference: 'VCCV' is mentioned on line 888, but not defined == Missing Reference: 'AS2547' is mentioned on line 912, but not defined == Unused Reference: 'PWE3-CTRL' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'BGP-VPN' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'RADIUS-DISC' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'BGP-DISC' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: 'VPLS-BRIDGING' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: 'L2VPN-SIG' is defined on line 1007, but no explicit reference was found in the text == Unused Reference: 'L2FRAME' is defined on line 1010, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-05 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-02 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-02 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? -- No information found for draft-ietf-ppvpn-l2-framework - is the name correct? -- No information found for draft-ietf-ppvpn-l2vpn-requirements - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 26 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Document Marc Lasserre 2 L2VPN Working Group Xipeng Xiao 3 Riverstone Networks 5 Yetik Serbest Marc Rapoport 6 SBC Completel 8 Cesar Garrido 9 Telefonica 11 draft-ietf-l2vpn-vpls-ldp-applic-00.txt 12 Expires: October 2004 March 2005 14 VPLS Applicability 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 or will be disclosed, and any of which I become aware will be 21 disclosed, in accordance with RFC 3668. 23 This document is an Internet-Draft and is in full conformance with 24 Sections 5 and 6 of RFC3667 and Section 5 of RFC3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.htm 42 Abstract 44 Virtual Private LAN Service (VPLS) is a layer 2 VPN service that 45 provides multipoint connectivity in the form of an Ethernet emulated 46 LAN, while usual L2 VPN services are typically point-to-point. Such 47 emulated LANs can span across metropolitan area networks as well as 48 wide area networks. 50 [VPLS-LDP] defines a method for signaling MPLS connections between 51 member PEs of a VPN and a method for forwarding Ethernet frames over 52 such connections. This document describes the applicability of such 53 procedures to provide VPLS services. 55 This document also compares the characteristics of this solution 56 against the requirements specified in [L2VPN-REQ]. In summary, there 57 are no architectural limitations to prevent the requirements from 58 being met. But meeting certain requirements (e.g. QoS) is beyond 59 the specification of [VPLS-LDP], and requires careful planning and 60 precise implementation of the Service Provider (SP) networks. This 61 document attempts to capture such issues, presents the potential 62 solutions to these issues, and discusses the pros and cons of each 63 alternative. 65 This document does not cover the applicability of [VPLS-BGP]. 67 Conventions 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 73 Placement of this Memo in Sub-IP Area 75 RELATED DOCUMENTS 77 www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-04.txt 78 www.ietf.org/internet-drafts/draft-ietf-l3vpn-applicability- 79 guidelines-00.txt 81 Table of Contents 83 1. Operation of Signaling and Data Planes..........................4 84 1.1. Signaling Plane...............................................4 85 1.2. Data Plane....................................................4 86 1.2.1. Ingress Processing..........................................4 87 1.2.2. Egress Processing...........................................4 88 1.2.3. Intermediate Node Processing................................5 89 2. VPLS vs. Alternative Approaches.................................5 90 2.1. Ethernet Switching............................................5 91 2.2. BGP/MPLS IP VPN...............................................5 92 3. Provisioning....................................................6 93 3.1. PE Auto-Discovery.............................................6 94 3.2. Operations and Maintenance....................................7 95 4. Migration Impacts...............................................7 96 4.1. Interconnecting L2 Ethernet Islands with a VPLS Core..........7 97 4.2. Migrating an Existing L2 Ethernet Core to a VPLS Core.........8 98 4.3. Interconnecting VPLS networks with ATM/FR networks............9 99 4.4. Adding VPLS Support to an IP Routed Network...................9 100 5. Multi-homing....................................................9 101 6. Loop Prevention................................................11 102 7. Packet Ordering................................................12 103 8. Multi-Domain VPLS Service......................................12 104 9. Maximum Transmission Unit (MTU) Issues.........................12 105 10. Interoperability and Interworking.............................13 106 10.1. Interworking with BGP/MPLS IP VPN...........................13 107 10.2. Interworking With Frame Relay/ATM Attachment Circuits.......13 108 11. Quality of Service............................................13 109 12. Security......................................................14 110 12.1. Customer Access Control and Authentication..................14 111 12.2. Traffic Separation between VPLS Instances...................14 112 12.3. Protection of SP Networks...................................14 113 12.4. Protection of User Data.....................................15 114 13. Scalability...................................................15 115 13.1. Mesh topology...............................................16 116 13.2. Signaling...................................................16 117 13.3. MAC addresses and MAC learning..............................16 118 13.4. Packet replication..........................................16 119 13.5. Broadcast limiting..........................................16 120 13.6. Multicast...................................................17 121 14. Management....................................................17 123 VPLS Overview 125 The primary motivation behind Virtual Private LAN Services (VPLS) is 126 to provide connectivity between geographically dispersed customer 127 sites across MAN/WAN network(s), as if they were connected using a 128 LAN. The intended applications for the end-user can be divided into 129 the following two categories: 131 - Connectivity between customer routers 132 - Connectivity between customer Ethernet switches 134 In addition, VPLS can also be used by the service providers to 135 deliver voice, video , and data services (i.e., triple play, 136 aggregation of IP services over Ethernet access) to connected end- 137 users. 139 Unlike L3 VPNs such as BGP/MPLS IP VPNs [2547bis] where traffic 140 exchanged between customers and service providers must be IP, VPLS 141 only requires traffic to be Ethernet over which any protocol can be 142 transported, e.g. Netbios or IPX. 144 The Service Provider Network is a packet switched network (PSN). 145 The PEs are assumed to be fully meshed (note that the mesh can be 146 broken with HVPLS) with transport tunnels over which customer frames 147 that belong to a specific VPLS instance are encapsulated and 148 forwarded. IP-in-IP, L2TPv3, GRE, and MPLS are examples of transport 149 tunnels. 151 Specific labels used to identify end-to-end paths over such 152 transport tunnels, and these end-to-end paths, which are known as 153 pseudo-wires (PW), are established via targeted LDP [VPLS-LDP]. 155 VPLS defines the bridging rules required for PEs to provide an 156 emulated Ethernet LAN service. In particular, it defines how a loop- 157 free topology must be built, the forwarding rules between PEs, and 158 the signaling method to set up PWs between PEs. The resulting 159 service provides a unique broadcast domain per VPN, with the ability 160 to send unicast, multicast and broadcast traffic (as well as 161 flooding of unknown unicast traffic). 163 1. 164 Operation of Signaling and Data Planes 166 1.1. 167 Signaling Plane 169 As with [PWE3-ETHERNET], [VPLS-LDP] specifies the use of targeted 170 LDP for the signaling of PWs. PWs are established between PEs that 171 are part of the same VPLS instance. 173 1.2. 174 Data Plane 176 1.2.1. 177 Ingress Processing 179 VPLS provides an Ethernet emulated LAN service and hence customer 180 frames are capsulated as Ethernet frames (Ethernet DIX or 802.1). 181 Note that such Ethernet frames can be carried over various access 182 transport technologies (Frame Relay, ATM, etc). Ingress PEs will 183 determine which Forwarding Information Base (FIB) to look up based 184 on the port, VLAN or port/VLAN combination where frames come from. 185 This port to FIB mapping is performed at provisioning time. The 186 destination MAC address is then looked up to determine on which PW 187 this address has been learned from. If the lookup fails, i.e. if 188 this MAC address has not been learned yet, the frame needs to be 189 sent on all the PWs that are part of the corresponding VPLS 190 instance. If the address is known, the frame is sent only over the 191 associated PW. Before actually transmitting the customer frame, it 192 needs to be encapsulated as defined in [PWE3-ETHERNET], and is 193 further encapsulated with the appropriate transport header (e.g. 194 MPLS or GRE). 196 1.2.2. 197 Egress Processing 199 Once the tunnel header has been removed, the egress PE determines 200 from the PW label which FIB to look up to determine the egress 201 interface, i.e., VLAN or port/VLAN combination. The original 202 Ethernet frame is then encapsulated with the proper transmission 203 header if necessary (e.g. Frame Relay header) and sent over the 204 corresponding port. 206 MAC addresses are learned dynamically as traffic is exchanged. New 207 source MAC addresses are learned on a per PW label per VPLS instance 208 basis. An aging timer is used to remove such bindings after a period 209 of time. When user topology changes occur, MAC withdrawal messages 210 in the signaling plane may be used to unlearn MAC addresses to 211 improve convergence time. 213 Egress PEs might also be configured to perform specific egress 214 encapsulation functions (e.g. VLAN translation). 216 1.2.3. 217 Intermediate Node Processing 219 Intermediate nodes (P routers) only act as pure forwarders based on 220 the outer tunnel header. Hence, they do not participate in any VPLS 221 related processing. Only PE routers maintain VPN specific 222 information. This improves the scalability of VPLS service. 224 2. 225 VPLS vs. Alternative Approaches 227 2.1. 228 Ethernet Switching 230 Ethernet can be used to provide multipoint connectivity within small 231 geographical areas such as small metropolitan networks. Pure 232 Ethernet based solutions have scalability issues (e.g. STP 233 limitations, 4095 VLAN limitations). Some enhancements such as QinQ, 234 STP extensions (RSTP, MSTP) provide additional scalability. 236 VPLS overcomes several limitations of Ethernet based solutions by 237 supporting large numbers of VPNs, better traffic engineering, 238 transport link layer independence and better quality of service. 240 It is not uncommon for VPLS networks to be complemented with 241 Ethernet switched networks as an aggregation layer. 243 2.2. 244 BGP/MPLS IP VPN 246 In metropolitan area networks (MANs), BGP is usually not enabled. 247 MANs provide a transport service to end-users. When multiple sites 248 need to be connected within a metro, VPLS offers the appropriate 249 multipoint transport solution. It is expected that a VPLS instance 250 supports up to O(10^2) site interfaces. When multipoint connectivity 251 is required for a higher number of interfaces sites, with a various 252 range of interface types (e.g. dial-up access, IPSec Tunnels), 253 BGP/MPLS IP VPNs can be more appropriate. 255 Section 10.1. describes how VPLS and BGP/MPLS IP VPNs can be 256 complementary. 258 The following sections compare the characteristics of LDP-based VPLS 259 solution against the requirements specified in [L2VPN-REQ]. Key 260 deployment issues that require careful planning and precise 261 implementation of SP networks are highlighted. 263 3. 264 Provisioning 266 To provision a VPLS service for a customer, the first step is to 267 create a Virtual Switching Instance (VSI), and assign the customer 268 attachment circuit (AC) (e.g. port, port/VLAN, ATM VC with 1483b 269 encapsulation, etc.) and PWs (including H-VPLS spokes) to it. The 270 PWs interconnect VSIs at different PEs and MTUs together to form an 271 emulated LAN for the customer. 273 One challenge in doing this is, when a VPLS site needs to be added 274 or removed at a PE, in addition to configuring that particular PE, 275 the network operator needs to find out which other PEs participate 276 in that VPLS instance, and re-configure those PEs. PE auto- 277 discovery can automate this process. The pros and cons of several 278 auto-discovery approaches are discussed in 3.1. . 280 3.1. 281 PE Auto-Discovery 283 Currently there are several proposals for PE auto-discovery: the 284 BGP-based approach [VPLS-BGP], the RADIUS-based approach [RADIUS- 285 DIS], and the Provisioning System-based approach. 287 The BGP and RADIUS-based approaches mandate the use of BGP or 288 RADIUS in every PE, and rely on it to propagate the information of 289 which PEs participate in a VPLS instance (Signaling can 290 automatically happen after the other PEs belonging to the same VPLS 291 instance are discovered). The pros of both approaches are reduced 292 provisioning work and no need for a provisioning system. The con is 293 BGP/RADIUS has to be in every PE, which may not be the case in 294 reality. 296 With the Provisioning System-based approach, network operators do 297 not configure the PEs. Instead, they specify which PEs participate 298 in which VPLS instances at the Provisioning System. The 299 Provisioning System then translates such service information into PE 300 configuration commands and telnet/ssh to the PEs to execute such 301 commands. Because all information related to every VPLS instance is 302 centralized at the Provisioning System, PE auto-discovery is 303 automatically achieved. To add or remove a PE for a VPLS instance, a 304 network operator simply specifies it at the Provisioning System 305 which will then configure the PEs accordingly. 307 For VPLS deployments that span across multiple domains, because the 308 ASBRs (autonomous system border routers) of other domains can be 309 treated as CEs of the current domain, these auto-discovery 310 approaches can all work in the multi-domain case. However, the 311 built-in scalability mechanism in BGP makes the BGP-based auto- 312 discovery more scalable in this scenario [VPLS-BGP]. 314 3.2. 315 Operations and Maintenance 317 To meet the service level agreement (SLA) with their customers, SPs 318 also need to provision the following: 320 - Traffic management throughout the network and on customer 321 facing ports in particular 322 - Traffic Engineering 323 - Traffic protection (e.g. Fast reroute) 324 - Service management (e.g. SLA measurement, OAM, accounting, 325 billing, etc) 327 Manual provisioning for these tasks can be tedious. A provisioning 328 system is highly desirable. If a provisioning system is used, PE 329 auto-discovery may be integrated into it. 331 4. 332 Migration Impacts 334 Migration in this document means replacing, or more often, 335 supplementing, an existing metro Ethernet or ATM/Frame Relay network 336 with a VPLS network. There are four likely scenarios: 338 Interconnecting existing L2 Ethernet islands with a VPLS core 339 Migrating an existing L2 Ethernet core to a VPLS core; 340 Interconnecting a new VPLS network with existing ATM/FR networks 341 Adding VPLS support to an IP routed network 343 Migration impacts may be mitigated through the use of careful 344 planning when building the network. Also, consideration must be 345 taken when integrating with protocols such as STP/MSTP and how 346 control packets (BPDUs) are handled. In addition, one must also 347 consider ongoing standards efforts within various standards bodies 348 such as the IEEE [802.1ad] and the Metro Ethernet Forum to assess 349 future impact of any changes within the provider network. 351 4.1. 352 Interconnecting L2 Ethernet Islands with a VPLS Core 354 Today, many existing metro Ethernet networks are relatively small 355 and cover only specific districts in a metro area. Such networks may 356 simply backhaul traffic to a routing backbone and not interconnected 357 at L2. When metro Ethernet service grows and these networks need to 358 be interconnected at L2, one approach that may be used for a 359 migration strategy is to effectively utilize existing L2 (possibly 360 802.1Q based or QinQ) networks as "islands" attached to an MPLS 361 based VPLS core network. In this particular case, the L2 network 362 uses predetermined Provider 802.1Q tags (P-tags) to transport a 363 given customers traffic. This P-tag is then utilized as a service 364 delimiter that is then stripped prior to being transported across 365 the MPLS cloud. The service delimiting P-tag is used to identify 366 the VPLS instance to which the traffic should be mapped. 368 ----CE1 369 ------- ------- / -------- 370 CE2- / \ / PE1 / \ 371 \ / \ / \ / \ 372 ---| QinQ \ / MPLS/ \ / QinQ | 373 | Domain PE VPLS PE Domain | 374 \ / \ Domain / \ /\ 375 \ / \ / \ / \ 376 ------- ---------- -------- --CE3 378 In this scenario, when different sites of a customer have a mismatch 379 of 802.1Q tags, VLAN translation as defined in [802.1ad] should be 380 applied. 381 ----- 382 / A1 \ 383 ---- ----CE1 | 384 / \ ------- ------- / | | 385 | A2 CE2- / \ / PE1 \ / 386 \ / \ / \ / \ ----- 387 ---- ---| QinQ \ / MPLS/ | 388 | Domain PE2 VPLS | 389 \ / \ Domain / 390 ----- \ / \ / 391 |QinQ|_/ ------- ------- 392 -| | 393 ---- / ------ ---- 394 / \/ \ / \ CE = Customer Edge Router 395 | A3 CE3 --C4 A4 | PE = Provider Edge Router 396 \ / \ / 397 ---- ---- 399 4.2. 400 Migrating an Existing L2 Ethernet Core to a VPLS Core 402 CE1 403 ------------------- ------ / 404 / \ -|VPLS| / 405 / \ / | PE |- 406 / \ ------ 407 / \ 408 | 802.1Q/QinQ | 409 \ / 410 ----- \ /\ ------ 411 |VPLS|_/ \ / \ |VPLS| 412 -| PE | \ / -| PE |- 413 / ------ ------------------- ------ \ 415 / \ \ 416 CE3 --CE4 CE2 418 Providers that have already deployed VLAN based core may choose to 419 build a parallel VPLS core and connect it to the existing 802.1Q/Q- 420 in-Q core. The 802.1Q/Q-in-Q core is effectively treated as a 421 super-island. Then one by one, each individual Ethernet access 422 island is disconnected from the existing core (i.e. super-island) 423 and connected to the VPLS core. The migration issues then become 424 similar to those described in 4.1. and interoperability aspects 425 between .1ad network and MPLS/VPLS network need to be worked out 426 before such migration 428 A second approach consists in configuring a second VPLS control 429 plane in the existing QinQ PE, hence implementing two virtual 430 networks over a single physical infrastructure. Once the PE/MPLS 431 control plane is running, each customer can be separately migrated 432 through a reconfiguration of its corresponding access ports. For 433 increased stability, the dual control plane approach might require 434 dedicating some links or PEs to the MPLS/VPLS network. 436 4.3. 437 Interconnecting VPLS networks with ATM/FR networks 439 If interworking at L2 is needed, the existing ATM/FR networks would 440 need to carry bridge-encapsulated traffic. VPLS can support ATM and 441 Frame Relay (FR) attachment circuits with Ethernet bridge 442 encapsulation. Once the FR/ATM encapsulation has been stripped off, 443 the resulting Ethernet frames can be processed as if they came from 444 an Ethernet link. Therefore, interworking can be naturally achieved. 446 If the existing ATM/FR networks do not carry bridge-encapsulated 447 traffic, then interworking can only happen at L3. For example, if 448 both VPLS and ATM/FR carry IP traffic, then an IP router can be used 449 to interconnect the two networks. 451 4.4. 452 Adding VPLS Support to an IP Routed Network 454 In such a scenario, if existing PEs can support VPLS, then they can 455 continue to serve as PEs. Otherwise, new VPLS PEs need to be added 456 and existing IP routers will serve as Ps or as Layer3-only PEs. 457 Depending on whether the existing IP routers support MPLS or not, 458 MPLS or some other tunneling mechanism such as GRE can be used. 460 5. 461 Multi-homing 463 Multi-homing is necessary in order to remove a VPLS PE as a single 464 point of failure for all devices attached to it. There are two 465 instances of multi-homing that apply to VPLS: 467 - When a CE device is connected to more than one PE, 468 - In the case of hierarchical VPLS - when an MTU-s device is 469 connected to more than one PE-rs. 471 In both of these cases, the concern is that a particular MAC address 472 will appear as a source on more than one PE device, causing other PE 473 devices to continuously change their FIBs with regard to the true 474 location of the MAC. This will cause constant table thrashing on 475 the remote PEs, a behavior akin to a Layer 2 switch which 476 participates in a loop. 478 It is therefore required that any Layer 2 loops, created by multi- 479 homing of a CE or an MTU-s, be resolved within the group of devices 480 participating in that loop. This group includes the multi-homed CE 481 or MTU-s, and all PEs to which it is attached. The PEs involved in 482 such a loop are connected with a full mesh of PWs per VPLS instance. 484 There are two approaches to resolving the loops created by the 485 multi-homed devices: 487 - Running an MSTP instance between all devices in the group. In 488 this case, the PEs within the group will need to utilize a P- 489 VLAN for the purposes of running MSTP in the group. This P- 490 VLAN can be re-used on non-overlapping groups of multi-homed CE 491 (or MTU-s) and its PEs. It must be clear that the MSTP 492 process discussed here is a completely different and 493 independent instance of STP than any STP the customer may be 494 running. Such customer STP is always tunneled through the VPLS 495 network, and is never acted upon by the PE or MTU-s devices. 497 - The MTU-s or the CE can designate its link to one of the PEs it 498 connects to as primary and only send packets for this 499 particular VPLS instance over that link. In this case the MTU- 500 s (CE) is responsible for monitoring the state of that link and 501 for switching to an alternate link if the primary fails. No 502 action is required from the PEs participating in the group, 503 though there should be an indication given from the MTU-s to 504 its connected PEs as to whether the PE is connected to the 505 primary or backup link. This is a very lightweight approach, 506 which is quite useful given the simple and known topology 507 between the CE (MTU-s) and its PEs. With this approach the 508 operator must ensure that PWs in the core remain up, as long as 509 the ingress PE they start from is up. This can typically be 510 ensured with MPLS TE tools, such as fast re-route or back-up 511 LSPs. If there is no available path between the ingress PE and 512 the Egress PEs, a mechanism that monitors the status of the PWs 513 to force the access connection to go down when the PWs are down 514 might be useful. If PWs in the core go down while their ingress 515 PE is up and accepting customer traffic, black-holes can occur. 517 In each case, the PE nodes are most likely in two different physical 518 locations in the provider network providing network element 519 protection, last mile protection, fiber diversity and provider 520 facility backup. Customer STP traffic is always tunneled through the 521 provider network, and is never acted upon by the PE or MTU-s 522 devices. 524 Lastly, it should be observed that, since VPLS services provide 525 Ethernet switch-like transport level services, the customer is free 526 to connect any device they desire as a CE. This could be anything 527 from a simple host, hub, L2 switch, or a router. The operator has 528 to be cognizant of the different capabilities of each of those 529 devices to ensure loop-free environment when multi-homed. 531 6. 532 Loop Prevention 534 Loops in the core VPLS network are prevented by creating a full mesh 535 of transport circuits between PEs and by applying a split-horizon 536 rule. The split-horizon approach prevents a frame received from the 537 backbone network from being sent out anything other than the 538 customer facing ports belonging to that VPLS instance on the 539 receiving PE. The frame MUST not be forwarded out other PW 540 connecting the receiving PE to other PEs participating in the VPLS 541 instance. This provides the necessary protection, network bandwidth 542 optimization and scalability in the carriers' network as it does not 543 rely on link blocking technologies, like spanning tree type 544 protocols. This forwarding mechanism allows PEs to effectively 545 protect the core network from data loops. 547 Customer networks need to be able to transparently transport the 548 protocol information that allows their network to properly converge. 549 However, the provider should consider loop protection schemes 550 between the CE and PE that do not affect the customer functions. 551 This would be in addition to spanning tree when the PE connects to a 552 VLAN based L2 metro or when the customer is directly connected to 553 multiple PE nodes. 555 The provider should look at deploying a loop protection scheme that 556 would intervene automatically when it detects a loop condition on 557 customer access ports. This loop protection scheme serves as an 558 additional line of defense against protocol failures or 559 misconfigurations, which can result in data loops. The concern is 560 that a particular MAC address will appear as a source on more than 561 one PE device, causing other PE devices to continuously update their 562 tables. An external loop protection scheme adds a level of insurance 563 above the customer link protection schemes. Its function is to 564 reduce unnecessary core bandwidth usage when a loop condition occurs 565 in an adjacent network and provide an extra level of protection to 566 multi-homed networks. It is a complement but not a replacement for 567 traditional loop protection mechanisms, like spanning tree. Such a 568 loop protection scheme could be based on the monitoring of the 569 number of Mac addresses moving from one attachment circuit/PW to 570 another circuit/PW. 572 With directly connected customers, careful consideration needs to be 573 given to backdoor connections. Backdoor connections provide an 574 alternate path around a single provider. If a loop detection scheme 575 is invoked here the customer may be forced to traverse a link that 576 is not desired. 578 7. 579 Packet Ordering 581 Normally there is only one transmission path towards a destination 582 with VPLS. So there is no packet re-ordering issue. But if some 583 load balancing mechanism is enabled or if LSPs carrying VPLS traffic 584 are rerouted, packets may be re-ordered inside the PSN. Note that 585 reordering can be avoided when load balancing flows across PWs. 586 Flows can be identified through a number of identifiers in the 587 packet, including MPLS labels, MAC addresses, IP addresses, and 588 UDP/TCP ports. 590 VPLS data packets use the encapsulation mechanism defined in [PWE3- 591 ETHERNET]. An optional control word which contains a sequence number 592 field can be used to assist in-order delivery. If the user's 593 applications are sensitive to packet re-ordering, this option may be 594 used. However, enabling sequencing usually causes forwarding 595 performance degradation. Another alternative is to avoid load 596 sharing for traffic inside a LSP and pin down LSPs to avoid 597 rerouting. 599 8. 600 Multi-Domain VPLS Service 602 As the use of VPLS grows, it is expected that customers will require 603 a single VPLS service delivered by different providers (e.g. either 604 for redundancy or because none of the SPs has the presence to 605 support all the sites of a customer). Different providers would then 606 need to interconnect their VPLS domains for these customers. [VPLS- 607 LDP] has provision for such a requirement, utilizing a full mesh of 608 LSPs among the VPLS gateways of these domains. However, experience 609 of such interconnection is not yet available. 611 9. 612 Maximum Transmission Unit (MTU) Issues 614 Because of the encapsulation and transport headers, the MTU for user 615 applications will be smaller than the smallest MTU of all the 616 physical links. In responding to path MTU discovery message, each 617 network device must deduct the total header size from a physical 618 link's MTU. Since path MTU discovery is not always used, SPs must 619 clearly communicate the potential MTU issue to their customers and 620 ask for their cooperation. In reality, most applications will work 621 fine but a small number of them may be affected. This is by no 622 means specific to VPLS. Any networks that put additional header(s) 623 on customer's packets will have the same issue. 625 10. 626 Interoperability and Interworking 628 Interoperability should be ensured by proper implementation of the 629 published standards. 631 10.1. 632 Interworking with BGP/MPLS IP VPN 634 When interworking VPLS with BGP/MPLS IP VPN, a BGP/MPLS IP VPN (in 635 the backbone) is typically used to interconnect VPLS domains in 636 multiple metros, with such VPLS domains acting as Ethernet 637 aggregation networks for the IP service. In this type of scenario, 638 the BGP/MPLS IP VPN will carry inter-metro traffic whereas VPLS will 639 handle intra-metro traffic. 641 A useful method for interconnecting a VPLS with a BGP/MPLS IP VPN is 642 to use a "link" to interconnect the VSI and the VRF. Such a "link" 643 can be a physical port, a VLAN spanning across one or multiple 644 physical hops, or 2 LSPs with one in each direction, etc. 645 Analogously, this is like interconnecting a L2 switch with a router, 646 with the VSI as the switch and the VRF as the router. 648 Access/transport networks such as VPLS can also be interconnected 649 with BGP/MPLS IP VPNs using various mechanisms such as Carrier's 650 Carrier as defined in [RFC-2547]. 652 10.2. 653 Interworking With Frame Relay/ATM Attachment Circuits 655 Frame Relay (FR) and ATM attachment circuits with Ethernet bridged 656 encapsulation can be terminated within VPLS PEs. The resulting 657 Ethernet frames (i.e. once the FR/ATM encapsulation has been 658 stripped off) are processed as standard Ethernet frames. 660 In order to support a complete interworking model between FR and 661 Ethernet or between ATM and Ethernet, mapping service profiles and 662 OAM traffic from one to the other are necessary. Additionally, 663 circuit management (e.g. LMI to PW state mapping) between the 664 various technologies are required. Such standards are being defined 665 by other standard organizations such as the MPLS-FR-ATM Alliance. 667 11. 668 Quality of Service 670 The provision of appropriate QoS capabilities may require any 671 combination of the following: 673 - QoS in the access network. 674 - Admission control by the PE router on the ingress access links. 675 - Classification by the PE, for traffic arriving from the CE. 676 Once the PE classifies a user packet, this classification needs 677 to be preserved in the encapsulation (MPLS EXP or IP DSCP) used 678 to send the packet across the backbone. 680 - Traffic conditioning (policing or shaping) by the PE router on 681 the ingress access links. 682 - DSCP/EXP-based queuing and WRED in the VPLS network 683 - Traffic engineering in the VPLS network. 684 - Fast reroute in the VPLS network 686 None of these features are VPLS specific. The ability to support 687 them depends on whether the features are available on the edge and 688 core devices. It is up to the SPs to decide how to use such 689 mechanisms to provide QoS. Such mechanisms can be used to support 690 either the "hose model" or the "pipe model", although the hose model 691 is a more natural fit and is usually the support model by default. 693 12. 694 Security 696 12.1. 697 Customer Access Control and Authentication 699 Control of the customer access can be achieved by controlling 700 physical access to the CEs, the PEs and the links between them. If 701 multiple customers use 802.1Q service delimiting tags in the same 702 trunk link to access VPLS service, and the tags are put on by the 703 customers themselves, ACLs should be used to ensure that each 704 customer only puts on the tag that it is supposed to put on. Packets 705 with other tag(s) must be dropped. 707 802.1x may be used for CE device authentication. 709 12.2. 710 Traffic Separation between VPLS Instances 712 VPLS instances maintain separation of broadcast domains between 713 themselves. Traffic entering a given VPLS instance at a given PE 714 device does not, under any circumstances, cross the boundaries of 715 the VPLS into another instance. VPLS devices (PEs and MTU-s) ensure 716 that by maintaining a FIB table and a full mesh of PWs on a per-VPLS 717 instance basis. 719 The above statement is correct regardless of the learning mode 720 employed by a particular VPLS instance (qualified or unqualified), 721 or whether or not VLANs are treated as broadcast domain identifiers, 722 or simply as circuit IDs which have no significance in determining 723 the broadcast domain. In either of these cases, the VPLS instance 724 is the outer-most "envelope" which ensures that traffic within it 725 does not "leak" into another VPLS instance. 727 12.3. 728 Protection of SP Networks 730 Two types of DoS attacks are of concern with VPLS: 732 - Attacks against VPLS devices 733 - Attacks against other devices, for which the VPLS network is a 734 transport. 736 Attacks of the first type are naturally of greater concern for a 737 VPLS operator, because they can destabilize the VPLS network as a 738 whole, and affect multiple customers. The tunneling nature of VPLS 739 by itself limits the possibilities for attacks via the data plane, 740 simply because such attacks will be tunneled through the VPLS 741 network, and will create the same load on the VPLS equipment as 742 legitimate traffic will. 744 Operators must watch for exception packet handling in VPLS 745 equipment. In many cases, exception packets are sent to the control 746 plane for handling. If that is the case, the operator must ensure 747 that such exception packets can be rate-limited in a fashion that 748 guarantees that the control plane will not be significantly burdened 749 by them. A SP should limit the amount of traffic that a customer can 750 flood. 752 The second type of DoS attacks, which use the VPLS network as a 753 transport, are not really a threat to the VPLS devices themselves 754 but are to devices behind them. VPLS PEs may be configured with 755 rate-limiting and rate-shaping capabilities which permit them to 756 limit the amount of traffic allowed into a particular VPLS instance. 757 This prevents a VPLS customer from consuming excessive amount of 758 network resources and from starving other customers. For example, it 759 might be useful to limit the multicast/broadcast/unknown traffic of 760 the customer, considering that the replication of this traffic will 761 create a load in the core proportional to the number of PEs 762 participating to the VPLS instance. Optionally, they can also be 763 tasked with advanced processing of the traffic they tunnel. For 764 example, they may impose access lists which deny traffic from 765 particular sources or protocols. 767 Such approaches however are highly vendor-specific and outside the 768 scope of [VPLS-LDP]. In addition, they may have significant design 769 and operational repercussions. Alternative approaches which hand- 770 off DoS protection activities to non-VPLS devices (such as customer 771 equipment) are a possibility. 773 12.4. 774 Protection of User Data 776 VPLS does not have special provisioning for ensuring user data 777 security. If a customer's traffic is IP traffic, that customer may 778 provide its own user data security by using IPsec. In fact, VPLS is 779 compatible with any use of security by the customer, as long as a 780 clear text Ethernet header is passed from CE to PE. 782 13. 783 Scalability 785 As per [L2VPN-REQ], a large SP may eventually require support of up 786 to O(10^4) VPLS instances. In addition, some of these VPLS instances 787 may need to support O(10^2) sites and O(10^3) users/MACs. This 788 section describes the key scalability challenges and how VPLS-LDP 789 addresses them. 791 13.1. 792 Mesh topology 794 A full mesh of tunnel LSPs, over which a full mesh of PWs is 795 established, is created between participating PEs. When using 796 hierarchical VPLS constructs, the size of this full mesh can be 797 reduced to hub PEs aggregating point-to-point spokes as described in 798 section 10 of [VPLS-LDP]. 800 This reduces the number of tunnels and PWs from O(N*N) to O(N). 802 13.2. 803 Signaling 805 Using HVPLS constructs also allows the total number of targeted LDP 806 sessions to be reduced from O(N*N) to O(N). 808 13.3. 809 MAC addresses and MAC learning 811 Depending on the type of CE devices used, i.e. switches or routers, 812 the total number of MAC addresses to be learned by VPLS PEs can vary 813 from one address per site to a large number of MAC addresses. 815 When Ethernet networks exceed a large number of MAC addresses (e.g. 816 hundreds), routers are introduced to limit the size of such 817 broadcast domains. This reduces the total number of MAC addresses to 818 learn to such routers only. 820 In the case of large flat Ethernet networks, ingress PEs must be 821 able to limit the number of MAC addresses that can be learned on a 822 per VPLS basis. 824 13.4. 825 Packet replication 827 With VPLS, broadcast, multicast and unknown destination frames get 828 replicated by the ingress PEs, i.e. close to the source of the 829 frame. Ideally such frames should be replicated as close to the 830 destination as possible to minimize bandwidth consumption. With 831 hierarchical VPLS, the replication process is distributed between 832 several ingress and egress MTUs and PEs. This helps not only 833 minimizing bandwidth resources but also improving multicast 834 performance and reducing latency. 836 13.5. 837 Broadcast limiting 839 Ingress MTUs or PEs may be able to rate limit the amount of 840 broadcast/multicast/unknown traffic generated by end users in order 841 to protect core resources and to prevent a few users from using all 842 the bandwidth available. 844 13.6. 845 Multicast 847 In order to optimize the replication of multicast traffic, it is 848 highly desirable for PEs to support multicast snooping techniques in 849 order to only forward traffic where needed. In the case where the CE 850 device is an L2 switch, IGMP snooping would be required, however, if 851 the CE device is a router PIM snooping would be more applicable. 853 14. 854 Management 856 The following five major areas in management are discussed bellow: 858 - Fault 859 - Configuration 860 - Accounting 861 - Provisioning 862 - Security 864 VPLS introduces new configurations related to creation and removal 865 of VSIs, etc. VPLS also introduces new provisioning challenges 866 because the service needs to be delivered end-to-end and therefore 867 many things such as access control, QoS, etc need to be provisioned 868 accordingly. Achieving these via manual CLI configuration can be 869 error prone. Therefore, it is advisable to use a provisioning system 870 for configuration and provisioning. 872 Although VPLS-specific MIBs are still under development, accounting 873 information can usually be achieved via [IF-MIB] and [LSR-MIB]. The 874 important point is that accounting information should be available 875 per service basis. Such information can then be processed by an 876 accounting application to produce the accounting records. Security 877 can be achieved by the measures described in Section 0. 879 Managing fault with VPLS involves multi-point connectivity 880 verification and locating the fault if there is one. Such mechanism 881 is sometimes referred to as "VPLS OAM" and is discussed below. 883 Although VPLS OAM is still being defined, one of the approaches has 884 gained momentum. This approach proposes applying Ethernet OAM 885 mechanism that is being standardized by ITU, IEEE and the Metro 886 Ethernet Forum (MEF) to an VPLS environment for L2 connectivity 887 verification and fault locating, and applying MPLS OAM mechanism 888 such as [LSP-PING] or [BFD] or [VCCV] to MPLS connectivity 889 verification and fault locating. Of course, if IP tunnels (e.g. GRE) 890 are used, IP ping and traceroute can be used in the place of MPLS 891 OAM. VPLS OAM is therefore achieved by integrating OAM mechanisms at 892 different layers together. 894 In summary of this section: management of VPLS services involves 895 many things and can be tedious. A complete suite of management 896 software including EMS, NMS and a provisioning system can therefore 897 be highly desirable. 899 Acknowledgments 901 The authors wish to thank the following people for their 902 constructive contributions to the text in this document: 904 Javier Antich 905 Ian Cowburn 906 Richard Foote 907 Rob Nath 908 Ali Sajassi 909 Nick Slabakov 911 Some text was adapted from the Applicability Statement for BGP/MPLS 912 IP VPNs [AS2547] document. 914 Copyright Notice 916 Copyright (C) The Internet Society (2004). This document is subject 917 to the rights, licenses and restrictions contained in BCP 78, and 918 except as set forth therein, the authors retain all their rights. 920 Disclaimer 922 This document and the information contained herein are provided on 923 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 924 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 925 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 926 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 927 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 928 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 930 IPR Disclosure Acknowledgement 932 The IETF takes no position regarding the validity or scope of any 933 Intellectual Property Rights or other rights that might be claimed 934 to pertain to the implementation or use of the technology described 935 in this document or the extent to which any license under such 936 rights might or might not be available; nor does it represent that 937 it has made any independent effort to identify any such rights. 938 Information on the procedures with respect to rights in RFC 939 documents can be found in BCP 78 and BCP 79. 941 Copies of IPR disclosures made to the IETF Secretariat and any 942 assurances of licenses to be made available, or the result of an 943 attempt made to obtain a general license or permission for the use 944 of such proprietary rights by implementers or users of this 945 specification can be obtained from the IETF on-line IPR repository 946 at http://www.ietf.org/ipr. 948 The IETF invites any interested party to bring to its attention any 949 copyrights, patents or patent applications, or other proprietary 950 rights that may cover technology that may be required to implement 951 this standard. Please address the information to the IETF at 952 ietf-ipr@ietf.org. 954 Release Statement 956 By submitting this Internet-Draft, the authors accept the provisions 957 of Section 4 of RFC 3667. 959 Normative References 961 [VPLS-LDP] "Virtual Private LAN Services over MPLS", Marc Lasserre, 962 Vach Kompella, et al., draft-ietf-l2vpn-vpls-ldp-05.txt, Work in 963 progress, September 2004 965 [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet 966 Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- 967 02.txt, Work in progress, February 2003. 969 [PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf- 970 pwe3-control-protocol-02.txt, Work in progress, February 2003. 971 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 972 January 2001. 974 [RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036. 975 January 2001. 977 [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std 802.1D- 978 1993 "MAC Bridges". 980 [802.1D-REV] 802.1D - "Information technology - Telecommunications 981 and information exchange between systems - Local and metropolitan 982 area networks - Common specifications - Part 3: Media Access Control 983 (MAC) Bridges: Revision. This is a revision of ISO/IEC 10038: 1993, 984 802.1j-1992 and 802.6k-1992. It incorporates P802.11c, P802.1p and 985 P802.12e." ISO/IEC 15802-3: 1998. 987 [802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE 988 Standards for Local and Metropolitan Area Networks: Virtual Bridged 989 Local Area Networks", July 1998. 991 Informative References 993 [BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". draft-ietf-ppvpn- 994 rfc2547bis-04.txt, Work in Progress, May 2003. 996 [RADIUS-DISC] " Using Radius for PE-Based VPN Discovery", Juha 997 Heinanen, draft-heinanen-radius-pe-discovery-04.txt, Work in 998 Progress, June 2003. 1000 [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- 1001 based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto- 1002 05.txt, Work in Progress, May 2003. 1004 [VPLS-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls- 1005 00.txt, Work in Progress, June 2002. 1007 [L2VPN-SIG] "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2- 1008 signaling-03.txt, Work in Progress, May 2003. 1010 [L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work 1011 in Progress, February 2003. 1013 [L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned 1014 Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements- 1015 00.txt, Work in Progress, May 2003. 1017 [802.1ad] "IEEE standard for Provider Bridges", Work in Progress, 1018 December 2002. 1020 Authors' Addresses 1022 Marc Lasserre 1023 Riverstone Networks 1024 Email: marc@riverstonenet.com 1026 Xipeng Xiao 1027 Riverstone Networks 1028 Email: xxiao@riverstonenet.com 1030 Yetik Serbest 1031 SBC Communications 1032 Yetik_serbest@labs.sbc.com 1034 Cesar Garrido, 1035 Telefonica 1036 cesar.garridosanahuja@telefonica.es 1038 Marc Rapoport 1039 Completel 1040 m.rapoport@completel.fr