idnits 2.17.1 draft-ietf-l2vpn-vpls-requirements-00.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. ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [3]), 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 221 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: 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 24 looks like a reference -- Missing reference section? '2' on line 50 looks like a reference -- Missing reference section? '3' on line 51 looks like a reference -- Missing reference section? '4' on line 58 looks like a reference -- Missing reference section? '5' on line 484 looks like a reference -- Missing reference section? '6' on line 487 looks like a reference -- Missing reference section? '7' on line 487 looks like a reference -- Missing reference section? '8' on line 487 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPVPN Working Group 3 Internet Draft 4 Document: draft-ietf-l2vpn-vpls-requirements-00.txt 5 Category: Informational 6 October 2002 Waldemar Augustyn 7 Expires: April 2003 (editor) 9 Giles Heron Pascal Menezes 10 PacketExchange Ltd Terabeam 12 Vach Kompella Hamid Ould-Brahim 13 TiMetra Networks Nortel Networks 15 Marc Lasserre Tissa Senevirathne 16 Riverstone Networks 18 Requirements for Virtual Private LAN Services (VPLS) 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026 [1]. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 For potential updates to the above required-text see: 42 http://www.ietf.org/ietf/1id-guidelines.txt 43 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 45 1 Abstract 47 This draft describes service requirements related to emulating a 48 virtual private LAN over an IP or MPLS network infrastructure. The 49 service is called VPLS. It is a class of Provider Provisioned 50 Virtual Private Network [2]. The general requirements can be found 51 in [3]. 53 2 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC-2119 [4]. 59 3 Definitions 61 3.1 VPLS 63 Virtual Private LAN Service, a case of L2VPN service distinguished 64 by the support of L2 broadcast. The term is also used, when clear 65 from the context, to refer to a particular instance of VPLS service. 67 A VPLS service allows the connection of multiple sites in a single 68 broadcast domain over a provider managed IP or MPLS network. All 69 customer sites in the VPLS appear to be on the same LAN regardless 70 of their location. 72 3.2 VPLS Domain 74 A Layer 2 VPN that is composed of a community of interest of L2 MAC 75 addresses and VLANs. Each VPLS Domain MAY have multiple VLANs in it. 77 3.3 VLAN 79 A customer VLAN identification using some scheme such as IEEE 802.1Q 80 tags, port configuration or any other means. A VPLS service can be 81 extended to recognize customer VLANs as specified in 6.1 . 83 3.4 VLAN Flooding Scope (VLAN Broadcast Domain) 85 The scope of flooding for a given VLAN. In a VPLS service, a VLAN 86 flooding scope is identical to the flooding scope of the VPLS it is 87 part of. If a VPLS service is extended to recognize customer VLANs, 88 the VLAN flooding scope is limited to the broadcast domain of each 89 recognized VLAN. 91 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 93 3.5 VSI 95 Virtual Switching Instance. A virtual layer 2 forwarding entity that 96 is closed to a VPLS domain membership. VSI forwarding can be based 97 on MAC addresses, VLAN tags, policies, topologies, filters, QoS 98 parameters, and other relevant information on a per VPLS basis. 100 4 Introduction 102 Traditionally, the typical connectivity between a service provider 103 and a customer is a WAN link with some type of a point-to-point 104 protocol. This arrangement was borne out of the necessity to 105 traverse TDM circuits originally designed for voice traffic. The 106 introduction of WAN links to network architectures significantly 107 increased the complexity of network topologies and required highly 108 skilled personnel to manage and maintain the network. 110 One solution to the above has been for service providers to deploy 111 emulated LAN services known in this context as "Transparent LAN" 112 services. These have typically been offered using a mesh of ATM PVCs 113 between locations. While this technique reduced complexity for the 114 customer, it proved inadequate in the area of scaling and ease of 115 management on the provider side. 117 The aim of this effort is to develop a Virtual Private LAN Service, 118 VPLS, that scales well, is simple to manage, and is based on the 119 existing MPLS or IP backbone. 121 VPLS emulates a flat LAN with learning and switching capabilities. 122 In a given LAN, there is a reasonably small set of MAC devices with 123 a limited number of MAC addresses to learn and manage. There is no 124 need for additional routing protocol support between the CE and the 125 PE devices. In the VPLS model, the service is transparent to the 126 customer's choice of routing protocol. Moreover, VPLS services also 127 benefit from being transparent to higher layer protocols, so the 128 same technology can transport, for example, IPv4, IPv6, MPLS as well 129 as legacy protocols such as IPX and OSI. 131 The VPLS model, while offering significant benefits for both 132 customers and service providers, retains all the quintessential 133 characteristics of L2 networks including their well known 134 limitations e.g. the maximum practical number of hosts on a single 135 LAN, etc. A likely application of this model is to connect a few 136 sites with only a single customer router at each site, or a small 137 number of customer hosts, at each site, connected via the VPLS. 139 The scope of this document will be limited to supporting Ethernet as 140 the access framing technology for VPLS implementation. 142 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 144 5 VPLS Reference Model 146 The following diagram shows a VPLS reference model where PE devices 147 that are VPLS-capable provide a logical interconnect such that CE 148 devices belonging to a specific VPLS appear to be connected by a 149 single logical Ethernet bridge. A VPLS can contain a single VLAN or 150 multiple, tagged VLANs. 152 +-----+ +-----+ 153 + CE1 +--+ +---| CE2 | 154 +-----+ | ........................ | +-----+ 155 VPLS A | +----+ +----+ | VPLS A 156 +--| PE |--- Service ---| PE |--+ 157 +----+ Provider +----+ 158 / . Backbone . \ - /\-_ 159 +-----+ / . | . \ / \ / \ +-----+ 160 + CE +--+ . | . +--\ Access \----| CE | 161 +-----+ . +----+ . | Network | +-----+ 162 VPLS B .........| PE |......... \ / VPLS B 163 +----+ ^ ------- 164 | | 165 | | 166 +-----+ | 167 | CE3 | +-- Logical bridge 168 +-----+ 169 VPLS A 171 Separate L2 broadcast domains are maintained on a per VPLS basis by 172 PE devices. Such domains are then mapped onto tunnels in the service 173 provider network. These tunnels can either be specific to a VPLS 174 (e.g. as with IP) or shared among several VPLSs (e.g. as with MPLS 175 tunnel LSPs). In the above diagram, the top PE routers maintain 176 separate forwarding instances for VPLS A and VPLS B. 178 The CE-to-PE links can either be direct physical links, e.g. 179 100BaseTX, or logical links, e.g. ATM PVC, T1/E1 TDM, or RFC1490- 180 encapsulated links, over which bridged Ethernet traffic is carried. 182 The PE-to-PE links carry tunneled Ethernet frames using different 183 tunneling technologies (e.g., GRE, IPSec, MPLS, L2TP, etc.). 185 Each PE device learns remote MAC addresses, and is responsible for 186 proper forwarding of the customer traffic to the appropriate end 187 nodes. It is responsible for guaranteeing each VPLS topology is loop 188 free. 190 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 192 6 VPLS General Requirements 194 6.1 Layer 2 Domain representation 196 A VPLS system MUST distinguish different customer domains. Each of 197 these customer domains MUST appear as a L2 broadcast domain network 198 behaving like a LAN (Local Area Network). These domains are referred 199 to as VPLS domains. 201 A VPLS MAY span multiple service providers. Each VPLS MUST carry a 202 unique identification within a VPLS system. It is RECOMMENDED that 203 VPLS identification be globally unique. 205 Each VPLS domain MUST be capable of learning and forwarding based on 206 MAC addresses thus emulating an Ethernet virtual switch to the 207 customer CE devices attached to PEs. 209 A VPLS system MAY recognize customer VLAN identification. In that 210 case, a VLAN MUST be recognized in the context of the VPLS it is 211 part of. If customer VLANs are recognized, separate VLAN broadcast 212 domains SHOULD be maintained. 214 A provider's implementation of a VPLS system SHOULD NOT constrain 215 the customer's ability to configure LAN topologies, tags, 802.1 p- 216 bits, or any other Layer 2 parameters. 218 6.2 VPLS Topology 220 The VPLS system MAY be realized using one or more network tunnel 221 topologies to interconnect PEs, ranging from simple point-to-point 222 to distributed hierarchical arrangements. The typical topologies 223 include: 225 o point-to-point 226 o point-to-multipoint, a.k.a. hub and spoke 227 o any-to-any, a.k.a. full mesh 228 o mixed, a.k.a. partial mesh 229 o hierarchical 231 Regardless of the topology employed, the service to the customers 232 MUST retain the typical LAN any-to-any connectivity. This 233 requirement does not imply that all traffic characteristics (such as 234 bandwidth, QoS, delay, etc.) be necessarily the same between any two 235 end points. 237 6.3 Redundancy and Failure Recovery 239 The VPLS infrastructure SHOULD provide redundant paths to assure 240 high availability. The reaction to failures SHOULD result in an 241 attempt to restore the service using alternative paths. 243 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 245 The intention is to keep the restoration time small. It is 246 RECOMMENDED that the restoration time be less than the time it takes 247 the CE devices, or customer L2 control protocols, to detect a 248 failure in the VPLS. 250 In cases where the provider knows a priori about impending changes 251 in network topology, the network SHOULD have the capability to 252 reconfigure without a loss, duplication, or re-ordering of customer 253 packets. This situation typically arises with planned network 254 upgrades or scheduled maintenance activities. 256 6.4 Policy Constraints 258 A VPLS system MAY employ policy constraints governing various 259 interconnection attributes for VPLS domains. Typical attributes 260 include: 262 o Selection of available network infrastructure 263 o QoS services needed 264 o Protection services needed 265 o Availability of higher level service access points (see 9.7 ) 267 Policy attributes SHOULD be advertised via the VPLS system's control 268 plane. 270 6.5 PE nodes 272 The PE nodes are the devices in the VPLS system that store 273 information related to customer VPLS domains and employ methods to 274 forward customer traffic based on that information. In this 275 document, the PE nodes are meant in logical sense. In the actual 276 implementations, the PE nodes may be comprised of several physical 277 devices. Conversely, a single physical device may contain more than 278 one PE node. 280 All forwarding decisions related to customer VPLS traffic MUST be 281 made by PE nodes. This requirement prohibits any other network 282 components from altering decisions made by PE nodes. 284 6.6 PE-PE Interconnection and Tunneling 286 A VPLS system MUST provide for connectivity between each pair of PE 287 nodes. The connectivity is referred to as transport tunneling or 288 simply tunneling. 290 There are several choices for implementing transport tunnels. Some 291 popular choices include MPLS, IP in IP tunnels, variations of 292 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 294 802.1Q, etc. Regardless of the choice, the existence of the tunnels 295 and their operations MUST be transparent to the customers. 297 6.7 PE-CE Interconnection and Profiles 299 A VPLS system MUST provide for connectivity between PE nodes and CE 300 nodes. That connectivity is referred to as an Attachment Circuit 301 (AC). Attachment Circuits MAY span networks of other providers or 302 public networks. 304 There are several choices for implementing ACs. Some popular choices 305 include Ethernet, ATM (DSL), Frame Relay, MPLS-based virtual 306 circuits etc. Regardless of the choice, the ACs MUST use Ethernet 307 frames as the Service Protocol Data Unit (SPDU). 309 A CE access connection over an AC MUST be bi-directional in nature. 311 PE devices MAY support multiple ACs on a single physical interface. 312 In such cases, PE devices MUST NOT rely on customer controlled 313 parameters for distinguishing between different access connections. 314 For example, if VLAN tags were used for that purpose, the provider 315 would be controlling the assignment of the tag values and would 316 strictly enforce compliance by the CEs. 318 An AC connection, whether direct or virtual, MUST maintain all 319 committed characteristics of the customer traffic, such as QoS, 320 priorities etc. The characteristics of an AC connection are only 321 applicable to that connection. 323 7 Control Plane Requirements 325 7.1 Provider Edge Signaling 327 The control protocols SHOULD provide methods for signaling between 328 PEs. The signaling SHOULD inform of membership, tunneling 329 information, and other relevant parameters. 331 The infrastructure MAY employ manual configuration methods to 332 provide this type of information. 334 The infrastructure SHOULD use policies to scope the membership and 335 reachability advertisements for a particular VPLS. 337 7.2 VPLS Membership Discovery 339 The control plane and/or the management plane SHOULD provide methods 340 to discover the PEs which connect CEs forming a VPLS. 342 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 344 7.3 Support for Layer 2 control protocols 346 The VPLS system's control protocols SHOULD allow transparent 347 operation of Layer 2 control protocols employed by customers. 349 A VPLS system MUST ensure that loops be prevented. This can be 350 accomplished through a loop free topologies or appropriate 351 forwarding rules. Control protocols such as Spanning Tree (STP) or 352 similar could be employed. The system's control protocols MAY use 353 indications from customer control protocols, e.g. STP, to improve 354 the operation of a VPLS. 356 7.4 Scaling Requirements 358 In a VPLS system, the control plane traffic increases with the 359 growth of VPLS membership. Similarly, the control plane traffic 360 increases with the number of supported VPLS domains. The rate of 361 growth of the associated control plane traffic SHOULD be linear. 363 The use of control plane resources increases with the number of 364 hosts connected to a VPLS. The rate of growth of the demand for 365 control process resources SHOULD be linear. The control plane MAY 366 offer means for enforcing a limit on the number of customer hosts 367 attached to a VPLS. 369 8 Data Plane Requirements 371 8.1 Transparency 373 VPLS service is intended to be transparent to Layer 2 customer 374 networks. It SHOULD NOT require any special packet processing by 375 the end users before sending packets to the provider's network. 377 8.2 QoS and packet re-ordering 379 A VPLS system SHOULD have capabilities to enforce QoS parameters. 381 The queuing and forwarding policies SHOULD preserve packet order for 382 packets with the same QoS parameters. 384 The service SHOULD not duplicate packets. 386 8.3 Broadcast Domain 388 The Broadcast Domain is defined as the flooding scope of a Layer 2 389 network. A separate Broadcast Domain MUST be maintained for each 390 VPLS. 392 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 394 In addition to VPLS Broadcast Domains, a VPLS system MAY recognize 395 customer VLAN Broadcast Domains. In that case, the system SHOULD 396 maintain a separate VLAN Broadcast Domain for each customer VLAN. A 397 VLAN Broadcast Domain MUST be a subset of the owning VPLS Broadcast 398 Domain. 400 8.4 MAC address learning 402 A VPLS service SHOULD derive all topology and forwarding information 403 from packets originating at customer sites. Typically, MAC 404 addresses learning mechanisms are used for this purpose. 406 In a VPLS system, MAC address learning MUST take place on a per 407 Virtual Switching Instance (VSI) basis, i.e. in the context of a 408 VPLS and, if supported, in the context of VLANs therein. 410 8.5 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding 412 VPLS MUST be aware of the existence and the designated roles of 413 special MAC addresses such as Multicast and Broadcast addresses. 414 VPLS MUST forward these packets according to their intended 415 functional meaning and scope. 417 Broadcast packets MUST be flooded to all destinations. 419 Multicast packets MUST be flooded to all destinations. However, a 420 VPLS system MAY employ multicast snooping techniques, in which case 421 multicast packets SHOULD be forwarded only to their intended 422 destinations. 424 Unicast packets MUST be forwarded to their intended destinations. 426 Unknown Unicast packets MUST be flooded to all destinations in the 427 flooding scope of the VPLS (or VLAN). If the VPLS service relies on 428 MAC learning for its operations, it MUST assure proper forwarding of 429 packets with MAC addresses that have not been learned. Once 430 destination MAC addresses are learned, unicast packets SHOULD be 431 forwarded only to their intended destinations. 433 A provider MAY employ a method to limit the scope of flooding of 434 Unknown Unicast packets in cases where a customer desires to 435 conserve its bandwidth or wants to implement certain security 436 policies. 438 8.6 Virtual Switching Instance 440 VPLS Provider Edge devices MUST maintain a separate Virtual 441 Switching Instance (VSI) per each VPN. Each VSI MUST have 442 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 444 capabilities to forward traffic based on customer's traffic 445 parameters such as MAC addresses, VLAN tags (if supported), etc. as 446 well as local policies. 448 VPLS Provider Edge devices MUST have capabilities to classify 449 incoming customer traffic into the appropriate VSI. 451 Each VSI MUST have flooding capabilities for its Broadcast Domain to 452 facilitate proper forwarding of Broadcast, Multicast and Unknown 453 Unicast customer traffic. 455 8.7 Minimum MTU 457 The VPLS service MUST support customer frames with payload 1500 458 bytes long. The service MAY offer support for longer frames. 460 The service MUST NOT fragment packets. Packets exceeding committed 461 MTU size MUST be discarded. 463 The committed minimum MTU size MUST be the same for a given instance 464 of VPLS. Different VPLS instances MAY have different committed MTU 465 sizes. If VLANs are supported, all VLANs within a given VPLS MUST 466 inherit the same MTU size. 468 8.8 Multilink Access 470 The VPLS service SHOULD support multilink access for CE devices. 471 The VPLS service MAY support multihome access for CE devices. 473 8.9 End-point VLAN tag translation 475 If VLANs are recognized, the VPLS system MAY support translation of 476 customers' VLAN tags. Such service simplifies connectivity of sites 477 that want to keep their tag assignments or sites that belong to 478 different administrative entities. In the latter case, the 479 connectivity is sometimes referred to as L2 extranet. 481 8.10 Support for MAC Services 483 VPLS are REQUIRED to provide MAC service compliant with IEEE 802.1D 484 specification [5] Section 6. Compliance with this section 485 facilitates proper operation of 802.1 LAN and seamless integration 486 of VPLS with bridged Local Area Networks. It is also useful to 487 compare [6], [7], and [8]. 489 A MAC service in the context of VPLS is defined as the transfer of 490 user data between source and destination end stations via the 491 service access points using the information specified in the VSI. 493 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 495 1. A PE device that provides VPLS MUST NOT be directly accessed by 496 end stations except for explicit management purposes. 498 2. All MAC addresses MUST be unique within a given broadcast domain. 500 3. The topology and configuration of the VPLS MUST NOT restrict the 501 MAC addresses of end stations 503 9 Management and Operations Requirements 505 9.1 VPLS configuration and monitoring 507 A VPLS system MUST have capabilities to configure, manage, and 508 monitor its different components. 510 It SHOULD be possible to create several disjoint instances of VPLS 511 systems within the same underlying network infrastructures. 513 The infrastructure SHOULD monitor all characteristics of the service 514 that are reflected in the customer SLA. This includes but is not 515 limited to bandwidth usage, packet counts, packet drops, service 516 outages, etc. 518 9.2 VPLS operations 520 The operations of a VPLS systems is controlled by an Administrative 521 Authority (Admin). The Admin is the originator of all operational 522 parameters of a VPLS system. Conversely, the admin is also the 523 ultimate destination for the status of the VPLS system and the 524 related statistical information. A typical VPLS system spans 525 several such Admins. 527 A VPLS system MUST support proper dissemination of operational 528 parameters to all elements of a VPLS system in the presence of 529 multiple Admins. 531 A VPLS system MUST employ mechanisms for sharing operational 532 parameters between different Admins. These mechanism MUST NOT 533 assume any particular structure of the different Admins. For 534 example the VPLS should not be relying on Admins forming a 535 hierarchy. 537 A VPLS system SHOULD support policies for proper selection of 538 operational parameters coming from different Admins. Similarly, a 539 VPLS system SHOULD support policies for selecting information to be 540 disseminated to different Admins. 542 A VPLS system SHOULD employ discovery mechanisms to minimize the 543 amount of operational information maintained by the Admins. For 544 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 546 example, if an admin adds or removes a customer port on a given PE, 547 the remaining PEs should determine the necessary actions to take 548 without the Admins having to explicitly reconfigure those PEs. 550 9.3 CE Provisioning 552 The VPLS MUST require only minimal or no configuration on the CE 553 devices, depending on the CE device that connects into the 554 infrastructure. 556 9.4 Customer traffic policing 558 The VPLS service SHOULD provide the ability to police and/or shape 559 customer traffic entering and leaving the VPLS system. 561 9.5 Dynamic Service Signaling 563 A Provider MAY offer to customers an in-band method for selecting 564 services from the list specified in the SLA. A Provider MAY use the 565 same mechanism for reporting statistical data related to the 566 service. 568 9.6 Class of Service Model 570 The VPLS service MAY define a graded selection of classes of 571 traffic. These include, but are not limited to 573 o range of priorities 574 o best effort vs. guaranteed effort 575 o range of minimum delay characteristics 577 9.7 VPLS service access option. 579 The VPLS service SHOULD allow for a Provider based Service Access 580 for orderly injection of L3 or higher services to the customers' 581 VPLS networks. 583 In particular, the system SHOULD allow to build L3VPN services, 584 including L3 interworking schemes such as ARP mediation or similar. 586 As a value added service, a Provider MAY offer access to other 587 services such as, IP gateways, storage networks, content delivery 588 etc. 590 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 592 9.8 Testing 594 The VPLS service SHOULD provide the ability to test and verify 595 operational and maintenance activities on a per VPLS basis and, if 596 supported, on a per VLAN basis. 598 9.9 Learning information from customer devices 600 The VPLS service SHOULD provide means for limiting the amount of 601 information learned from customer devices. For example, VPLS 602 implementations may limit the number of MAC addresses learned from 603 the customers' devices. 605 10 Security Requirements 607 10.1 Traffic separation 609 A VPLS system MUST provide traffic separation between different VPLS 610 domains. If VLANs are supported, the system MUST provide traffic 611 separation between customer VLANs within each VPLS domain. 613 10.2 Provider network protection. 615 A VPLS system MUST be immune to malformed or maliciously constructed 616 customer traffic. This includes but is not limited to duplicate or 617 invalid L2 addresses, customer side loops, short/long packets, 618 spoofed management packets, spoofed VLAN tags, etc. 620 The VPLS infrastructure devices MUST NOT be accessible from the 621 VPLS. 623 10.3 Value added security services 625 Value added security services such as encryption and/or 626 authentication of customer packets, certificate management, and 627 similar are OPTIONAL. 629 Security measures employed by the VPLS system SHOULD NOT restrict 630 implementation of customer based security add-ons. 632 11 References 634 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 635 9, RFC 2026, October 1996. 637 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 639 2. Carugi, et al., "Service requirements for Provider Provisioned 640 Virtual Private Networks ", Work in progress, December 2001. 642 3. Nagarajan et al., " Generic Requirements for Provider Provisioned 643 VPN", Work in progress, September 2002. 645 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement 646 Levels", BCP 14, RFC 2119, March 1997. 648 5. ANSI/IEEE Std 802.1D 1998 Edition, "Media Access Control (MAC) 649 Bridges", 1998. 651 6. IEEE Standard 802.1Q, "IEEE Standards for Local and Metropolitan 652 Area Networks: Virtual Bridged Local Area Networks", 1998. 654 7. IEEE Standard 802.1u-2001, "IEEE Standard for Local and 655 Metropolitan Area Networks: Virtual Bridged Local Area Networks - 656 Amendment 1: Technical and editorial corrections", 2001. 658 8. IEEE Standard 802.1v-2001, "IEEE Standard for Local and 659 Metropolitan Area Networks: Virtual Bridged Local Area Networks - 660 Amendment 2: VLAN Classification by Protocol and Port", 2001. 662 12 Acknowledgments 664 We would like to acknowledge extensive comments provided by Loa 665 Anderson, Joel Halpern, and Eric Rosen. The authors, also, wish to 666 extend appreciations to their respective employers and various other 667 people who volunteered to review this work and provided feedback. 669 13 Authors' Addresses 671 Waldemar Augustyn 672 Email: waldemar@nxp.com 674 Giles Heron 675 PacketExchange Ltd. 676 The Truman Brewery 677 91 Brick Lane 678 London E1 6QL 679 United Kingdom 680 Email: giles@packetexchange.net 681 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 683 Vach Kompella 684 TiMetra Networks 685 274 Ferguson Dr. 686 Mountain View, CA 94043 687 Email: vkompella@timetra.com 689 Marc Lasserre 690 Riverstone Networks 691 5200 Great America Pkwy 692 Santa Clara, CA 95054 693 Phone: 408-878-6500 694 Email: marc@riverstonenet.com 696 Pascal Menezes 697 Terabeam 698 Phone: 206-686-2001 699 Email: pascal.menezes@terabeam.com 701 Hamid Ould-Brahim 702 Nortel Networks 703 P.O. Box 3511 Station C 704 Ottawa ON K1Y 4H7 705 Canada 706 Phone: 613-765-3418 707 Email: hbrahim@nortelnetworks.com 709 Tissa Senevirathne 710 Email: tsenevir@hotmail.com 711 draft-ietf-ppvpn-vpls-requirements-01.txt October 2002 713 Full Copyright Statement 715 "Copyright (C) The Internet Society (2001). All Rights Reserved. 716 This document and translations of it may be copied and furnished to 717 others, and derivative works that comment on or otherwise explain it 718 or assist in its implementation may be prepared, copied, published 719 and distributed, in whole or in part, without restriction of any 720 kind, provided that the above copyright notice and this paragraph 721 are included on all such copies and derivative works. However, this 722 document itself may not be modified in any way, such as by removing 723 the copyright notice or references to the Internet Society or other 724 Internet organizations, except as needed for the purpose of 725 developing Internet standards in which case the procedures for 726 copyrights defined in the Internet Standards process must be 727 followed, or as required to translate it into languages other than 728 English. 730 The limited permissions granted above are perpetual and will not be 731 revoked by the Internet Society or its successors or assigns. 733 This document and the information contained herein is provided on an 734 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 735 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 736 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 737 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 738 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."