idnits 2.17.1 draft-augustyn-vpls-requirements-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 document seems to lack a Security Considerations section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 234 has weird spacing: '...ranging from ...' == 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 'SHOULD not' in this paragraph: A provider's implementation of a VPLS system SHOULD not constrain the customer's ability to configure VLAN topologies, tags, 802.1 p-bits, or any other Layer 2 parameters. == 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 'SHOULD not' in this paragraph: The service SHOULD not duplicate packets. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 28 looks like a reference -- Missing reference section? '2' on line 54 looks like a reference -- Missing reference section? '3' on line 61 looks like a reference -- Missing reference section? '6' on line 492 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPVPN Working Group Waldemar Augustyn 3 Internet Draft 4 Document: draft-augustyn-vpls-requirements-02.txt Giles Heron 5 Category: Informational PacketExchange Ltd 7 February 2002 Vach Kompella 8 Expires: August 2002 TiMetra Networks 10 Marc Lasserre 11 Riverstone Networks 13 Pascal Menezes 14 Terabeam 16 Hamid Ould-Brahim 17 Nortel Networks 19 Tissa Senevirathne 20 Force10 Networks 22 Requirements for Virtual Private LAN Services (VPLS) 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026 [1]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 For potential updates to the above required-text see: 46 http://www.ietf.org/ietf/1id-guidelines.txt 47 draft-augustyn-vpls-requirements-02.txt February 2002 49 1 Abstract 51 This draft describes service requirements related to emulating a 52 virtual private LAN segment over an IP or MPLS network 53 infrastructure. The service is called VPLS. It is a class of 54 Provider Provisioned Virtual Private Network [2]. 56 2 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119 [3]. 62 3 Definitions 64 3.1 VPLS 66 A Virtual Private LAN Service or, when referring to a virtual LAN 67 segment offered by that service, a Virtual Private LAN Segment. 69 A VPLS service allows the connection of multiple sites in a single 70 bridged domain over a provider managed IP or MPLS network. All 71 customer sites in the VPLS appear to be on the same LAN regardless 72 of their location. 74 3.2 VPLS System 76 A collection of communication equipment, related protocols, and 77 configuration elements that implements VPLS Services. 79 3.3 VPLS Domain 81 A Layer 2 VPN that is composed of a community of interest of L2 MAC 82 addresses and VLANs. Each VPLS Domain MAY have multiple VLANs in it. 84 3.4 VLAN 86 A customer VLAN identification using some scheme such as IEEE 802.1Q 87 tags, port configuration or any other means. A VPLS service can be 88 extended to recognize customer VLANs as specified in 6.1 . 90 3.5 VLAN Flooding Scope (VLAN Broadcast Domain) 92 The scope of flooding for a given VLAN. 94 In a VPLS service, a VLAN flooding scope MUST be identical to the 95 flooding scope of the VPLS it is part of. If a VPLS service is 96 extended to recognize customer VLANs, the VLAN flooding scope SHOULD 97 be limited to the broadcast domain of each recognized VLAN. 99 draft-augustyn-vpls-requirements-02.txt February 2002 101 3.6 VFI 103 Virtual Forwarding Instance. 105 A virtual layer 2 forwarding entity that is closed to a VPLS Domain 106 membership. VFI forwarding is based on MAC addresses, VLAN tags, 107 policies, topologies, filters, QoS parameters, and other relevant 108 information on a per VPLS basis. 110 4 Introduction 112 Traditionally, the typical connectivity between a service provider 113 and a customer is a WAN link with some type of a point-to-point 114 protocol. This arrangement was borne out of the necessity to 115 traverse TDM circuits originally designed for voice traffic. The 116 introduction of WAN links to network architectures significantly 117 increased the complexity of network topologies and required highly 118 skilled personnel to manage and maintain the network. 120 One solution to the above has been for service providers to deploy 121 emulated LAN services known in this context as "Transparent LAN" 122 services, or TLS. These have typically been offered using a mesh of 123 ATM PVCs between locations. While this technique reduced complexity 124 for the customer, it proved inadequate in the area of scaling and 125 ease of management on the provider side. 127 The aim of this effort is to develop a Virtual Private LAN Service, 128 VPLS, that scales well, is simple to manage, and is based on the 129 existing MPLS or IP backbone. 131 VPLS emulates a flat LAN segment with learning and switching 132 capabilities. In a given LAN segment, there is a reasonably small 133 set of MAC devices with a limited number of MAC addresses to learn 134 and manage. There is no need for additional routing protocol support 135 between the CE and the PE devices. In the VPLS model, the service 136 is transparent to the customer's choice of routing protocol. 137 Moreover, VPLS services also benefit from being transparent to 138 higher layer protocols, so the same technology can transport, for 139 example, IPv4, IPv6, MPLS as well as legacy protocols such as IPX 140 and OSI. 142 The VPLS model, while offering significant benefits for both 143 customers and service providers, retains all the quintessential 144 characteristics of L2 networks including their well known 145 limitations such as the maximum practical number of hosts on a 146 single segment and the inability to assign different metrics for 147 connectivity between different hosts on the same segment. A likely 148 application of this model is to connect a few sites with only a 149 single customer router at each site, or a small number of customer 150 hosts, at each site, connected via the VPLS. 152 draft-augustyn-vpls-requirements-02.txt February 2002 154 The scope of this document will be limited to supporting Ethernet as 155 the access framing technology for VPLS implementation. 157 5 VPLS Reference Model 159 The following diagram shows a VPLS reference model where PE devices 160 that are VPLS-capable provide a logical interconnect such that CE 161 devices belonging to a specific VPLS appear to be connected by a 162 single logical Ethernet bridge. A VPLS can contain a single VLAN or 163 multiple, tagged VLANs. 165 +-----+ +-----+ 166 + CE1 +--+ +---| CE2 | 167 +-----+ | ........................ | +-----+ 168 VPLS A | +----+ +----+ | VPLS A 169 +--| PE |--- Service ---| PE |--+ 170 +----+ Provider +----+ 171 / . Backbone . \ - /\-_ 172 +-----+ / . | . \ / \ / \ +-----+ 173 + CE +--+ . | . +--\ Access \----| CE | 174 +-----+ . +----+ . | Network | +-----+ 175 VPLS B .........| PE |......... \ / VPLS B 176 +----+ ^ ------- 177 | | 178 | | 179 +-----+ | 180 | CE3 | +-- Logical bridge 181 +-----+ 182 VPLS A 184 Separate L2 broadcast domains are maintained on a per VPLS basis by 185 PE devices. Such domains are then mapped onto tunnels in the service 186 provider network. These tunnels can either be specific to a VPLS 187 (e.g. as with IP) or shared among several VPLSs (e.g. as with MPLS 188 tunnel LSPs). In the above diagram, the top PE routers maintain 189 separate forwarding instances for VPLS A and VPLS B. 191 The CE-to-PE links can either be direct physical links, e.g. 192 100BaseTX, or logical links, e.g. ATM PVC, T1/E1 TDM, or RFC1490- 193 encapsulated link, over which bridged Ethernet traffic is carried. 195 The PE-to-PE links carry tunneled Ethernet frames using different 196 tunneling technologies (e.g., GRE, IPSec, MPLS.). 198 Each PE device learns remote MAC addresses, and is responsible for 199 proper forwarding of the customer traffic to the appropriate end 200 draft-augustyn-vpls-requirements-02.txt February 2002 202 nodes. It is responsible for guaranteeing each VPLS topology is loop 203 free. 205 6 VPLS General Requirements 207 6.1 Layer 2 Domain representation and VLAN allocation 209 A VPLS system MUST distinguish different customer domains. Each of 210 these customer domains MUST appear as a L2 broadcast domain network 211 behaving like a LAN (Local Area Network). These domains are referred 212 to as VPLS domains. 214 A VPLS Domain MAY span multiple service providers. Each VPLS domain 215 MUST carry a unique identification within a VPLS system. It is 216 RECOMMENDED that VPLS identification be globally unique. 218 Each VPLS Domain MUST be capable of learning and forwarding based on 219 MAC addresses thus emulating an Ethernet virtual switch to the 220 customer CE devices attached to PEs. 222 A VPLS system MAY recognize customer VLAN identification. In that 223 case, a VLAN MUST be recognized in the context of the VPLS it is 224 part of. If customer VLANs are recognized, separate VLAN broadcast 225 domains SHOULD be maintained. 227 A provider's implementation of a VPLS system SHOULD not constrain 228 the customer's ability to configure VLAN topologies, tags, 802.1 p- 229 bits, or any other Layer 2 parameters. 231 6.2 VPLS Topology 233 The VPLS system MAY be realized using one or more network tunnel 234 topologies to interconnect PEs, ranging from simple point-to-point 235 to distributed hierarchical arrangements. The typical topologies 236 include: 238 o point-to-point 239 o point-to-multipoint, a.k.a. hub and spoke 240 o any-to-any, a.k.a. full mesh 241 o mixed, a.k.a. partial mesh 242 o hierarchical 244 Regardless of the topology employed, the service to the customers 245 MUST retain the typical LAN any-to-any connectivity. This 246 requirement does not imply that all traffic characteristics (such as 247 bandwidth, QoS, delay, etc.) be necessarily the same between any two 248 end points. 250 draft-augustyn-vpls-requirements-02.txt February 2002 252 6.3 Redundancy and Failure Recovery 254 The VPLS infrastructure SHOULD provide redundant paths to assure 255 high availability. The reaction to failures SHOULD result in an 256 attempt to restore the service using alternative paths. 258 The intention is to keep the restoration time small. It is 259 RECOMMENDED that the restoration time be less than the time it 260 takes the CE devices to detect a failure in the VPLS. 262 In cases where the provider knows a priori about impending changes 263 in network topology, the network SHOULD have the capability to 264 reconfigure without a loss, duplication, or re-ordering of customer 265 packets. This situation typically arises with planned network 266 upgrades, or scheduled maintenance activities. 268 6.4 Policy Constraints 270 A VPLS system MAY employ policy constraints governing various 271 interconnection attributes for VPLS domains. Typical attributes 272 include: 274 o Selection of available network infrastructure 275 o QoS services needed 276 o Protection services needed 277 o Availability of higher level service access points (see 9.11 ) 279 Policy attributes SHOULD be advertised via the VPLS system's control 280 plane. 282 6.5 PE nodes 284 The PE nodes are the devices in the VPLS system that store 285 information related to customer VPLS domains and employ methods to 286 forward customer traffic based on that information. In this 287 document, the PE nodes are meant in logical sense. In the actual 288 implementations, the PE nodes may be comprised of several physical 289 devices. Conversely, a single physical device may contain more than 290 one PE node. 292 All forwarding decisions related to customer VPLS traffic MUST be 293 made by PE nodes. This requirement prohibits any other network 294 components from altering decisions made by PE nodes. 296 6.6 PE-PE Interconnection and Tunneling 298 A VPLS system MUST provide for connectivity between each pair of PE 299 nodes. The connectivity is referred to as transport tunneling or 300 simply tunneling. 302 There are several choices for implementing transport tunnels. Some 303 popular choices include MPLS, IP in IP tunnels, variations of 304 draft-augustyn-vpls-requirements-02.txt February 2002 306 802.1Q, etc. Regardless of the choice, the existence of the tunnels 307 and their operations MUST be transparent to the customers. 309 6.7 PE-CE Interconnection and Profiles 311 A VPLS system MUST provide for connectivity between PE nodes and CE 312 nodes. That connectivity is referred to as CE access connection, 313 access connection, or simply access. Access connections MAY span 314 networks of other providers or public networks. 316 There are several choices for implementing access. Some popular 317 choices include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual 318 circuits etc. Regardless of the choice, the access connection MUST 319 use Ethernet frames as the Service Protocol Data Unit (SPDU). 321 A CE access connection MUST be bi-directional in nature. 323 PE devices MAY support multiple CE access connections on a single 324 physical interface. In such cases, PE devices MUST NOT rely on 325 customer controlled parameters, such as VLAN tags etc., for 326 distinguishing between different access connections. 328 A CE access connection, whether direct or virtual, MUST maintain all 329 committed characteristics of the customer traffic, such as QoS, 330 priorities etc. 332 The characteristics of a CE access connection are only applicable to 333 that connection. 335 7 Control Plane Requirements 337 7.1 Provider Edge Signaling 339 The control protocols SHOULD provide methods for signaling between 340 PEs. The signaling SHOULD inform of membership, tunneling 341 information, and other relevant parameters. 343 The infrastructure MAY employ manual configuration methods to 344 provide this type of information. 346 The infrastructure SHOULD use policies to scope the membership and 347 reachability advertisements for a particular VPLS. 349 7.2 VPLS Membership Discovery 351 The control protocols SHOULD provide methods to discover the PEs 352 which connect CEs that form a VPLS. 354 draft-augustyn-vpls-requirements-02.txt February 2002 356 7.3 Support for Layer 2 control protocols 358 A VPLS system MUST ensure that loops are prevented. This can be 359 accomplished through a use of control protocols such as Spanning 360 Tree or similar, or through other means such as full mesh topologies 361 and appropriate forwarding rules. 363 The VPLS system's control protocols SHOULD allow transparent 364 operation of Layer 2 control protocols employed by customers. 366 A VPLS system's control protocols MAY use indications from customer 367 STP to improve the operation of a VPLS. 369 7.4 Scaling Requirements 371 Control plane traffic will increase correspondingly, as a VPLS 372 scales in membership. The rate of growth of control plane traffic 373 SHOULD be linear. 375 Control plane traffic will increase correspondingly, as the number 376 of supported VPLS segments increases. The rate of growth of control 377 plane traffic SHOULD be linear. 379 The use of control plane resources will increase correspondingly, as 380 the number of hosts connected to a VPLS increases. The rate of 381 growth of the demand for control process resources SHOULD be linear. 382 The control plane MAY offer means for enforcing a limit on the 383 number of customer hosts attached to a VPLS. 385 8 Data Plane Requirements 387 8.1 Transparency 389 VPLS service is intended to be transparent to Layer 2 customer 390 networks. It MUST NOT require any special packet processing by the 391 end users before sending packets to the provider's network. 393 8.2 Broadcast Domain 395 The Broadcast Domain is defined as the flooding scope of a Layer 2 396 network. In a VPLS system, a separate Broadcast Domain MUST be 397 maintained for each VPLS. 399 In addition to VPLS Broadcast Domains, a VPLS system MAY recognize 400 customer VLAN Broadcast Domains. In that case, the system SHOULD 401 maintain a separate VLAN Broadcast Domain for each customer VLAN. A 402 VLAN Broadcast Domain MUST be a subset of the owning VPLS Broadcast 403 Domain. 405 draft-augustyn-vpls-requirements-02.txt February 2002 407 8.3 Layer 2 Virtual Forwarding Instance 409 VPLS Provider Edge devices MUST maintain a separate Virtual 410 Forwarding Instance (VFI) per VPLS. Each VFI MUST have capabilities 411 to forward traffic based on customer's traffic parameters such as 412 MAC addresses, VLAN tags (if supported), etc. as well as local 413 policies. 415 Each VFI MUST have flooding capabilities for its Broadcast Domain to 416 facilitate proper forwarding of Broadcast, Multicast and Unknown 417 Unicast customer traffic. 419 VPLS Provider Edge devices MUST have capabilities to classify 420 incoming customer traffic into the appropriate VFI. 422 8.4 MAC address learning 424 A VPLS service SHOULD derive all topology and forwarding information 425 from packets originating at customer sites. Typically, MAC 426 addresses learning mechanisms are used for this purpose. 428 In a VPLS system, MAC address learning MUST take place on a per 429 Virtual Forwarding Instance (VFI) basis, i.e. in the context of a 430 VPLS and, if supported, in the context of VLANs therein. 432 8.5 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding 434 VPLS MUST be aware of the existence and the designated roles of 435 special MAC addresses such as Multicast and Broadcast addresses. 436 VPLS MUST forward these packets according to their intended 437 functional meaning and scope. 439 Broadcast packets MUST be flooded to all destinations. 441 Multicast packets MUST be flooded to all destinations. However, a 442 VPLS system MAY employ multicast snooping techniques, in which case 443 multicast packets SHOULD be forwarded only to their intended 444 destinations. 446 Unicast packets MUST be forwarded to their intended destinations. 448 Unknown Unicast packets MUST be flooded to all destinations in the 449 flooding scope of the VPLS (or VLAN). If the VPLS service relies on 450 MAC learning for its operations, it MUST assure proper forwarding of 451 packets with MAC addresses that have not been learned. Once 452 destination MAC addresses are learned, unicast packets SHOULD be 453 forwarded only to their intended destinations. 455 A provider MAY employ a method to limit the scope of flooding of 456 Unknown Unicast packets in cases where a customer desires to 457 conserve its bandwidth or wants to implement certain security 458 policies. 460 draft-augustyn-vpls-requirements-02.txt February 2002 462 8.6 Multilink Access 464 The VPLS service SHOULD support multilink access for CE devices. 465 The VPLS service MAY support multihome access for CE devices. 467 8.7 Minimum MTU 469 The service MUST support customer frames with payload 1500 bytes 470 long. The service MAY offer support for longer frames. 472 The service MUST NOT fragment packets. Packets exceeding committed 473 MTU size MUST be discarded. 475 The committed minimum MTU size MUST be the same for a given VPLS. If 476 VLANs are supported, all VLANs within a given VPLS MUST inherit the 477 same MTU size. Different VPLS segments MAY have different committed 478 MTU sizes. 480 8.8 QoS and packet re-ordering 482 A VPLS system SHOULD have capabilities to enforce QoS parameters. 484 The queuing and forwarding policies SHOULD preserve packet order for 485 packets with the same QoS parameters. 487 The service SHOULD not duplicate packets. 489 8.9 Support for MAC Services 491 VPLS are REQUIRED to provide MAC service compliant with IEEE 802.1D 492 specification [6] Section 6. Compliance with this section 493 facilitates proper operation of 802.1 LAN and seamless integration 494 of VPLS with bridged Local Area Networks. 496 A MAC service in the context of VPLS is defined as the transfer of 497 user data between source and destination end stations via the 498 service access points using the information specified in the VFI. 500 1. A PE device that provides VPLS MUST NOT be directly accessed by 501 end stations except for explicit management purposes. 503 2. All MAC addresses MUST be unique within a given broadcast domain. 505 3. The topology and configuration of the VPLS MUST NOT restrict the 506 MAC addresses of end stations 507 draft-augustyn-vpls-requirements-02.txt February 2002 509 9 Management and Operations Requirements 511 9.1 The VPLS system MUST have capabilities to manage and monitor its 512 different components. 514 9.2 VPLS System Instantiation 516 It SHOULD be possible to create several disjoint instances of VPLS 517 systems within the same underlying network infrastructures. 519 9.3 Monitoring 521 The infrastructure SHOULD monitor all characteristics of the service 522 that are reflected in the customer SLA. This includes but is not 523 limited to bandwidth usage, packet counts, packet drops, service 524 outages, etc. 526 9.4 VPLS membership 528 The amount of configuration changes when adding or deleting customer 529 ports to, or from, a given VPLS SHOULD be minimal. The configuration 530 changes of a port to or from a given VPLS SHOULD involve only 531 configuration on the device that this port is connected to. 533 9.5 End-point VLAN tag translation 535 If VLANs are recognized, the infrastructure MAY support translation 536 of customers' VLAN tags. Such service simplifies connectivity of 537 sites that want to keep their tag assignments or sites that belong 538 to different administrative entities. In the latter case, the 539 connectivity is sometimes referred to as L2 extranet. 541 9.6 MAC Address Limiting 543 The VPLS infrastructure MUST be able to limit the number of MAC 544 addresses learned from the customers. 546 9.7 CE Provisioning 548 The VPLS MUST require only minimal or no configuration on the CE 549 devices, depending on the CE device that connects into the 550 infrastructure. 552 9.8 Customer traffic policing 554 The VPLS service SHOULD provide the ability to police and/or shape 555 customer traffic entering and leaving the VPLS system. 557 draft-augustyn-vpls-requirements-02.txt February 2002 559 9.9 Dynamic Service Signaling 561 A Provider MAY offer to Customers an in-band method for selecting 562 services from the list specified in the SLA. A Provider MAY use the 563 same mechanism for reporting statistical data related to the 564 service. 566 9.10 Class of Service Model 568 The VPLS service MAY define a graded selection of classes of 569 traffic. These include, but are not limited to 571 o range of priorities 572 o best effort vs. guaranteed effort 573 o range of minimum delay characteristics 575 9.11 L3, and higher, service access point. 577 The VPLS service SHOULD allow for a Provider based Service Access 578 Point for orderly injection of L3 or higher services to the 579 customers' VPLS segments. 581 As a value added service, a Provider MAY offer access to other 582 services such as, IP gateways, storage networks, content delivery 583 etc.. 585 9.12 Testing 587 The VPLS service SHOULD provide the ability to test and verify 588 operational and maintenance activities on a per VLAN basis. 590 10 Security Requirements 592 10.1 Traffic separation 594 VPLS system MUST provide traffic separation between different VPLS 595 domains as well as between customer VLANs within each VPLS domain if 596 VLANs are supported. 598 10.2 Provider network protection. 600 The VPLS system MUST be immune to malformed or maliciously 601 constructed customer traffic. This includes but is not limited to 602 duplicate or invalid MAC addresses, short/long packets, spoofed 603 management packets, spoofed VLAN tags, high volume traffic, etc. 605 Additionally, VPLS system MUST be immune to misconfigured or 606 maliciously set up customer network topologies. These include 607 customer side loops, backdoor links between sites, etc. 609 draft-augustyn-vpls-requirements-02.txt February 2002 611 The VPLS infrastructure devices MUST NOT be accessible from the 612 VPLS. 614 10.3 Value added security services 616 Value added security services such as encryption and/or 617 authentication of customer packets, certificate management, and 618 similar are OPTIONAL. 620 Security measures employed by the VPLS system SHOULD NOT restrict 621 implementation of customer based security add-ons. 623 11 References 625 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 626 9, RFC 2026, October 1996. 628 2. Carugi, et al., "Service requirements for Provider Provisioned 629 Virtual Private Networks ", Work in progress, December 2001. 631 3. Bradner, S., "Key words for use in RFCs to Indicate Requirement 632 Levels", BCP 14, RFC 2119, March 1997. 634 4. ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) 635 Bridges", 1998. 637 5. IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan 638 Area Networks: Virtual Bridged Local Area Networks", 1998. 640 6. IEEE Standard 802.1u-2001, "IEEE Standard for Local and 641 Metropolitan Area Networks: Virtual Bridged Local Area Networks - 642 Amendment 1: Technical and editorial corrections", 2001. 644 7. IEEE Standard 802.1v-2001, "IEEE Standard for Local and 645 Metropolitan Area Networks: Virtual Bridged Local Area Networks - 646 Amendment 2: VLAN Classification by Protocol and Port", 2001. 648 12 Acknowledgments 650 We would like to acknowledge extensive comments provided by Loa 651 Anderson, Joel Halpern, and Eric Rosen. The authors, also, wish to 652 extend appreciations to their respective employers and various other 653 people who volunteered to review this work and provided feedback. 655 draft-augustyn-vpls-requirements-02.txt February 2002 657 13 Authors' Addresses 659 Waldemar Augustyn 660 Email: waldemar@nxp.com 662 Giles Heron 663 PacketExchange Ltd. 664 The Truman Brewery 665 91 Brick Lane 666 London E1 6QL 667 United Kingdom 668 Email: giles@packetexchange.net 670 Vach Kompella 671 TiMetra Networks 672 274 Ferguson Dr. 673 Mountain View, CA 94043 674 Email: vkompella@timetra.com 676 Marc Lasserre 677 Riverstone Networks 678 5200 Great America Pkwy 679 Santa Clara, CA 95054 680 Phone: 408-878-6500 681 Email: marc@riverstonenet.com 683 Pascal Menezes 684 Terabeam 685 Phone: 206-686-2001 686 Email: pascal.menezes@terabeam.com 688 Hamid Ould-Brahim 689 Nortel Networks 690 P.O. Box 3511 Station C 691 Ottawa ON K1Y 4H7 692 Canada 693 Phone: 613-765-3418 694 Email: hbrahim@nortelnetworks.com 696 Tissa Senevirathne 697 Force10 Networks 698 1440 McCarthy Blvd 699 Milpitas, CA 95035 700 Phone: 408-965-5103 701 Email: tsenevir@hotmail.com 702 draft-augustyn-vpls-requirements-02.txt February 2002 704 Full Copyright Statement 706 "Copyright (C) The Internet Society (2001). All Rights Reserved. 707 This document and translations of it may be copied and furnished to 708 others, and derivative works that comment on or otherwise explain it 709 or assist in its implementation may be prepared, copied, published 710 and distributed, in whole or in part, without restriction of any 711 kind, provided that the above copyright notice and this paragraph 712 are included on all such copies and derivative works. However, this 713 document itself may not be modified in any way, such as by removing 714 the copyright notice or references to the Internet Society or other 715 Internet organizations, except as needed for the purpose of 716 developing Internet standards in which case the procedures for 717 copyrights defined in the Internet Standards process must be 718 followed, or as required to translate it into languages other than 719 English. 721 The limited permissions granted above are perpetual and will not be 722 revoked by the Internet Society or its successors or assigns. 724 This document and the information contained herein is provided on an 725 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 726 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 727 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 728 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 729 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."