diff options
Diffstat (limited to 'doc/rfc/rfc7041.txt')
| -rw-r--r-- | doc/rfc/rfc7041.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7041.txt b/doc/rfc/rfc7041.txt new file mode 100644 index 0000000..7773883 --- /dev/null +++ b/doc/rfc/rfc7041.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Balus, Ed. +Request for Comments: 7041 Alcatel-Lucent +Category: Informational A. Sajassi, Ed. +ISSN: 2070-1721 Cisco + N. Bitar, Ed. + Verizon + November 2013 + + + Extensions to the Virtual Private LAN Service (VPLS) + Provider Edge (PE) Model for Provider Backbone Bridging + +Abstract + + The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines + an architecture and bridge protocols for interconnection of multiple + Provider Bridged Networks (PBNs). Provider backbone bridging was + defined by IEEE as a connectionless technology based on multipoint + VLAN tunnels. PBB can be used to attain better scalability than + Provider Bridges (PBs) in terms of the number of customer Media + Access Control addresses and the number of service instances that can + be supported. + + The Virtual Private LAN Service (VPLS) provides a framework for + extending Ethernet LAN services, using MPLS tunneling capabilities, + through a routed MPLS backbone without running the Rapid Spanning + Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) + across the backbone. As a result, VPLS has been deployed on a large + scale in service provider networks. + + This document discusses extensions to the VPLS Provider Edge (PE) + model required to incorporate desirable PBB components while + maintaining the service provider fit of the initial model. + + + + + + + + + + + + + + + + + + +Balus, et al. Informational [Page 1] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7041. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. General Terminology .............................................4 + 3. PE Reference Model ..............................................6 + 4. Packet Walkthrough ..............................................9 + 5. Control Plane ..................................................11 + 6. Efficient Packet Replication in PBB VPLS .......................12 + 7. PBB VPLS OAM ...................................................12 + 8. Security Considerations ........................................12 + 9. References .....................................................13 + 9.1. Normative References ......................................13 + 9.2. Informative References ....................................13 + 10. Contributors ..................................................14 + 11. Acknowledgments ...............................................15 + + + + + +Balus, et al. Informational [Page 2] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + +1. Introduction + + The IEEE 802.1 Provider Backbone Bridges specification [PBB] defines + an architecture and bridge protocols for interconnection of multiple + Provider Bridged Networks (PBNs). PBB can be used to attain better + scalability than Provider Bridges [PB] in terms of the number of + customer Media Access Control (MAC) addresses and the number of + service instances that can be supported. PBB provides a data-plane + hierarchy and new addressing designed to achieve such better + scalability in Provider Backbone Networks. A number of Ethernet + control-plane protocols, such as the Rapid Spanning Tree Protocol + (RSTP), the Multiple Spanning Tree Protocol (MSTP), and Shortest Path + Bridging (SPB), could be deployed as the core control plane for loop + avoidance and load balancing for PBB. The applicability of these + control protocols is out of scope for this document. + + The Virtual Private LAN Service (VPLS) provides a solution for + extending Ethernet LAN services, using MPLS tunneling capabilities, + through a routed MPLS backbone without requiring the use of a native + Ethernet control-plane protocol across the backbone. VPLS use of + the structured FEC 129 [RFC4762] also allows for inter-domain, + inter-provider connectivity and enables auto-discovery options across + the network, improving the service delivery options. + + A hierarchical solution for VPLS was introduced in [RFC4761] and + [RFC4762] to provide improved scalability and efficient handling of + packet replication. These improvements are achieved by reducing the + number of Provider Edge (PE) devices connected in a full-mesh + topology through the creation of two-tier PEs. A User-facing PE + (U-PE) aggregates all the Customer Edge (CE) devices in a lower-tier + access network and then connects to the Network-facing PE (N-PE) + device(s) deployed around the core domain. In VPLS, Media Access + Control (MAC) address learning and forwarding are done based on + Customer MAC addresses (C-MACs); this poses scalability issues on the + N-PE devices as the number of VPLS instances (and thus C-MACs) + increases. Furthermore, since a set of pseudowires (PWs) is + maintained on a "per customer service instance" basis, the number of + PWs required at N-PE devices is proportional to the number of + customer service instances multiplied by the number of N-PE devices + in the full-mesh set. This can result in scalability issues (in + terms of PW manageability and troubleshooting) as the number of + customer service instances grows. + + This document describes how PBB can be integrated with VPLS to allow + for useful PBB capabilities while continuing to avoid the use of MSTP + in the backbone. The combined solution referred to in this document + + + + + +Balus, et al. Informational [Page 3] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + as PBB-VPLS results in better scalability in terms of the number of + service instances, PWs, and C-MACs that need to be handled in the + VPLS PEs. + + Section 2 provides a quick terminology reference. Section 3 covers + the reference model for PBB VPLS PEs. Section 4 describes the packet + walkthrough. Sections 5 through 7 discuss the PBB-VPLS usage of + existing VPLS mechanisms -- the control plane; efficient packet + replication; and Operations, Administration, and Maintenance (OAM). + +2. General Terminology + + Some general terminology is defined here; most of the terminology + used is from [PBB], [PB], [RFC4664], and [RFC4026]. Terminology + specific to this memo is introduced as needed in later sections. + + B-BEB: A backbone edge bridge positioned at the edge of a provider + backbone bridged network. It contains a B-component that supports + bridging in the provider backbone based on Backbone MAC (B-MAC) + and B-tag information. + + B-component: A bridging component contained in backbone edge and core + bridges that bridges in the backbone space (B-MAC addresses, + B-VLAN). + + B-MAC: The backbone source or destination MAC address fields defined + in the PBB provider MAC encapsulation header. + + B-tag: Field defined in the PBB provider MAC encapsulation header + that conveys the backbone VLAN identifier information. The format + of the B-tag field is the same as that of an 802.1ad S-tag field. + + B-Tagged Service Interface: The interface between a BEB and a + Backbone Core Bridge (BCB) in a provider backbone bridged network. + Frames passed through this interface contain a B-tag field. + + B-VID: The specific VLAN identifier carried inside a B-tag. + + B-VLAN: The backbone VLAN associated with a B-component. + + B-PW: The pseudowire used to interconnect B-component instances. + + BEB: A backbone edge bridge positioned at the edge of a provider + backbone bridged network. It can contain an I-component, a + B-component, or both I-components and B-components. + + C-VID: The VLAN identifier in a customer VLAN. + + + + +Balus, et al. Informational [Page 4] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + DA: Destination Address. + + I-BEB: A backbone edge bridge positioned at the edge of a provider + backbone bridged network. It contains an I-component for bridging + in the customer space (customer MAC addresses, service VLAN IDs). + + I-component: A bridging component contained in a backbone edge bridge + that bridges in the customer space (customer MAC addresses, + service VLAN identifier information (S-VLAN)). + + I-SID: The 24-bit service instance field carried inside the I-tag. + I-SID defines the service instance that the frame should be + "mapped to". + + I-tag: A field defined in the PBB provider MAC encapsulation header + that conveys the service instance information (I-SID) associated + with the frame. + + I-Tagged Service Interface: The interface defined between the + I-components and B-components inside an IB-BEB or between two + B-BEBs. Frames passed through this interface contain an I-tag + field. + + IB-BEB: A backbone edge bridge positioned at the edge of a provider + backbone bridged network. It contains an I-component for bridging + in the customer space (customer MAC addresses, service VLAN IDs) + and a B-component for bridging the provider's backbone space + (B-MAC, B-tag). + + PBs: Provider Bridges (IEEE amendment (802.1ad) to 802.1Q for "QinQ" + encapsulation and bridging of Ethernet frames [PB]). + + PBBs: Provider Backbone Bridges (IEEE amendment (802.1ah) to 802.1Q + for "MAC tunneling" encapsulation and bridging of frames across a + provider network [PBB]). + + PBBN: Provider Backbone Bridged Network. + + PBN: Provider Bridged Network. A network that employs 802.1ad (QinQ) + technology. + + PSN: Packet-Switched Network. + + S-tag: A field defined in the 802.1ad QinQ encapsulation header that + conveys the service VLAN identifier information (S-VLAN). + + + + + + +Balus, et al. Informational [Page 5] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + S-Tagged Service Interface: The interface defined between the + customer (CE) and the I-BEB or IB-BEB components. Frames passed + through this interface contain an S-tag field. + + S-VLAN: The specific service VLAN identifier carried inside an S-tag. + + SA: Source Address. + + S-VID: The VLAN identifier in a service VLAN. + + Tag: In Ethernet, a header immediately following the Source MAC + Address field of the frame. + +3. PE Reference Model + + The following gives a short primer on the Provider Backbone Bridge + (PBB) before describing the PE reference model for PBB-VPLS. The + internal components of a PBB bridge module are depicted in Figure 1. + + +-------------------------------+ + | PBB Bridge Model | + | | + +---+ | +------+ +-----------+ | + |CE |---------|I-Comp|------| | | + +---+ | | | | |-------- + | +------+ | | | + | o | B-Comp | | + | o | |-------- + | o | | | + +---+ | +------+ | | | + |CE |---------|I-Comp|------| |-------- + +---+ ^ | | | ^ | | | ^ + | | +------+ | +-----------+ | | + | +------------|------------------+ | + | | | + | | | + S-tagged I-tagged B-tagged + Service Interface Service I/F Service I/F + (I/F) + + Figure 1: PBB Bridge Model + + + + + + + + + + +Balus, et al. Informational [Page 6] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + Provider Backbone Bridges (PBBs) [PBB] offer a scalable solution for + service providers to build large bridged networks. The focus of PBB + is primarily on improving two main areas with provider Ethernet + bridged networks: + + - MAC-address table scalability + - Service instance scalability + + To obviate the above two limitations, PBB introduces a hierarchical + network architecture with associated new frame formats that extend + the work completed by Provider Bridges (PBs). In the PBBN + architecture, customer networks (using PBs) are aggregated into + PBBNs, which utilize the IEEE PBB frame format. The frame format + employs a MAC tunneling encapsulation scheme for tunneling customer + Ethernet frames within provider Ethernet frames across the PBBN. A + VLAN identifier (B-VID) is used to segregate the backbone into + broadcast domains, and a new 24-bit service identifier (I-SID) is + defined and used to associate a given customer MAC frame with a + provider service instance (also called the service delimiter). It + should be noted that in [PBB] there is a clear segregation between + provider service instances (represented by I-SIDs) and provider VLANs + (represented by B-VIDs), which was not the case for PBs. + + As shown in Figure 1, a PBB bridge may consist of a single + B-component and one or more I-components. In simple terms, the + B-component provides bridging in the provider space (B-MAC, B-VLAN), + and the I-component provides bridging in the customer space (C-MAC, + S-VLAN). The customer frame is first encapsulated with the provider + backbone header (B-MAC, B-tag, I-tag); then, the bridging is + performed in the provider backbone space (B-MAC, B-VLAN) through the + network till the frame arrives at the destination BEB, where it gets + decapsulated and passed to the CE. If a PBB bridge consists of both + I-components and B-components, then it is called an IB-BEB, and if it + only consists of either B-components or I-components, then it is + called a B-BEB or an I-BEB, respectively. The interface between an + I-BEB or IB-BEB and a CE is called an S-tagged service interface, and + the interface between an I-BEB and a B-BEB (or between two B-BEBs) is + called an I-tagged service interface. The interface between a B-BEB + or IB-BEB and a Backbone Core Bridge (BCB) is called a B-tagged + service interface. + + + + + + + + + + + +Balus, et al. Informational [Page 7] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + To accommodate the PBB components, the VPLS model defined in + [RFC4664] is extended as depicted in Figure 2. + + +----------------------------------------+ + | PBB-VPLS-Capable PE Model | + | +---------------+ +------+ | + | | | |VPLS-1|------------ + | | |==========|Fwdr |------------ PWs + +--+ | | Bridge ------------ |------------ + |CE|-|-- | | +------+ | + +--+ | | Module | o | + | | | o | + | | (PBB | o | + | | bridge) | o | + | | | o | + +--+ | | | +------+ | + |CE|-|-- | ------------VPLS-n|------------- + +--+ | | |==========| Fwdr |------------- PWs + | | | ^ | |------------- + | +---------------+ | +------+ | + | | | + +-------------------------|--------------+ + LAN Emulation Interface + + Figure 2: PBB-VPLS-Capable PE Model + + The PBB module as defined in the [PBB] specification is expanded to + interact with VPLS Forwarders. The VPLS Forwarders are used in + [RFC4762] to build a PW mesh or a set of spoke PWs (Hierarchical VPLS + (H-VPLS) topologies). The VPLS instances are represented externally + in the MPLS context by a Layer 2 Forwarding Equivalence Class (L2FEC) + that binds related VPLS instances together. VPLS Signaling + advertises the mapping between the L2FEC and the PW labels and + implicitly associates the VPLS bridging instance to the VPLS + Forwarders [RFC4762]. + + In the PBB-VPLS case, the backbone service instance in the + B-component space (B-VID) is represented in the backbone MPLS network + using a VPLS instance. In the same way as for the regular VPLS case, + existing signaling procedures are used to generate through PW labels + the linkage between VPLS Forwarders and the backbone service + instance. + + Similarly, with the regular H-VPLS, another L2FEC may be used to + identify the customer service instance in the I-component space. + This will be useful, for example, to address the PBB-VPLS N-PE case + where H-VPLS spokes are connecting the PBB-VPLS N-PE to a VPLS U-PE. + + + + +Balus, et al. Informational [Page 8] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + It is important to note that the PBB-VPLS solution inherits the PBB + service aggregation capability where multiple customer service + instances may be mapped to a backbone service instance. In the + PBB-VPLS case, this means multiple customer VPNs can be transported + using a single VPLS instance corresponding to the backbone service + instance, thus substantially reducing resource consumption in the + VPLS core. + +4. Packet Walkthrough + + Since the PBB bridge module inherently performs forwarding, the PE + reference model of Figure 2 can be expanded as shown in Figure 3. + + Furthermore, the B-component is connected via several virtual + interfaces to the PW Forwarder module. The function of the PW + Forwarder is defined in [RFC3985]. In this context, the PW Forwarder + simply performs the mapping of the PWs to the virtual interface on + the B-component, without the need for any MAC lookup. + + This simplified model takes full advantage of the PBB module -- where + all the [PBB] procedures, including C-MAC/B-MAC forwarding and PBB + encapsulation/decapsulation, take place -- and thus avoids the need + to specify any of these functions in this document. + + Because of text-based graphics, Figure 3 only shows PWs on the + core-facing side; however, in the case of MPLS access with spoke PWs, + the PE reference model is simply extended to include the same PW + Forwarder function on the access-facing side. To avoid cluttering + the figure, but without losing any generality, the access-side PW + Forwarder (Fwdr) is not depicted. + + + + + + + + + + + + + + + + + + + + + +Balus, et al. Informational [Page 9] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + +------------------------------------------------+ + | PBB-VPLS-Capable PE Model | + | +---------------+ +------+ | + | | | | | | + | +------+ | ======== --------- + +--+ | | | | | | --------- PWs + |CE|-|-- | I- ==== ======== PW --------- + +--+ | | Comp | | | | Fwdr | + | +------+ | | | --------- PWs + | | B-Comp ======== --------- + | | | ^ | | | + | +------+ | | | +------+ | + +--+ | | I- | | OOOOOOOOOOOOOOOOOOOOOOOO B-tag + |CE|-|-- | Comp ==== | | | I/Fs + +--+ | | |^ | OOOOOOOOOOOOOOOOOOOOOOOO + | +------+| | | | | + | | +---------------+ | | + | | | | + +-----------|--------------------|---------------+ + | | + Internal I-tag I/Fs Virtual Interfaces (I/Fs) + + +---------------+ +--------------+ + | C-MAC DA,SA | | PSN Header | + |---------------| |--------------| + | S-VID, C-VID | | PW Label | + |---------------| |--------------| + | Payload | | B-MAC DA,SA | + +---------------+ |--------------| + | PBB I-tag | + |--------------| + | C-MAC DA,SA | + |--------------| + | S-VID, C-VID | + |--------------| + | Payload | + +--------------+ + + Figure 3: Packet Walkthrough for PBB VPLS PE + + In order to better understand the data-plane walkthrough, let us + consider the example of a PBB packet arriving over a Backbone + pseudowire (B-PW). The PSN header is used to carry the PBB + encapsulated frame over the backbone while the PW label will point to + the related Backbone Service Instance (B-SI), in the same way as for + regular VPLS. The PW label has in this case an equivalent role with + the backbone VLAN identifier on the PBB B-tagged interface. + + + + +Balus, et al. Informational [Page 10] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + An example of the PBB packet for the regular Ethernet PW is depicted + on the right-hand side of Figure 3. The MPLS packet from the MPLS + core network is received by the PBB-VPLS PE. The PW Forwarder + function of the PE uses the PW label to derive the virtual + interface-id on the B-component, and then, after removing the PSN and + PW encapsulation, it passes the packet to the B-component. From + there on, the processing and forwarding are performed according to + [PBB], where bridging based on the Backbone MAC (B-MAC) Destination + Address (DA) is performed. This scenario results in one of the + following outcomes: + + 1. The packet is forwarded to a physical interface on the + B-component. In this case, the PBB Ethernet frame is forwarded + as is. + + 2. The packet is forwarded to a virtual interface on the B-component. + This is not typically the case, because of a single split-horizon + group within a VPLS instance; however, if there is more than one + split-horizon group, then such forwarding takes place. In this + case, the PW Forwarder module adds the PSN and PW labels before + sending the packet out. + + 3. The packet is forwarded toward the access side via one of the + I-tagged service interfaces connected to the corresponding + I-components. In this case, the I-component removes the B-MAC + header according to [PBB] and bridges the packet using the + C-MAC DA. + + If the destination B-MAC is an unknown MAC address or a Group MAC + address (multicast or broadcast), then the B-component floods the + packet to one or more of the three destinations described above. + +5. Control Plane + + The control-plane procedures described in [RFC6074], [RFC4761], and + [RFC4762] can be reused in a PBB-VPLS to set up the PW infrastructure + in the service provider and/or customer bridging space. This allows + porting the existing control-plane procedures (e.g., BGP + Auto-Discovery (BGP-AD), PW setup, VPLS MAC flushing, PW OAM) for + each domain. + + + + + + + + + + + +Balus, et al. Informational [Page 11] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + +6. Efficient Packet Replication in PBB VPLS + + The PBB VPLS architecture takes advantage of the existing VPLS + features addressing packet replication efficiency. The H-VPLS + hierarchy may be used in both customer and backbone service instances + to reduce the redundant distribution of packets over the core. IGMP + and PIM snooping may be applied on a "per customer service instance" + basis to control the distribution of the multicast traffic to + non-member sites. + + [IEEE-802.1Q] specifies the use of the Multiple MAC Registration + Protocol (MMRP) for flood containment in the backbone instances. The + same solution can be ported in the PBB-VPLS solution. + + Further optimizations of the packet replication in PBB-VPLS are out + of the scope of this document. + +7. PBB VPLS OAM + + The existing VPLS, PW, and MPLS OAM procedures may be used in each + customer service instance or backbone service instance to verify the + status of the related connectivity components. + + PBB OAM procedures make use of the IEEE Ethernet Connectivity Fault + Management [CFM] and ITU-T Y.1731 [Y.1731] tools in both I-components + and B-components. + + Both sets of tools (PBB and VPLS) may be used for the combined + PBB-VPLS solution. + +8. Security Considerations + + No new security issues are introduced beyond those described in + [RFC4761] and [RFC4762]. + + + + + + + + + + + + + + + + + +Balus, et al. Informational [Page 12] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + +9. References + +9.1. Normative References + + [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, January 2007. + + [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private + LAN Service (VPLS) Using Label Distribution Protocol (LDP) + Signaling", RFC 4762, January 2007. + + [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, + "Provisioning, Auto-Discovery, and Signaling in Layer 2 + Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. + +9.2. Informative References + + [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for + Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, + September 2006. + + [PBB] Clauses 25 and 26 of "IEEE Standard for Local and + metropolitan area networks - Media Access Control (MAC) + Bridges and Virtual Bridged Local Area Networks", IEEE + Std 802.1Q-REV, 2013. + + [PB] Clauses 15 and 16 of "IEEE Standard for Local and + metropolitan area networks - Media Access Control (MAC) + Bridges and Virtual Bridged Local Area Networks", IEEE + Std 802.1Q-REV, 2013. + + [CFM] CFM clauses of "IEEE Standard for Local and metropolitan + area networks - Media Access Control (MAC) Bridges and + Virtual Bridged Local Area Networks", IEEE Std 802.1Q-REV, + 2013. + + [IEEE-802.1Q] + "IEEE Standard for Local and metropolitan area networks - + Media Access Control (MAC) Bridges and Virtual Bridged + Local Area Networks", IEEE Std 802.1Q-REV, 2013. + + + + + + + +Balus, et al. Informational [Page 13] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + [Y.1731] ITU-T Recommendation Y.1731, "OAM functions and mechanisms + for Ethernet based networks", July 2011. + + [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual + Private Network (VPN) Terminology", RFC 4026, March 2005. + +10. Contributors + + The following people made significant contributions to this document: + + Matthew Bocci + Alcatel-Lucent + Voyager Place + Shoppenhangers Road + Maidenhead + Berks, UK + + EMail: matthew.bocci@alcatel-lucent.com + + + Raymond Zhang + Alcatel-Lucent + + EMail: raymond.zhang@alcatel.com + + + Geraldine Calvignac + Orange + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + France + + EMail: geraldine.calvignac@orange.com + + + John Hoffmans + KPN + Regulusweg 1 + 2516 AC Den Haag + The Netherlands + + EMail: john.hoffmans@kpn.com + + + + + + + + + +Balus, et al. Informational [Page 14] + +RFC 7041 Extensions to VPLS PE Model for PBB November 2013 + + + Olen Stokes + Extreme Networks + PO Box 14129 + RTP, NC 27709 + USA + + EMail: ostokes@extremenetworks.com + +11. Acknowledgments + + The authors would like to thank Wim Henderickx, Mustapha Aissaoui, + Dimitri Papadimitriou, Pranjal Dutta, Jorge Rabadan, Maarten Vissers, + and Don Fedyk for their insightful comments and probing questions. + +Authors' Addresses + + Florin Balus (editor) + Alcatel-Lucent + 701 E. Middlefield Road + Mountain View, CA 94043 + USA + + EMail: florin.balus@alcatel-lucent.com + + + Ali Sajassi (editor) + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: sajassi@cisco.com + + + Nabil Bitar (editor) + Verizon + 60 Sylvan Road + Waltham, MA 02145 + USA + + EMail: nabil.n.bitar@verizon.com + + + + + + + + + + +Balus, et al. Informational [Page 15] + |