idnits 2.17.1 draft-brissette-bess-evpn-l2gw-proto-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1151 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) == Unused Reference: 'RFC6378' is defined on line 524, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group P. Brissette 3 Internet-Draft A. Sajassi 4 Intended status: Standards Track L. Burdet, Ed. 5 Expires: August 26, 2021 Cisco Systems 6 D. Voyer 7 Bell Canada 8 February 22, 2021 10 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols 11 draft-brissette-bess-evpn-l2gw-proto-06 13 Abstract 15 The existing EVPN multi-homing load-balancing modes defined are 16 Single-Active and All-Active. Neither of these multi-homing 17 mechanisms adequately ethernet-segments facing access networks with 18 Layer-2 Gateway protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. 19 These loop-preventing Layer-2 protocols require a new multi-homing 20 mechanism defined in this draft. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 59 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Single-Flow-Active redundancy mode . . . . . . . . . . . 6 62 3.2. Fast-Convergence . . . . . . . . . . . . . . . . . . . . 7 63 3.2.1. Handling of Topology Change Notification (TCN) . . . 7 64 3.2.2. Propagating L2GW Protocol Events . . . . . . . . . . 7 65 3.2.3. MAC Flush and Invalidation Procedure . . . . . . . . 8 66 3.3. Backwards compatibility . . . . . . . . . . . . . . . . . 8 67 3.3.1. The two-ESI solution . . . . . . . . . . . . . . . . 8 68 3.3.2. RFC7432 Remote PE . . . . . . . . . . . . . . . . . . 9 69 4. ESI-label Extended Community Extension . . . . . . . . . . . 10 70 5. EVPN Inter-subnet Forwarding . . . . . . . . . . . . . . . . 10 71 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 10.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Existing EVPN Single-Active and All-Active multi-homing mechanisms do 83 not address the additional requirements of loop-preventing Layer-2 84 gateway protocols such as G.8032, (M)STP, REP, MPLS-TP, etc. 86 These Layer-2 Gateway protocols require that a given L2 flow of a 87 VLAN be only active on one of the PEs in the multi-homing group, 88 while another L2 flow may be active on the other PE. This is in 89 contrast with Single-Active redundancy mode where all flows of a VLAN 90 are active on a single multi-homing PEs and it is also in contrast 91 with All-Active redundancy mode where all flows of a VLAN are active 92 on all PEs in the redundancy group. 94 This draft defines a new multi-homing mechanism "Single-Flow-Active" 95 specifying that a VLAN can be active on all PEs in the redundancy 96 group but each unique L2 flow of that VLAN can be active on only one 97 of the PEs in the redundancy group at a time. In fact, the 98 Designated Forwarder election algorithm for these L2 Gateway 99 protocols, is not per VLAN but rather for a given L2 flow. A 100 selected PE in the redundancy group must be the only Designated 101 Forwarder for a specific L2 flow, but the decision is not taken by 102 the PE. The loop-prevention blocking scheme occurs in the access 103 network, by the Layer-2 protocol. 105 EVPN multi-homing procedures need to be enhanced to support 106 Designated Forwarder election for all traffic (both known unicast and 107 BUM) on a per L2 flow basis. The Single-Flow-Active multi-homing 108 mechanism also requires new EVPN considerations for aliasing, mass- 109 withdraw, fast-switchover and 110 [I-D.ietf-bess-evpn-inter-subnet-forwarding] as described in the 111 solution section. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 1.2. Terms and Abbreviations 121 AC: Attachment Circuit 123 BUM: Broadcast, Unknown unicast, Multicast 125 DF: Designated Forwarder 127 GW: Gateway 129 L2 Flow: A given flow of a VLAN, represented by (MAC-SA, MAC-DA) 131 L2GW: Layer-2 Gateway 133 MAC-IP: EVPN Route-Type 2 with non-zero IP field 135 G.8032: Ethernet Ring Protection 137 (M)STP: Multi-Spanning Tree Protocol 139 REP: Resilient Ethernet Protocol 141 TCN: Topology Change Notification 143 2. Requirements 145 The EVPN L2GW framework for L2GW protocols in Access-Gateway mode, 146 consists of the following rules: 148 o Peering PEs MUST share the same ESI. 150 o The Ethernet-Segment DF election MUST NOT be performed and 151 forwarding state MUST be dictated by the L2GW protocol. In 152 gateway mode, both PEs are usually in forwarding state. In fact, 153 the access protocol is responsible for operationally setting the 154 forwarding state for each VLAN. 156 o Split-horizon filtering is NOT needed because L2GW protocol 157 ensures there will never be a loop in the access network. The 158 forwarding between peering PEs MUST also be preserved. In 159 Figure 1, CE1/CE4 device may need reachability with CE2 device. 160 ESI-filtering capability MUST be disabled. The ESI label extended 161 comunity advertised to other peering PEs in the redundancy group 162 MUST NOT be applied it if received. 164 o ESI label BGP Extended Community MUST support a new multi-homing 165 mode named "Single-Flow-Active" corresponding largely to the 166 single-active behaviour of [RFC7432], applied per L2 flow rather 167 than per VLAN. 169 o Upon receiving ESI label BGP Extended Community with the single- 170 flow-active load-balancing mode, remote PE MUST: 172 * Disable ESI label processing 174 * Disable aliasing (at Layer-2 and Layer-3 175 [I-D.ietf-bess-evpn-inter-subnet-forwarding]) 177 o The Ethernet-Segment procedures in the EVPN core such as Ethernet 178 A-D per ES and per Ethernet A-D per EVI routes advertisement/ 179 withdraw, as well as MAC and MAC+IP advertisement, remains as 180 explained in [RFC7432] and 181 [I-D.ietf-bess-evpn-inter-subnet-forwarding]. 183 o For fast-convergence, remote PE3 MAY set up two distinct backup 184 paths on a per-flow basis: 186 * { PE1 active, PE2 backup } 188 * { PE2 active, PE1 backup } 189 The backup paths so created, operate as in [RFC7432] section 8.4 190 where the backup PE of the redundancy group MAY immediately be 191 selected for forwarding upon detection of a specific subset of 192 failures: Ethernet A-D per ES route withdraw, Active PE loss of 193 reachability (via IGP detection). An Ethernet A-D per EVI 194 withdraw MUST NOT result in automatic switching to the backup PE 195 as only a subset of the hosts may be changing reachability to the 196 Backup PE, and the remote cannot determine which. 198 o MAC mobility procedures SHALL have precedence over backup path 199 procedure in Single-Flow-Active for tracking host reachability. 201 3. Solution 203 +---+ 204 |CE3| 205 +---+ 206 | 207 | 208 +-----+ 209 +-----| PE3 |-----+ 210 | +-----+ | 211 | | 212 | MPLS/IP | 213 | CORE | 214 | | 215 +-----+ +-----+ 216 | PE1 |-----------| PE2 | 217 +-----+ +-----+ 218 AC1| |AC2 219 | | 220 +---+ +---+ 221 |CE1| |CE2| 222 +---+ +---+ 223 | | 224 | +---+ | 225 +----|CE4|---/ /--+ 226 +---+ 228 Figure 1: EVPN network with L2 access GW protocols 230 Figure 1 shows a typical EVPN network with an access network running 231 a L2GW protocol, typically one of the following: G.8032, (M)STP, REP, 232 MPLS- TP, etc. The L2GW protocol usually starts from AC1 (on PE1) up 233 to AC2 (on PE2) in an open "ring" manner. AC1 and AC2 interfaces of 234 PE1 and PE2 are participants in the access protocol. 236 The L2GW protocol is used for loop avoidance. In above example, the 237 loop is broken on the right side of CE4. 239 3.1. Single-Flow-Active redundancy mode 241 PE1 and PE2 are peering PEs in a redundancy group, and sharing a same 242 ESI. In the proposed Single-Flow-Active mode, load-balancing at PE1 243 and PE2 shares similarities with singular aspects of both Single- 244 Active and All-Active. Designated Forwarder election must not 245 compete with the L2GW protocol and must not result in blocked ports 246 or portions of the access may become isolated. Additionally, the 247 reachability between CE1/CE4 and CE2 is achieved with the forwarding 248 path through the EVPN MPLS/IP core side. Thus, the ESI-Label 249 filtering of [RFC7432] is disabled for Single-Flow-Active Ethernet 250 segments. 252 Finally, PE3 behaves according to EVPN [RFC7432] rules for traffic 253 to/from PE1/PE2. Peering PE, selected per L2 flow, is chosen by the 254 L2GW protocol in the access, and is out of EVPN control. 256 From PE3 point of view, the L2 flows from PE3 destined to CE1/CE4 257 transit via edge node PE1 and the L2 flows destined to CE2 transit 258 via edge node PE2. A specific unicast L2 flow never goes to both 259 peering PEs. Therefore, aliasing of [RFC7432] Section 8.4 cannot be 260 performed by PE3. That node operates in a single-active fashion for 261 each of the unicast L2 flows. 263 The backup path of [RFC7432] Section 8.4 which is also setup for 264 single-active rapid convergence on a per-VLAN basis, is not 265 applicable here. For example, in Figure 1, if a failure happens 266 between CE1 and CE4 the loop-prevention at the right of CE4 is 267 released and: 269 o L2 flows coming from CE3 behind PE3 destined to CE1 still transit 270 through edge device PE1, and shall not switch to PE2 as a backup 271 path. 273 o L2 flows destined to CE4 on the other hand, may be backup switched 274 to PE2 transit node. 276 On PE3, there is no way to know which L2 flow specifically is 277 affected. During the transition time, PE3 may flood until unicast 278 traffic recovers properly. 280 3.2. Fast-Convergence 282 3.2.1. Handling of Topology Change Notification (TCN) 284 In order to address rapid Layer-2 convergence requirement, topology 285 change notification received from the L2GW protocols must be sent 286 across the EVPN network to perform the equivalent of legacy L2VPN 287 remote MAC flush. 289 The generation of TCN is done differently based on the access 290 protocol. In the case of REP and G.8032, TCN gets generated in both 291 directions and thus both of the dual-homing PEs receive it. However, 292 with (M)STP, TCN gets generated only in one direction and thus only a 293 single PE can receive it. That TCN is propagated to the other 294 peering PE for local MAC flushing, and relaying back into the access. 296 In fact, PEs have no direct visibility on failures happening in the 297 access network nor on the impact of those failures over the 298 connectivity between CE devices. Hence, both peering PEs require to 299 perform a local MAC flush on corresponding interfaces. 301 There are two options to relay the access protocol's TCN to the 302 peering PE: in-band or out-of-band messaging. The first method is 303 better for rapid convergence, and requires a dedicated channel 304 between peering PEs. An EVPN-VPWS connection MAY be dedicated for 305 that purpose, connecting the Untagged ACs of both PEs. The latter 306 choice relies on the MAC Mobility BGP Extended Community applied to 307 the Ethernet A-D per EVI route, detailed below. It is a slower 308 method but has the advantage of avoiding a dedicated channel between 309 peering PEs. 311 3.2.2. Propagating L2GW Protocol Events 313 Peering PE in Single Flow Active mode, upon receiving notification of 314 a protocol convergence-event from access (such as TCN), MUST: 316 o As per legacy VPLS, perform a local MAC flush on the access-facing 317 interfaces. An ARP probe is also sent for all hosts previously 318 locally-attached. 320 o Advertise Ethernet A-D per EVI route along with the MAC Mobility 321 BGP Extended Community, with incremented sequence number if 322 previously advertised, in order to perform a remote MAC flush and 323 steer L2 traffic to proper peering PE. The sequence number is 324 incremented by one as a flushing indication to remote PEs. 326 o Ensure MAC and MAC+IP route re-advertisement, with incremented 327 sequence number when host reachability is NOT moving to peering 328 PE. This is to ensure a re-advertisement of current MAC and MAC- 329 IP which may have been flushed remotely upon MAC Mobility Extended 330 Community reception. In theory, it should happen automatically 331 since peering PE, receiving TCN from the access, performs local 332 MAC flush on corresponding interface and will re-learn that local 333 MAC or MAC+IP. 335 o Where an access protocol relies on TCN BPDU propagation to all 336 participant nodes, a dedicated EVPN-VPWS connection MAY be used as 337 an in-band channel to relay TCN between peering PEs. That 338 connection may be auto-generated or can simply be configured by 339 user. 341 3.2.3. MAC Flush and Invalidation Procedure 343 The MAC-Flush procedure described in [RFC7623] is borrowed, and the 344 MAC mobility BGP Extended community is signaled along with the 345 Ethernet A-D per EVI route from a PE in Single-Flow-Active mode. 347 When MAC Mobility BGP Extended Community is received on the Ethernet 348 A-D per EVI route, it indicates to all remote PEs that all MAC 349 addresses associated with that EVI/ESI are "flushed" i.e. must be 350 unresolved. 352 Remote PEs, having previously received Ethernet A-D per ES with 353 Single Flow Active indication from an originating PE, treat the MAC 354 Mobility indication to simply invalidate the MAC entries for that 355 originating PE on an EVI/ESI basis, similar to [RFC7432]'s mass- 356 withdraw mechanism. 358 They remain unresolved until the remote PE receives a route update 359 (or withdraw) for those MAC addresses. Note: the MAC may be re- 360 advertised by the same PE, but also some are expected to have moved 361 to a multi-homing peer, within the same ESI, due to the L2 protocol's 362 action. 364 The sequence number of the MAC Mobility extended community is of 365 local significance from the originating PE, and is not used for 366 comparison between peering PEs. Rather, it is used to signal via BGP 367 successive MAC Flush requests from a given PE per EVI/ESI. 369 3.3. Backwards compatibility 371 3.3.1. The two-ESI solution 373 As a reference, an alternative solution which achieves some, but not 374 all, of the requirements exists: 376 On the PE1 and PE2, 378 a. A single-homed (different) non-zero ESI, or zero-ESI, is used for 379 each PE; 381 b. With no remote Ethernet-Segment routes received matching local 382 ESI, each PE will be designated forwarder for all the local 383 VLANs; 385 c. Each L2GW PE will send Ethernet A-D per ES and per EVI routes for 386 its ESI if non-zero; and 388 d. When the L2GW PEs receive a MAC-Flush notification (STP TCN, 389 G.8032 mac-flush, LDP MAC withdrawal etc.), they send an update 390 of the Ethernet A-D per EVI route with the MAC Mobility extended 391 community and a higher sequence number, using the procedure 392 outlined in Section 3.2.3. 394 While this solution is feasible, it is considered to fall short of 395 the requirements listed in Section 2, namely for all aspects meant to 396 achieve fast-convergence. 398 3.3.2. RFC7432 Remote PE 400 A PE which receives an Ethernet A-D per ES route with the Single- 401 Flow-Active bit set in the ESI-flags, and which does not support/ 402 understand this bit, SHALL discard the bit and continue operating per 403 [RFC7432] (All-Active). The operator should understand the usage of 404 single-flow-active load-balancing mode else it is highly recommended 405 to use the two-ESI approach as described in Section 3.3.1 407 The remote PE3 which does not support Single-Flow-Active redundancy 408 mode as described, will ECMP traffic to peering PE1 and PE2 in the 409 example topology above (Figure 1), per [RFC7432], Section 8.4 410 aliasing and load-balancing rules. PE1 and PE2, which support the 411 Single-Flow-Active redundancy mode MUST setup redirections towards 412 the PE at which the flow is currently active (sub-optimal Layer-2 413 forwarding and sub-optimal Layer-3 routing). 415 Thus, while PE3 will ECMP (on average) 50% of the traffic to the 416 incorrect PE using [RFC7432] operation, PE1 and PE2 will handle this 417 gracefully in Single-Flow-Active mode and redirect across peering 418 pair of PEs appropriately. 420 No extra route or information is required for this. The [RFC7432] 421 and [I-D.ietf-bess-evpn-inter-subnet-forwarding] route advertisements 422 are sufficient. 424 4. ESI-label Extended Community Extension 426 In order to support the new EVPN load-balancing mode (single-flow- 427 active), the ESI label Extended Community is updated. 429 The 1 octet flag field, part of the ESI Label Extended Community, is 430 modified as follows: 432 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type=0x06 | Sub-Type=0x01 | Flags(1 octet)| Reserved=0 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Reserved=0 | ESI Label | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Low-order bit: [7:0] 441 [2:0]- 000 = all-active, 442 001 = single-active, 443 010 = single-flow-active, 444 others = unassigned 445 [7:3]- Reserved 447 Figure 2: ESI Label BGP Extended Community 449 5. EVPN Inter-subnet Forwarding 451 EVPN Inter-subnet forwarding procedures in 452 [I-D.ietf-bess-evpn-inter-subnet-forwarding] works with the current 453 proposal and does not require any extension. Host routes continue to 454 be installed at PE3 with a single remote nexthop, no aliasing. 456 However, leveraging the same-ESI on both L2GW PEs enables ARP/ND 457 synchronization procedures which are defined for All-Active 458 redundancy in [I-D.ietf-bess-evpn-inter-subnet-forwarding]. In 459 steady-state, on PE2 where a host is not locally-reachable the 460 routing table will reflect PE1 as the destination. However, with 461 ARP/ND synchronization based on a common ESI, the ARP/ND cache may be 462 pre-populated with the local AC as destination for the host, should 463 an AC failure occur on PE1. This achieves fast-convergence. 465 When a host moves to PE2 from the PE1 L2GW peer, the MAC mobility 466 sequence number is incremented to signal to remote peers that a 467 'move' has occurred and the routing tables must be updated to PE2. 468 This is required when an Access Protocol is running where the loop is 469 broken between two CEs in the access and the L2GWs, and the host is 470 no longer reachable from the PE1-side but now from the PE2-side of 471 the access network. 473 6. Conclusion 475 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols solves a 476 true problem due to the wide legacy deployment of these access L2GW 477 protocols in Service Provider networks. The current draft has the 478 main advantage to be fully compliant with [RFC7432] and 479 [I-D.ietf-bess-evpn-inter-subnet-forwarding]. 481 7. Security Considerations 483 The same Security Considerations described in [RFC7432] and 484 [I-D.ietf-bess-evpn-inter-subnet-forwarding] remain valid for this 485 document. 487 8. Acknowledgements 489 Authors would like to thank Thierry Couture for valuable review and 490 inputs with respect to access protocol deployments related to 491 procedures proposed in this document. 493 9. IANA Considerations 495 There are no IANA considerations. 497 10. References 499 10.1. Normative References 501 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 502 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 503 Rabadan, "Integrated Routing and Bridging in EVPN", draft- 504 ietf-bess-evpn-inter-subnet-forwarding-11 (work in 505 progress), October 2020. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 513 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 514 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 515 2015, . 517 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 518 Henderickx, "Provider Backbone Bridging Combined with 519 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 520 September 2015, . 522 10.2. Informative References 524 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 525 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 526 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 527 October 2011, . 529 Authors' Addresses 531 Patrice Brissette 532 Cisco Systems 533 Ottawa, ON 534 Canada 536 Email: pbrisset@cisco.com 538 Ali Sajassi 539 Cisco Systems 540 USA 542 Email: sajassi@cisco.com 544 Luc Andre Burdet (editor) 545 Cisco Systems 546 Ottawa, ON 547 Canada 549 Email: lburdet@cisco.com 551 Daniel Voyer 552 Bell Canada 553 Montreal, QC 554 Canada 556 Email: daniel.voyer@bell.ca