PPVPN Working Group Loa Andersson Internet-Draft Utfors AB Expiration Date: December 2002 28 June, 2002 Parameters and related metrics to compare PPVPN Layer 2 solutions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [rfc2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Summary for Sub-IP related Internet Drafts RELATED DOCUMENTS: Section 5 lists an extensive list of current drafts submitted to the PPVP WG. WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID is intended for the PPVPN WG. WHY IS IT TARGETED AT THIS WG(s) INTERNET-DRAFT draft-andersson-ppvpn-terminolgy-01.txt 28 June, 2002 Andersson Expires December 2002 [Page 2] The PPVPN WG deals with provider provisioned VPNs. This document describes metrics for Layer 2 Provider Provisioned Virtual Private Network services, a class of Provider Provisioned Virtual Private Networks services. JUSTIFICATION This document describes some parameters and related metrics which could be used for classifying solutions in the Layer 2 space and, possibly, for evaluating commonalities and differences, pros and cons of the functional options specific to each solution. As complementary result, the document aims to provide input to the PPVPN WG for further definition of a limited set of candidate solutions in the Layer 2 solution space, promoting commonalities and convergence among solutions in respect of the key service requirements. The parameters and related metrics under consideration are inspired from the appropriate service requirement drafts ([L2VPN-REQ], etc.) and are then relevant for evaluating the Layer 2 VPN solutions against significant requirements for customers and service providers. In this perspective, the metrics will be also aligned with the PPVPN Applicability Statement Guidelines document [APPL-GUIDE] and will provide input for each candidate solution-specific Layer 2 Applicability Statement. The extension of this document to Layer 3 VPNs in a further version has to be evaluated. Abstract The PPVPN working group deals with provider provisioned VPNs. This document describes metrics primarily for Layer 2 Virtual Private Networks, to be used in comparing solutions proposal and later when comparing new proposals to the existing. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [rfc2119]. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 3] Contents 1. Introduction...................................................... 4 2. Metrics........................................................... 4 2.1 Type Service.................................................. 5 2.2 Provisioning.................................................. 5 2.3 Discovery..................................................... 6 2.4 VPN "Signaling"............................................... 7 2.5 Coupling...................................................... 8 3. Reference tree.................................................... 8 3.1 Classification Tree........................................... 8 4. Non-metrics...................................................... 10 4.1 Tunnel technology............................................ 10 4.2 Security..................................................... 10 5. List of Layer 2 VPN drafts....................................... 10 6. Metrics and parameter matrix..................................... 15 6.1 Service quality.............................................. 15 6.2 Scaling...................................................... 16 6.3 SLA enforcements............................................. 17 6.4 Inter-domain reachability.................................... 18 6.5 Provisioning cost/complexity................................. 18 6.6 Flexibility.................................................. 19 6.7 Integration and migration.................................... 19 6.8 Value-add services........................................... 20 6.9 Cost......................................................... 20 7. Summary and recommendations...................................... 21 7.1 Documents for VPLS type of services.......................... 21 7.2 Document for VPWS type of services:.......................... 21 7.3 Protocol extensions.......................................... 21 7.4 Architecture and Framework................................... 22 8. Security......................................................... 22 INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 4] 1. Introduction The Provider Provisioned VPN solutions have attracted a great deal of interest and several solutions have been proposed. There is clearly a need for an organized way of comparing the solutions and elements in the solutions. This document proposes such a method; it is based on some generic elements that have to be present/solved by every VPN implementation. This version of the draft is very much focused on the L2 VPNs, and that is natural since it comes out of a L2 VPN design team effort. The L3 parts of this document is included to only show the potential to include a more extensive treatment of L3 VPNs in the future. Concepts and terminology in this document are according to [TERM]. 2. Metrics When implementing customer VPNs in a provider network a certain set of metrics has to be considered, see e.g. [L2VPN-REQ], in future versions of this document further references will be added, e.g. other requirement documents and Applicability Statement Guidelines document. Examples of such metrics are: - service quality - scaling, e.g. number of nodes per VPN, number of nodes per site or number of VPN per network - SLA enforcements - inter-domain reachability - provisioning cost/complexity - flexibility - integration with and migration from existing infrastructure and services - value-add services - cost - etc. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 5] In deciding which solution to be implemented in a given situation the relevant metrics for each of the parameters below could be considered. 2.1 Type Service Currently we see three different types of provider provisioned VPN services, Layer 3 VPN, Virtual Private Wire Service (VPWS) and Virtual private LAN Service (VPLS). A framework for L3-VPNs is found in [L3- FRMWRK] and a framework for Layer 2 VPNs is found in [L2-FRMWRK]. The [L2-FRMWRK] also opens up for a discussion of an IP-only LAN-like Service (IPLS), however this is for further discussion. A joint name for the VPLS and the VPWS is Layer 2 VPNs, potentially the IPLS will be included in this group. 2.1.1 Layer3 VPN A L3 VPN is an IP routed network, where addresses could be either from the public or private address space. Being a routed service it will scale based on how many routes the Provider Edge routers (PE) are able to handle in their VRFs. Scaling properties are very good for L3VPN, and is not in general dependent on standards or specification, but rather on the networking equipment or network(s) it is implemented. More detailed treatment of L3 VPNs are for future versions of this document. 2.1.2 Virtual Private Wire Service (VPWS) A VPWS is a VPN service that supplies a L2 point-to-point service across a Wide Area Network (WAN) or a Metropolitan Area Network (MAN). Being a point-to-point service where there are very few scaling issues with the service as such. Scaling issues might arise from the number of end- points that can be supported on a particular PE. 2.1.3 Virtual Private LAN Service (VPLS) A VPLS is an L2 service that in all respects emulates LAN across a Wide Area Network (WAN) or a Metropolitan Area Network (MAN). Thus it also has all the scaling characteristics of a LAN. Other scaling issues might arise from the number of end-points that can be supported on a particular PE. 2.2 Provisioning It is critical to limit the time and effort that a service provider needs to spend on provisioning customer VPNs. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 6] 2.2.1 Static We say that a VPN is static configured if all information ˇ attachment circuits, tunnels, routing/forwarding information, QoS parameters, etc. ˇ are manually configured at each node participating in the VPN service. 2.2.2 Automatic In an automatic configured network it is possible to enter configuration parameters on one single spot, e.g. the PE. 2.3 Discovery Discovery involves discovering e.g. VPNs and VPN end-points, in such a way that they may be connected to the VPN. The most important parameter in comparing different discovery mechanisms is the time it takes from that the information is configured until all nodes that need to know it has that information. 2.3.1 BGP A basic function in BGP is to advertise information BGP speaking peers. In VPN solutions MP-BGP is used to distribute information that is used in a PE to map traffic from an attachment circuit to a PE-to-PE tunnel and which de-multiplexor to use, and vice versa. The scaling issues in using BGP as discovery protocol are few. The number of VPNs in a network, the number of hosts per site, the number of sites per VPN and number of VPN instances per PE is not in any way limited by the use of BGP. 2.3.2 Directory based In a directory based solution the information needed by a PE to set up tunnels and de-multiplexors are configured in a directory, the Pes supporting a particular VPN then can and go look up the information needed to establish the connectivity and other configuration information needed for that VPN. Note: For a future treatment of L3 VPNs discovery by means of Multicast IGP has to be added. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 7] 2.4 VPN "Signaling" VPN Signaling involves distributing information between PEs so the PE can take a local decision on setting up tunnels and distributing de- multiplexors correctly for the Layer 2 VPN sites connected to the PE. 2.4.1 L2TP Extension to L2TP to make is possible to signal information between Pes for establishing de-multiplexors has been presented in [L2TP]. 2.4.2 RSVP-TE RSVP-TE (RSVP Tunnel Extensions) is a protocol that was developed to set up LSPs with certain constraints, e.g. bandwidth and/or explicit routes. There are proposals to use RSVP-TE in situations where only a few VPNs are present and where QoS parameters are important. 2.4.3 LDP Label Distribution Protocol (LDP) is a protocol that has been developed to distribute MPLS labels within a domain. LDP has no method defined for carrying explicit routes or QoS information. The targeted LDP makes it possible to communicate between two non- adjacent LSRs to set up de-multiplexors between Pes. LDP has a reliable delivery mechanism since it is based on TCP. Main benefit by using LDP is that it is readily available in almost any MPLS enabled IP network. In the context of provider provisioned VPNs there are few scaling issues with LDP, LDP has however not a method to carry information across AS borders. 2.4.4 BGP BGP is a protocol that in the context of VPNs is used both for discovery and to signal necessary information (e.g. de-multiplexors) to set up end-to-end connectivity across the core network tunnels. For signalling purposes it is the Multi-Protocol extensions to BGP (MP-BGP) that is used. BGP has a reliable delivery mechanism since it is based on TCP. Main benefits by using BGP are that it has become a common denominator in networks that run MPLS based VPNs and that it by its nature is possible to use for Inter-Domain areas. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 8] In the context of provider provisioned VPNs there are few scaling issues with MP-BGP. 2.5 Coupling The concept of "coupling" relates to Layer 2 VPNs and how the functionality needed for the service is allocated relative to the Pes; it describes e.g. how MAC-learning and signalling functions are distributed across different devices. 2.5.1 Coupled In a coupled situation all functions are located on the same physical device. 2.5.2 De-coupled In a de-coupled situation functions are distributed across at least two different physical devices. De-coupled solutions are found in [DTLS] and [LPE], taxonomy and terminology for de-coupled solutions is found in [TERM]. 3. Reference tree By using the parameters discussed in section 2 it is possible to create a decision tree that can be used to classify the existing VPN proposals. By traversing the tree from top to bottom a short hand description of the solution is created and could easily be compared with other solutions. 3.1 Classification Tree INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 9] Type of Service L3VPN VPW VPLS | | | | | | | +-------------------+-+-------+ | | | | | | | | +-----------+ +-----+-+-------+--------+ | | +-+-----+ | | | | | +-----+ | +-------+ | | | || | v v v vv v Provisioning Static Automatic | | | | | +--------------+ | | | | | | | | | | | | | | | +--------------+-+ | | | | | v v v v Discovery BGP Directory based |||| | | | | +----------+||+----------------+-+-+-+-+ | || | | | | | | |+-----------+ | | | | | |+----------+------------+-----+ | | | | || |+-----------+-------+ | | | || || |+--------+ | | || || || | | vv vv vv v v Signalling L2TP RSVP-TE LDP BGP | | | | | | || | +---------+-+----------+-+------+ || | | | | | | || +--------+ | +----------+ +---+ | || | | | | | | || | | +---------+-+---+--+--+| | | | | | | | | | | |+--------+ +---+--+--+| | | || | | || | | || | | || v v vv v v vv Coupling Coupled De-Coupled Note: The L3 branch is in the tree for further study only. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 10] 4. Non-metrics Some of the issues that may seem obvious to consider when deciding how to deploy a VPN are considered to be outside the scope of this document. Some of those are listed here. 4.1 Tunnel technology Most VPNs are implemented by means of a set of tunnels between the PEs of that service. Tunnel technology and the methods to signal the set up of the tunnel are outside the scope of this document. The establishment of the tunnel is viewed as inherent to the network; it is even conceivable that different "legs" of the VPN might use different tunnel technologies. 4.2 Security VPN technologies supply a traffic separation between customers and customer services. This is the same level of traffic separation that e.g. is supplied by traditional WAN technology based VPNs. Further security mechanisms, e.g. encryption is outside the scope of this document. 5. List of Layer 2 VPN drafts In this section the current drafts addressed to the ppvpn working group is classified according to the parameters in the classification tree in section 3. As documents do not address every aspect of a VPN some entries says Not Applicable (NA). Sometimes what is describe in the document are equally applicable to all the values a parameter make take, those entries says "All". For the aspects that are discussed in the document specific values are entered. Note: For version ˇ01 this process is not completed, the the list of Layer 2 VPN drafts needs to be further discussed and agreed upon. draft-ietf-ppvpn-bgpvpn-auto-02.txt This draft defines a BGP based auto-discovery mechanism for both Layer 2 VPNs and Layer 3 VPNs. This mechanism is based on the approach used by RFC2547-bis for distributing VPN routing information within the service provider(s). Each VPN scheme uses the mechanism to automatically discover the information needed by that particular scheme. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 11] Classification: Type of Service: All Provisioning: NA Discovery: BGP Signalling: NA Coupling: NA draft-ietf-ppvpn-l2vpn-00.txt This document discusses the signalling, encapsulation, and configuration issues that arise. Its purpose is to provide an architecture which allows different kinds of point-to-point virtual circuits to be provided through different kinds of IP tunnels. Classification: Type of Service: Provisioning: Discovery: Signalling: Coupling: NA draft-augustyn-vpls-arch-00.txt This document describes the architecture and model for Virtual Private LAN Services (VPLS) and discusses the signalling, encapsulation, and configuration issues that arise. draft-augustyn-vpls-bw-00.txt This document describes a method for controlling customer traffic for L2 VPN services which support broadcast, multicast or implied broadcast such as e.g. VPLS. draft-augustyn-vpls-requirements-02.txt This document specifies requirements for a VPLS, the intention is to extend it to comprise all types of Layer 2 VPNs. draft-cai-ppvpn-vc-rsvp-te-00.txt This draft discusses the use of RSVp-TE as a VC setup mechanism. draft-chen-ppvpn-dvpls-compare-00.txt This draft compares different solutions for decouple PE functionality in a VPLS. It advocates a merging of existing drafts. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 12] draft-elwin-l2tpext-ppvpn-00.txt PPVPNs need a tunneling mechanism and a means to automatically discover VPN membership and signal these tunnels. This draft elaborates the use of L2TP as the tunneling mechanism, and defines extensions to L2TP to handle VPN membership discovery to leverage PPVPNs. draft-elwin-ppvpn-l2tp-arch-00.txt This document discusses the use of L2TP for establishing PPVPNs. It proposes to use L2TP for VPN membership, topology discovery, and as a tunnelling mechanism. draft-heinanen-dirldp-uni-vc-vpns-01.txt This document describes how provider based unidirectional Virtual Circuit VPNs can be implemented using a directory (such as DNS) and LDP for PE discovery and label distribution. draft-Heinanen-dns-ldp-vpls-00.txt This document describes how provider provisioned Virtual Private LAN Service (VPLS) can be implemented using DNS and LDP for PE discovery and label distribution. draft-heinanen-inarp-uni-01.txt This document describes operation of an Inverse Address Resolution Protocol (InARP) over unidirectional virtual circuits such as MPLS LSPs. draft-khandekar-ppvpn-hvpls-mpls-00.txt This document proposes extensions to draft-lasserre-vkompella- ppvpn-tls-00.txt, by introducing hierarchical connectivity. This document also describes support for participation of non-bridging PE devices in a VPLS solution. draft-knight-l2vpn-lpe-ad-00.txt This document describes a lightweight protocol for VPLS information exchange between Logical PE components, consisting of the PE-Edge (i.e. in the terminology of [TERM] the User facing-PE (U-PE)) and PE-Core (i.e. in the terminology [TERM] of the Network facing-PE (N-PE)). draft-kompella-ppvpn-dtls-01.txt INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 13] In a VPLS a common scenario is when Service Provider in a metro area places a simple, low-cost box (MTU, i.e. in the terminology of [TERM] a User facing-PE (U-PE)) in each building; these MTUs have uplinks to some box (PE, i.e. in the terminology of [TERM] a Network facing-PE (N-PE)) in one or more provider site. The document describes decoupling the functions needed to offer the VPLS across the MTU and PE. draft-kompella-ppvpn-l2vpn-01.txt This document present a Layer 2 VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single network for IP, IP VPNs, and Layer 2 VPNs. draft-kompella-ppvpn-vpls-00.txt In the case of a VPLS, a point to multipoint network connects the customers in the VPN. This document describes the functions needed to offer a VPLS, and propose a mechanism for signaling a VPLS, and a mechanism for transport of VPLS frames over tunnels across a packet switched network. draft-lasserre-vkompella-ppvpn-tls-00.txt This document describes a VPLS solution over MPLS. VPLS simulates an Ethernet virtual 802.1d bridge for a given set of users. It deliver a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses that is closed to a given set of users. draft-lau-ppvpn-qos-tls-mpls-00.txt draft-lasserre-vkompella-ppvpn-vpls-00.txt describes a solution to support point-to-multipoint VPLSs over MPLS. This document describes two extensions to facilitate the provisioning and support of QoS in VPLS over MPLS. The use of the VCID field in the VC-FEC is extended to identify a VPN endpoint. One VC-label per source/destination VPN endpoint pair is used. draft-luciani-ppvpn-vpn-discovery-01.txt This document describes the use of DNS to discovery VPN endpoints. draft-martini-l2circuit-encap-mpls-04.txt This document describes methods for encapsulating the Protocol Data Units (PDus) of layer 2 protocols such as Frame Relay, ATM, or Ethernet for transport across an MPLS or IP network. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 14] draft-martini-l2circuit-trans-mpls-08.txt This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. draft-menezes-inter-city-man-mpls-00.txt This document describes a network service model for high-speed Metropolitan Area Network (MAN) service providers to services between cities. It simplifies MAN operation and improves the scalability of a traditional standard overlay model by allowing the MAN provider to peer to the NSP for both Internet transit and inter-city MAN services (e.g. a VPLS). draft-ouldbrahim-bgpgmpls-ovpn-02.txt This document describes a method for how a service provider network that offers Optical/TDM Virtual Private Network service. draft-ouldbrahim-l2vpn-lpe-01.txt In a VPLS a common scenario is when Service Provider in a metro area places a simple, low-cost box Edge-PE (i.e. in the terminology of [TERM] a User facing-PE (U-PE)) in each Building; these Edge-PEs have uplinks to some box Core-PE (i.e. in the terminology of [TERM] the Network facing-PE) in one or more provider sites. This document describes decoupling the functions needed to offer the VPLS across the Edge-PEs and Core-PE. draft-rosen-ppvpn-l2-signaling-01.txt This draft describes a signaling technique that eliminates the requirement for a priori knowledge of a common VC identifier, and to eliminate the requirement that each endpoint be known to The other. draft-sajassi-vpls-architectures-00.txt In this document a reference architecture for VPLS systems is defined. It describes possible VPLS architectures based on this reference architecture and the logical components of each. draft-senevirathne-vmi-frame-02.txt This document presents a framework for a VPLS and a point-to-point Layer 2 VPN service. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 15] draft-shah-ppvpn-arp-mediation-00.txt This draft specifies the procedures, which the Provider Edge routers should perform in order to allow correct operation of address resolution across heterogeneous point-to-point links. draft-shah-ppvpn-vpls-pe-mtu-signaling-00.txt draft-kompella-ppvpn-dtls-01.txt identifies the need for an information exchange mechanism between a PE device (i.e. in the terminology of [TERM] the Network facing-PE) and its adjunct L2PE devices (i.e. in the terminology of [TERM] the User facing-PE) in the decoupled VPLS. This draft proposes an LDP based approach for such exchange mechanisms. draft-tsenevir-gre-vpls-00.txt In this document a VPLS solution that use GRE and IP tunnels is described. 6. Metrics and parameter matrix In this section each of the parameters in section 2.1 to 2.5 is examined according to the metrics in the classification tree section (section 3). 6.1 Service quality Service quality has many aspects, there are traffic related aspects e.g. bandwidth, delay and jitter (depending on context called QoS, ToS or CoS. There are also other aspects as availability, fail over times, start up times, activation time and delivery times. 6.1.1 Type of Service Type of service and service quality is closely connected. The inter relationship is for further study. 6.1.2 Provisioning There is no reason to suspect that the method chosen to provision the VPN will have an impact service quality once the necessary connectivity has been established. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 16] 6.1.3 Discovery There is no reason to suspect that the method of discovery will effect the service quality once a VPN member is discovered and properly attached to the VPN. It is possible that availability and activation times could be affected by the choice of discovery mechanism. 6.1.4 Signalling There is no reason to suspect that the method chosen to set up pseudowires will have an impact service quality once the pseudowire has been established. One possible effect of the selection of method for distributing de- multiplexors for solutions where recovery is done on a post facto basis is that fail over times may be effected. 6.1.5 Coupling There is no reason to suspect that whethere the PE is of a coupled or de-coupled type will have an impact service quality, given that the connectivity is feasible. 6.2 Scaling Scaling is one of the most discussed aspects of Layer 2 VPNs, and especially VPLS solutions. It is the stated goal of most VPLS solutions to scale in the same manner as traditional LAN. There are also other scaling aspects that are of interest, e.g. number of nodes (mac addresses) per VPN, number of sites per VPN, or number of VPNs in an operator network. 6.2.1 Type of Service Clearly a Layer 3 VPN has other internal scaling properties than a Layer 2 VPN, communication is based on IP routing and routers that split the network up to a manageable size. Scaling in terms of supporting a high number of Layer 2 VPNs or Layer 3 VPNs, or a combination of them, in a provider network are very similar. 6.2.2 Provisioning The scaling issues when it comes to provision different types of VPNs depends on how many nodes one "has to touch". A system there one need to INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 17] configure every node and set up every tunnel, PW and attachment circuit separately and manually, for each node that is added to the VPN, has very different scaling characteristics as compared to a system where one configure the relevant information on the node once you have decided that it supports a specific VPN. 6.2.3 Discovery For further study (FFS). 6.2.4 Signalling There are two different aspects of signalling (de-multiplexor distribution) that needs to be discussed. First how the de-multiplexor systems are supported and second the result of the signalling. A de-multiplexor distribution system that is based on running a peering process between two PEs that needs to exhange de-multiplexors, in combination with PEs that only support a limit number of such processes will run into scaling problems. 6.2.5 Coupling FFS. 6.3 SLA enforcements FFS. 6.3.1 Type of Service FFS. 6.3.2 Provisioning FFS. 6.3.3 Discovery FFS. 6.3.4 Signalling FFS. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 18] 6.3.5 Coupling FFS. 6.4 Inter-domain reachability FFS. 6.4.1 Type of Service FFS. 6.4.2 Provisioning FFS. 6.4.3 Discovery FFS. 6.4.4 Signalling FFS. 6.4.5 Coupling FFS. 6.5 Provisioning cost/complexity FFS. 6.5.1 Type of Service FFS. 6.5.2 Provisioning FFS. 6.5.3 Discovery FFS. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 19] 6.5.4 Signalling FFS. 6.5.5 Coupling FFS. 6.6 Flexibility FFS. 6.6.1 Type of Service FFS. 6.6.2 Provisioning FFS. 6.6.3 Discovery FFS. 6.6.4 Signalling FFS. 6.6.5 Coupling FFS. 6.7 Integration and migration FFS. 6.7.1 Type of Service FFS. 6.7.2 Provisioning FFS. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 20] 6.7.3 Discovery FFS. 6.7.4 Signalling FFS. 6.7.5 Coupling FFS. 6.8 Value-add services FFS. 6.8.1 Type of Service FFS. 6.8.2 Provisioning FFS. 6.8.3 Discovery FFS. 6.8.4 Signalling FFS. 6.8.5 Coupling FFS. 6.9 Cost FFS. 6.9.1 Type of Service FFS. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 21] 6.9.2 Provisioning FFS. 6.9.3 Discovery FFS. 6.9.4 Signalling FFS. 6.9.5 Coupling FFS. 7. Summary and recommendations >From the number of Internet draft on requirements, architectures and solutions seen in the Layer 2 VPN area it is possible to draw the conclusion that there is a high degree on commonalties and a great interest in this area. Within the PPVPN WG it is a common understanding that the existing set of solutions need to be limited to a more manageable set of unified solutions. 7.1 Documents for VPLS type of services This for a future version of this document. 7.2 Document for VPWS type of services: This for a future version of this document. 7.3 Protocol extensions To the extent extensions are needed for protocol that originates from other working groups than PPVPN they should be handled in separate documents. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 22] 7.4 Architecture and Framework Architecture and framework issues on a general level for L2 PPVPNs should be consolidated and incorporated in this document. 8. Security This is a document that outlines how to compare solutions in the L2 VPN space; while security considerations might be an issue in such a comparison the document in itself does not introduce or address security considerations. Acknowledgements This document is the outcome of discussions within the PPVPN L2 VPN design team. The design team includes M Lassere, V Kompella, J Heinanen, K Kompella, E Rosen, M Borden, L Andersson, P Menezes, H Ould-Brahim and W Augustyn. Authors' Contact Loa Andersson Utfors AB R…sundav„gen 12, PO Box 525 SE-169 29 Solna, Sweden phone: +46 8 5270 5038 loa.andersson@utfors.se References [rfc2026] Bradner, S. "The Internet Standards Process -- Revision 3", rfc 2026, October 1996. [rfc2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", rfc 2119, March 1997. [TERM] Andersson, L. and Madsen T. "VPN Terminology", draft-andersson- ppvpn-terminology-01.txt", Work in Progress, Internet Draft, Jun 2002. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02 Andersson Expires December 2002 [Page 23] [L3-FRMWRK] Callon, R. et.al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", , Work in Progress, Internet Draft, February 2002. [L2TP] Elwin, E. and Gowda, N. "L2TP Extensions for PPVPN", , Work in Progress, Internet draft, November 2001. [DTLS] Kompella, K et.al "Decoupled Virtual Private LAN Services" draft- kompella-ppvpn-dtls-01.txt, Work in progress, Internet Draft, November 2001. [LPE]Ould-Brahim, H et.al "VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture" draft-ouldbrahim-l2vpn- lpe-01.txt, Work in Progress, Internet Draft, November 2001. [L2VPN-REQ] Augustyn, W. et al "Requirements for Layer 2 Virtual Private Network Services (L2VPN)", draft-augustyn-ppvpn-l2vpn- requirements-00.txt, Work in progress, Internet Draft, Jun 2002 [APPL-GUIDE] Sumimoto, J. et al "Guidelines of Applicability Statements for PPVPNs", draft-ietf-ppvpn-applicability-guidelines-00.txt, Work in progress, Internet Draft, Jun 2002 This document expires on 8 August 2002. INTERNET-DRAFT draft-andersson-ppvpn-metrics-00.txt 28.06.02