idnits 2.17.1 draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4664], [IEEE.802.1Q-2011]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2013) is 3968 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT F. Balus (editor) 3 Intended Status: Informational Alcatel-Lucent 4 Expires: December 15, 2013 Ali Sajassi (editor) 5 Cisco 6 Nabil Bitar (editor) 7 Verizon 9 June 13, 2013 11 Extensions to VPLS PE model for Provider Backbone Bridging 12 draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt 14 Abstract 16 IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines 17 an architecture and bridge protocols for interconnection of multiple 18 Provider Bridge Networks (PBNs). PBB was defined in IEEE as a 19 connectionless technology based on multipoint VLAN tunnels. PBB can 20 be used to attain better scalability in terms of number of customer 21 MAC addresses and number of service instances that can be supported. 23 Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for 24 extending Ethernet LAN services, using MPLS tunneling capabilities, 25 through a routed MPLS backbone without running RSTP or MSTP across 26 the backbone. As a result, VPLS has been deployed on a large scale in 27 service provider networks. 29 This draft discusses extensions to the VPLS Provider Edge (PE) model 30 required to incorporate desirable PBB components while maintaining 31 the Service Provider fit of the initial model. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. General terminology . . . . . . . . . . . . . . . . . . . . . . 4 73 3. PE Reference Model . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Packet Walkthrough . . . . . . . . . . . . . . . . . . . . . . 9 75 5. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. Efficient Packet replication in PBB VPLS . . . . . . . . . . . 11 77 7. PBB VPLS OAM . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines 90 an architecture and bridge protocols for interconnection of multiple 91 Provider Bridge Networks (PBNs). PBB provides data plane hierarchy 92 and new addressing designed to improve the scalability of MAC 93 addresses and service instances in Provider Backbone Networks. A 94 number of Ethernet control plane protocols such as Rapid Spanning 95 Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP) and 96 Shortest Path Bridging (SPB), could be deployed as the core control 97 plane for loop avoidance and load balancing for PBB. The 98 applicability of these control protocols is out of scope for this 99 document. 101 Virtual Private LAN Service (VPLS) provides a solution for extending 102 Ethernet LAN services, using MPLS tunneling capabilities, through a 103 routed MPLS backbone without requiring the use of an native Ethernet 104 control plane protocol across the backbone. VPLS use of the 105 structured FEC 129 [RFC4762] also allows for inter-domain, inter- 106 provider connectivity and enables auto-discovery options across the 107 network improving the service delivery options. 109 A hierarchical solution for VPLS was introduced in [RFC4761] and 110 [RFC4762] for the purpose of improved scalability and to provide 111 efficient handling of packet replication. These improvements are 112 achieved by reducing the number of Provider Edge (PE) devices 113 connected in a full-mesh topology through the creation of two-tier 114 PEs. A User-facing PE (U-PE) aggregates all the CE devices in a 115 lower-tier access network and then connects to the Network-facing PE 116 (N-PE) device(s) deployed around the core domain. In VPLS, Media 117 Access Control (MAC) address learning and forwarding are done based 118 on customer MAC addresses (C-MACs), which poses scalability issues on 119 the N-PE devices as the number of VPLS instances (and thus customer 120 MAC addresses) increases. Furthermore, since a set of PWs is 121 maintained on a per customer service instance basis, the number of 122 pseudowires (PWs) required at N-PE devices is proportional to the 123 number of customer service instances multiplied by the number of N-PE 124 devices in the full-mesh set. This can result in scalability issues 125 (in terms of PW manageability and troubleshooting) as the number of 126 customer service instances grows. 128 This document describes how PBB can be integrated with VPLS to allow 129 for useful PBB capabilities while continuing to avoid the use of MSTP 130 in the backbone. The combined solution referred in this document as 131 PBB-VPLS results in better scalability in terms of number of service 132 instances, PWs and Customer MACs (C-MACs) that need to be handled in 133 the VPLS PEs. 135 Section 2 gives a quick terminology reference. Section 3 covers the 136 reference model for PBB VPLS PE. Section 4 describes the packet 137 walkthrough. Section 5 to 7 discusses the PBB-VPLS usage of existing 138 VPLS mechanisms - control plane, efficient packet replication, 139 Operations, Administration, and Maintenance (OAM). 141 2. General terminology 143 Some general terminology is defined here; most of the terminology 144 used is from [IEEE.802.1Q-2011], [RFC4664] and [RFC4026]. Terminology 145 specific to this memo is introduced as needed in later sections. 147 802.1ad: See PB. 149 802.1ah: See PBB. 151 B-BEB: A backbone edge bridge positioned at the edge of a provider 152 backbone bridged network. It contains a B-component that supports 153 bridging in the provider backbone based on Backbone MAC (B-MAC) and 154 B-TAG information 156 B-MAC: The backbone source or destination MAC address fields defined 157 in the PBB provider MAC encapsulation header. 159 BEB: A backbone edge bridge positioned at the edge of a provider 160 backbone bridged network. It can contain an I-component, B-component 161 or both I and B components. 163 B-component: A bridging component contained in backbone edge and core 164 bridges that bridges in the backbone space (B-MAC addresses, B-VLAN) 166 B-TAG: field defined in the PBB provider MAC encapsulation header 167 that conveys the backbone VLAN identifier information. The format of 168 the B-TAG field is the same as that of an 802.1ad S-TAG field. 170 B-Tagged Service Interface: This is the interface between a BEB and 171 BCB in a provider backbone bridged network. Frames passed through 172 this interface contain a B-TAG field. 174 B-VID: The specific VLAN identifier carried inside a B-TAG 176 B-VLAN: The backbone VLAN associated with a B-component. 178 B-PW: The pseudowire used to interconnect B-component instances. 180 CVID: The VLAN identifier in a customer VLAN. 182 DA: Destination Address 184 I-component: A bridging component contained in a backbone edge bridge 185 that bridges in the customer space (customer MAC addresses, S-VLAN) 187 IB-BEB: A backbone edge bridge positioned at the edge of a provider 188 backbone bridged network. It contains an I-component for bridging in 189 the customer space (customer MAC addresses, service VLAN IDs) and a 190 B-component for bridging the provider's backbone space (B-MAC, B- 191 TAG). 193 I-BEB: A backbone edge bridged positioned at the edge of a provider 194 backbone bridged network. It contains an I-component for bridging in 195 the customer space (customer MAC addresses, service VLAN IDs). 197 I-SID: The 24-bit service instance field carried inside the I-TAG. I- 198 SID defines the service instance that the frame should be "mapped 199 to". 201 I-TAG: A field defined in the PBB provider MAC encapsulation header 202 that conveys the service instance information (I-SID) associated with 203 the frame. 205 I-Tagged Service Interface: This the interface defined between the I 206 and B components inside an IB-BEB or between two B-BEB. Frames passed 207 through this interface contain an I-TAG field 209 PB: Provider Bridge IEEE amendment (802.1ad) to 802.1Q for "QinQ" 210 encapsulation and bridging of Ethernet frames [IEEE.802.1Q-2011]. 212 PBB: Provider Backbone Bridge IEEE amendment (802.1ah) to 802.1Q for 213 "MAC tunneling" encapsulation and bridging of frames across a 214 provider network [IEEE.802.1Q-2011]. 216 PBBN: Provider Backbone Bridged Network 218 PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) 219 technology. 221 SA: Source Address 223 S-TAG: A field defined in the 802.1ad QinQ encapsulation header that 224 conveys the service VLAN identifier information (S-VLAN). 226 S-Tagged Service Interface: This the interface defined between the 227 customer (CE) and the I-BEB or IB-BEB components. Frames passed 228 through this interface contain an S-TAG field. 230 S-VLAN: The specific service VLAN identifier carried inside an S-TAG 232 SVID: The VLAN identifier in a service VLAN. 234 TAG: In Ethernet a header immediately following the Source MAC 235 Address field of the frame. 237 3. PE Reference Model 239 The following gives a short primer on Provider Backbone Bridge (PBB) 240 before describing the PE reference model for PBB-VPLS. The internal 241 components of a PBB bridge module are depicted in Figure 1. 243 +-------------------------------+ 244 | PBB Bridge Model | 245 | | 246 +---+ | +------+ +-----------+ | 247 |CE |---------|I-Comp|------| | | 248 +---+ | | | | |-------- 249 | +------+ | | | 250 | o | B-Comp | | 251 | o | |-------- 252 | o | | | 253 +---+ | +------+ | | | 254 |CE |---------|I-Comp|------| |-------- 255 +---+ ^ | | | ^ | | | ^ 256 | | +------+ | +-----------+ | | 257 | +------------|------------------+ | 258 | | | 259 | | | 260 S-tagged I-tagged B-tagged 261 Service I/F Service I/F Service Interface (I/F) 263 Figure 1: PBB Bridge Model 265 Provider Backbone Bridges (PBBs) [IEEE.802.1Q-2011] offers a scalable 266 solution for service providers to build large bridged networks. The 267 focus of PBB is primarily on improving two main areas with provider 268 Ethernet bridged networks: 270 - MAC-address table scalability 271 - Service instance scalability 273 To obviate the above two limitations, PBB introduces a hierarchical 274 network architecture with associated new frame formats which extend 275 the work completed by Provider Bridges (PB). In the PBBN 276 architecture, customer networks (using PB) are aggregated into 277 Provider Backbone Bridge Networks (PBBNs) which utilize the IEEE PBB 278 frame format. The frame format employs a MAC tunneling encapsulation 279 scheme for tunneling customer Ethernet frames within provider 280 Ethernet frames across the PBBN. A VLAN identifier (B-VID) is used to 281 segregate the backbone into broadcast domains and a new 24-bit 282 service identifier (I-SID) is defined and used to associate a given 283 customer MAC frame with a provider service instance (also called the 284 service delimiter). It should be noted that in [IEEE.802.1Q-2011] 285 there is a clear segregation between provider service instances 286 (represented by I-SIDs) and provider VLANs (represented by B-VIDs) 287 which was not the case for PB. 289 As shown in the figure 1, a PBB bridge may consist of a single B- 290 component and one or more I-components. In simple terms, the B- 291 component provides bridging in provider space (B-MAC, B-VLAN) and the 292 I-component provides bridging in customer space (C-MAC, S-VLAN). The 293 customer frame is first encapsulated with the provider backbone 294 header (B-MAC, B-tag, I-tag); then, the bridging is performed in the 295 provider backbone space (B-MAC, B-VLAN) through the network till the 296 frame arrives at the destination BEB where it gets de-encapsulated 297 and passed to the CE. If a PBB bridge consists of both I & B 298 components, then it is called IB-BEB and if it only consists of 299 either B-component or I-component, then it is called B-BEB or I-BEB 300 respectively. The interface between an I-BEB or IB-BEB and a CE is 301 called S-tagged service interface and the interface between an I-BEB 302 and a B-BEB (or between two B-BEBs) is called I-tagged service 303 interface. The interface between a B-BEB or IB-BEB and a Backbone 304 Core Bridge (BCB) is called B-Tagged service interface. 306 To accommodate the PBB components the VPLS model defined in [RFC4664] 307 is extended as depicted in figure 1. 309 +----------------------------------------+ 310 | PBB-VPLS-capable PE model | 311 | +---------------+ +------+ | 312 | | | |VPLS-1|------------ 313 | | |==========|Fwdr |------------ PWs 314 +--+ | | Bridge ------------ |------------ 315 |CE|-|-- | | +------+ | 316 +--+ | | Module | o | 317 | | | o | 318 | | (PBB | o | 319 | | bridge) | o | 320 | | | o | 321 +--+ | | | +------+ | 322 |CE|-|-- | ------------VPLS-n|------------- 323 +--+ | | |==========| Fwdr |------------- PWs 324 | | | ^ | |------------- 325 | +---------------+ | +------+ | 326 | | | 327 +-------------------------|--------------+ 328 LAN emulation Interface 330 Figure 2: PBB-VPLS capable PE Model 332 The PBB Module as defined in [IEEE.802.1Q-2011] specification is 333 expanded to interact with VPLS Forwarders. The VPLS Forwarders are 334 used in [RFC4762] to build a PW mesh or a set of spoke-PWs 335 (Hierarchical VPLS (HVPLS) topologies). The VPLS instances are 336 represented externally in the MPLS context by a Layer 2 Forwarding 337 Equivalence Class (L2FEC) which binds related VPLS instances 338 together. VPLS Signaling advertises the mapping between the L2FEC and 339 the PW labels and implicitly associates the VPLS bridging instance to 340 the VPLS Forwarders [RFC4762]. 342 In the PBB-VPLS case the backbone service instance in the B-component 343 space(B-VID) is represented in the backbone MPLS network using a VPLS 344 instance. Same as for the regular VPLS case, existing signaling 345 procedures are used to generate through PW labels the linkage between 346 VPLS Forwarders and the backbone service instance. 348 Similarly with the regular HVPLS, another L2FEC may be used to 349 identify the customer service instance in the I-component space. This 350 will be useful for example to address the PBB-VPLS N-PE case where 351 HVPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE. 353 It is important to note that the PBB-VPLS solution inherits the PBB 354 service aggregation capability where multiple customer service 355 instances may be mapped to a backbone service instance. In the PBB- 356 VPLS case this means multiple customer VPNs can be transported using 357 a single VPLS instance corresponding to the backbone service 358 instance, thus reducing substantially resource consumption in the 359 VPLS core. 361 4. Packet Walkthrough 363 Since the PBB bridge module inherently performs forwarding, the PE 364 reference model of Figure 2 can be expanded as the one shown in 365 Figure 3. 367 Furthermore, the B-component is connected via several virtual 368 interfaces to the PW Forwarder module. The function of PW Forwarder 369 is defined in [RFC3985]. In this context, the PW Forwarder simply 370 performs the mapping of the PWs to the Virtual Interface on the B- 371 component without the need for any MAC lookup. 373 This simplified model takes full advantage of PBB module where all 374 the PBB[IEEE.802.1Q-2011] procedures including the C-MAC/B-MAC 375 forwarding and PBB encapsulation/de-capsulation takes place and thus 376 avoids specifying any of these functions in here. 378 Because of text-based graphics, the Figure 3 only shows PWs on the 379 core-facing side; however, in case of MPLS access with spoke PWs, the 380 PE reference model is simply extended to include the same PW 381 Forwarder function on the access-facing side. To avoid cluttering the 382 figure, the access-side PW Forwarder (Fwdr) is not depicted without 383 loss of any generality. 385 +------------------------------------------------+ 386 | PBB-VPLS-capable PE model | 387 | +---------------+ +------+ | 388 | | | | | | 389 | +------+ | ======== --------- 390 +--+ | | | | | | --------- PWs 391 |CE|-|-- | I- ==== ======== PW --------- 392 +--+ | | comp | | | | Fwdr | 393 | +------+ | | | --------- PWs 394 | | B-Comp ======== --------- 395 | | | ^ | | | 396 | +------+ | | | +------+ | 397 +--+ | | I- | | OOOOOOOOOOOOOOOOOOOOOOOO B-tag 398 |CE|-|-- | comp ==== | | | I/Fs 399 +--+ | | |^ | OOOOOOOOOOOOOOOOOOOOOOOO 400 | +------+| | | | | 401 | | +---------------+ | | 402 | | | | 403 +-----------|--------------------|---------------+ 404 | | 405 Internal I-tag I/Fs Virtual Interfaces (I/Fs) 407 +----------+ +------------+ 408 |CMAC DA,SA| | PSN header | 409 |----------| |------------| 410 |SVID, CVID| | PW Label | 411 |----------| |------------| 412 | Payload | | BMAC DA,SA | 413 +----------+ |------------| 414 | PBB I-tag | 415 |------------| 416 | CMAC DA,SA | 417 |------------| 418 | SVID, CVID | 419 |------------| 420 | Payload | 421 +------------+ 423 Figure 3: Packet Walkthrough for PBB VPLS PE 425 In order to better understand the data plane walkthrough let us 426 consider the example of a PBB packet arriving over a Backbone 427 pseudowire (B-PW). The PSN header is used to carry the PBB 428 encapsulated frame over the backbone while the PW Label will point to 429 the related Backbone Service Instance (B-SI), same as for regular 430 VPLS. The PW Label has in this case an equivalent role with the 431 Backbone VLAN id on the PBB B-tagged interface. 433 An example of the PBB packet for regular Ethernet PW is depicted in 434 Figure 3 on the right hand side. The MPLS packet from MPLS core 435 network is received by the PBB-VPLS PE. The PW Forwarder function of 436 the PE uses PW label to derive the virtual interface-id on the B- 437 component and then after removing the PSN and PW encapsulation, it 438 passes the packet to the B-component. From there on, the processing 439 and forwarding is performed according to the PBB [IEEE.802.1Q-2011] 440 where bridging based on backbone MAC (B-MAC) Destination Address DA 441 is performed which result in one of the three outcomes: 443 1. The packet is forwarded to a physical interface on the B- 444 component. In this case, the PBB Ethernet frame is forwarded as 445 is. 447 2. The packet is forwarded to a virtual interface on the B- 448 component. This is not typically the case because of a single 449 split-horizon group within a VPLS instance; however, if there is 450 more than one split-horizon group, then such forwarding takes 451 place. In this case, the PW Forwarder module adds the PSN and PW 452 labels before sending the packet out. 454 3. The packet is forwarded toward the access side via one of the I- 455 tagged service interfaces connected to the corresponding I- 456 components. In this scenario, the I-component removes the B-MAC 457 header according to PBB [IEEE.802.1Q-2011] and bridges the packet 458 using C-MAC DA. 460 4. If the destination B-MAC is an unknown or a Group MAC address 461 (Multicast or Broadcast), then the B-component floods the 462 packet to one or more of the three destinations described above. 464 5. Control Plane 466 The control plane procedures described in [RFC6074], [RFC4761] and 467 [RFC4762] can be re-used in a PBB-VPLS to setup the PW infrastructure 468 in the service provider and/or customer bridging space. This allows 469 porting the existing control plane procedures (e.g. BGP Auto- 470 discovery (BGP-AD), PW setup, VPLS MAC Flush, PW OAM) for each 471 domain.) 473 6. Efficient Packet replication in PBB VPLS 475 The PBB VPLS architecture takes advantage of the existing VPLS 476 features addressing packet replication efficiency. HVPLS hierarchy 477 may be used in both customer and backbone service instances to reduce 478 the redundant distribution of packets over the core. IGMP and PIM 479 snooping may be applied on a per customer service instance to control 480 the distribution of the Multicast traffic to non-member sites. 482 IEEE 802.1Q [IEEE.802.1Q-2011] specifies the use of Multiple MAC 483 registration (MMRP) protocol for flood containment in the backbone 484 instances. The same solution can be ported in the PBB-VPLS solution. 486 Further optimizations of the packet replication in PBB-VPLS are out 487 of the scope of this draft. 489 7. PBB VPLS OAM 491 The existing VPLS, PW and MPLS OAM procedures may be used in each 492 customer or backbone service instance to verify the status of the 493 related connectivity components. 495 PBB OAM procedures make use of the IEEE Ethernet Connectivity Fault 496 Management (CFM) [IEEE.802.1Q-2011] and ITU-T Y.1731 [Y.1731] tools 497 in both I-component and B-component. 499 Both set of tools (PBB and VPLS) may be used for the combined PBB- 500 VPLS solution. 502 8. Security Considerations 504 No new security issues are introduced beyond those that are described 505 in [RFC4761] and [RFC4762]. 507 9. IANA Considerations 509 IANA does not need to take any action for this draft. 511 10. References 513 10.1. Normative References 514 [RFC4761] Kompella, K. and Rekhter, Y. (Editors), "Virtual Private 515 LAN Service (VPLS) Using BGP for Auto-Discovery and 516 Signaling", RFC 4761, January 2007. 518 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private 519 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 520 Signaling", RFC 4762, January 2007. 522 [RFC6074] E. Rosen, et Al. "Provisioning, Autodiscovery and Signaling 523 in L2VPNs", RFC 6074, January 2011 525 10.2. Informative References 527 [RFC3985] Bryant, S. and Pate, P. (Editors)," Pseudo Wire Emulation 528 Edge-to-Edge (PWE3) Architecture", RFC 3985, May 2005. 530 [RFC4664] Andersson, L. and Rosen, E. (Editors),"Framework for Layer 531 2 Virtual Private Networks (L2VPNs)", RFC 4664, Sept 2006 533 [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan 534 area networks -- Media Access Control (MAC) Bridges and 535 Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 536 2011. 538 [Y.1731] Y.1731 (2006), ITU-T Recommendation, OAM functions and 539 mechanisms for Ethernet based networks 541 [RFC4026] Andersson, L. et Al., "Provider Provisioned Virtual Private 542 Network (VPN) Terminology", RFC 4026, May 2005. 544 11. Contributors 546 The following authors contributed to this document: John Hoffmans 547 (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme 548 Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent). 550 12. Acknowledgments 552 The authors would like to thank Wim Henderickx, Mustapha Aissaoui, 553 Dimitri Papadimitriou, Pranjal Dutta, Jorge Rabadan, Maarten Vissers 554 and Don Fedyk for their insightful comments and probing questions. 556 Authors' Addresses 558 Ali Sajassi 559 Cisco 560 170 West Tasman Drive 561 San Jose, CA 95134, U.S. 562 Email: sajassi@cisco.com 564 Nabil Bitar 565 Verizon 566 40 Sylvan Road 567 Waltham, MA 02145 568 Email: nabil.bitar@verizon.com 570 Florin Balus 571 Alcatel-Lucent 572 701 E. Middlefield Road 573 Mountain View, CA, USA 94043 574 Email: florin.balus@alcatel-lucent.com 576 Matthew Bocci 577 Alcatel-Lucent, 578 Voyager Place 579 Shoppenhangers Road 580 Maidenhead 581 Berks, UK 582 e-mail: matthew.bocci@alcatel-lucent.com 584 Raymond Zhang 585 Alacatel-Lucent 586 EMail: raymond.zhang@alcatel.com 588 Geraldine Calvignac 589 Orange 590 2, avenue Pierre-Marzin 591 22307 Lannion Cedex 592 France 593 Email: geraldine.calvignac@orange.com 595 John Hoffmans 596 KPN 597 Regulusweg 1 598 2516 AC Den Haag 599 Nederland 600 Email: john.hoffmans@kpn.com 602 Olen Stokes 603 Extreme Networks 604 PO Box 14129 605 RTP, NC 27709 606 USA 607 Email: ostokes@extremenetworks.com