Internet Engineering Task Force                              J. Sumimoto
INTERNET-DRAFT                                                       NTT
                                                               M. Carugi
Expires December 2003                                    Nortel Networks
                                                            (Co-editors)

                                                            J. De Clercq
                                                                 Alcatel
                                                            A. Nagarajan
                                                              Consultant
                                                               M. Suzuki
                                                                     NTT

                                                           June 27, 2003

           Guidelines of Applicability Statements for PPVPNs
           <draft-ietf-l3vpn-applicability-guidelines-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of 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.

Abstract

   This document plays a role of guidelines to assist development of
   applicability statements for each specific Layer 2 and Layer 3 PPVPN
   approach. It provides a check-list which consists of metrics, each of
   which is intended to clearly point out what must be evaluated and
   written in each approach specific applicability statement document.

1. Introduction



Sumimoto, et al.         Expires December 2003                  [Page 1]


INTERNET-DRAFT                                             June 27, 2003


   The term Provider Provisioned Virtual Private Network (PPVPN) refers
   to Virtual Private Networks (VPNs) for which the service provider
   participates in management and provisioning of the VPN. PPVPNs can be
   classified into various PPVPN types based on their characteristics,
   and requirements for PPVPNs are described in three separate
   documents, [GEN REQTS], [L3 REQTS], and [L2 REQTS]. This document
   extracts metrics directly relating to protocols/mechanisms out of
   provider/service/engineering requirements for PPVPNs described in the
   three requirements documents so as to make approach specific
   applicability statements significant. The extracted metrics in this
   document form a check-list, each of which is intended to clearly
   point out what must be evaluated and written in each approach
   specific applicability statement document. Detailed description with
   regard to the metrics is out of scope of this document.
   Section 2 reviews taxonomy of PPVPN types for which metrics are
   listed in this document. Section 3 provides list and outline of
   metrics. Section 4 is for security considerations, Section 5 is for
   acknowledgement and section 6 is for references.

2. Taxonomy of PPVPNs

   The terminology used in this document is defined in [TERMINOLOGY].


                             PPVPN
               ________________|__________________
               |                                 |
             Layer 2                           Layer 3
         ______|_____                     _______|________
         |          |                     |              |
        P2P        P2M                PE-based       CE-based
       (VPWS)    ___|______        _______|_____         |
                 |        |        |           |         |
               VPLS      IPLS     RFC2547   Virtual    IPsec
                                  Style     Router

                         Figure. 2.1 PPVPN taxonomy


   The figure above presents taxonomy of PPVPN approaches. Note that
   CE-based Layer 2 PPVPNs may also be further classified as point-to-
   point (P2P) or point-to-multipoint (P2M), and P2M PPVPNs may also be
   further classified as Virtual Private LAN Service (VPLS) and IP-only
   LAN-like Service (IPLS). Definitions for layer 3 PPVPNs can be
   obtained from [L3 FWK] and definitions for layer 2 PPVPNs can be
   obtained from [L2 FWK].

3. List and outline of metrics for evaluating each PPVPN approach



Sumimoto, et al.         Expires December 2003                  [Page 2]


INTERNET-DRAFT                                             June 27, 2003


   This section provides list and outline of metrics generic to L3 and
   L2 PPVPN approaches (in Section 3.1), specific to L3 PPVPN approaches
   (in Section 3.2) and specific to L2 PPVPN approaches (in Section
   3.3). Each L3 PPVPN approach is to be evaluated by using both generic
   and L3 specific metrics. Similarly, each L2 PPVPN approach is to be
   evaluated by using both generic and L2 specific metrics. In this
   document, AS stands for Applicability Statements.

3.1 Generic metrics

   This section provides metrics generic to layer 3 and layer 2 PPVPN
   approaches.

   3.1.1 Isolated exchange of routing and data information

   Each specific AS document must clarify whether and how the following
   attributes are implemented by the concerned PPVPN approach.

    - Isolated data forwarding (mandatory)

    - Isolated routing (i.e. constrained distribution of reachability to
      only VPN sites)
      (Internal topology of VPN should not be visible to the shared
       public network (Internet))

   3.1.2 Security

   Each specific AS document must clarify whether and how the following
   attributes of user security are supported by the concerned PPVPN
   approach.

    - Confidentiality

    - Integrity

    - Authentication

    - Replay attack prevention

   Additionally, each specific AS document must clarify how the
   following security attributes with regard to setup/operation are
   protected by the concerned PPVPN approach.

    - Protocol attacks

    - Unauthorized access

    - Tampering with signaling



Sumimoto, et al.         Expires December 2003                  [Page 3]


INTERNET-DRAFT                                             June 27, 2003


   3.1.3 Tunneling

   Each specific AS document must clarify the following attributes.

    - Kind of supported tunneling techniques

    - Tunnel termination points

   3.1.4 QoS

   Each specific AS document must clarify if the following types of QoS
   are supported or not, and how they are supported.


    - Intserv/RSVP (Customer usage/Provider usage)

    - Diffserv (Customer usage/Provider usage)

    - Point to point

    - Point to cloud

   3.1.5 Auto-discovery

   Each specific AS document must clarify

    - Whether any mechanism are supported or not

      If supported, it must also clarify the following attributes.

    - Kind of mechanism

    - What is discovered by the mechanism

    - Information exchanged by the mechanism

   3.1.6 Scalability

   With regard to each of the following factors, each specific AS
   document must clarify (1) what resource is pressed by the factor
   (e.g. VFI's table size) and (2) how (in what order) is the resource
   pressed? (E.g. O(n) or O(n^2) or ...). VFI stands for Virtual
   Forwarding Instance, and VSI stands for Virtual Switching Instance
   (for more detail, see framework documents).

    - Number of VPNs
      (Especially, influence toward VFI/VSI's table size / number of
       tunnels should be considered.)



Sumimoto, et al.         Expires December 2003                  [Page 4]


INTERNET-DRAFT                                             June 27, 2003


    - Number of sites
      (Especially, influence toward VFI/VSI's table size / number of
       tunnels should be considered.)

    - Number of routes per VPN

    - Rate of configuration changes / impact of adding new site
      (Especially, influence toward increase of controlling traffic /
       average convergence time should be considered.)

    - Number of users per VPN

    - Number of addresses per VPN

    - Number of PEs and/or CEs

    - Number of VRFs/VRs and interfaces per PE (for only PE-based L3 VPN
      approaches),
      (Especially, influence toward processing overhead of a PE should
       be considered.)

    - Number of tunnels

   3.1.7 Management

   Each specific AS document must clarify (1) whether each of the
   following aspects of management are supported or not by the concerned
   PPVPN approach, and (2) how they are supported.

    - Configuration/Provisioning
      VPN membership, tunnels, network access, routing protocols, etc.

    - Performance/SLA
      Monitoring/Accounting states and statistics.

    - Security
      Access control, authentication, etc.

    - Fault
      Detection, localization, and corrective actions.

    - Customer Management
      Capabilities of customers to view the topology, operational state,
      order status, and other parameters associated with their VPN

   3.1.8 Traffic types

   Each specific AS document must clarify whether and how the following



Sumimoto, et al.         Expires December 2003                  [Page 5]


INTERNET-DRAFT                                             June 27, 2003


   types of traffic are supported or not.

    - Unicast or point-to-point

    - Multicast or point-to-multipoint

    - Broadcast

   3.1.9 Temporary access

   Besides permanent access which is mandatory to all PPVPN approach,
   each specific AS document must clarify (1) whether supported or not,
   and (2) how to support,

    - Temporary access

   3.1.10 Migration impacts

   Each specific AS document must clarify

    - Functions required to be added to legacy devices from the
      customers' and providers' point of view.

   3.1.11 Interworking

   Interworking scenarios among different solutions providing PPVPN
   services is highly desirable. If any constraints exist in a PPVPN
   approach, the corresponding specific AS document must show the
   constraints and their influence.

3.2 Metrics specific to L3 PPVPN approaches

   This section provides metrics specific to L3 PPVPN approaches. Each
   specific L3 PPVPN approach must be checked by these L3 specific
   metrics as well as generic metrics provided in the former sections.

   3.2.1 Addressing

   Each specific AS document must clarify whether overlapping customer
   IP addresses in different VPNs are supported or not.

   3.2.2 IP Routing Protocol Support for Customer

   At least the following protocols must be supported between CE and PE
   routers, or between CE routers: static routing, IGP, such as RIP,
   OSPF, IS-IS, and BGP. If there exists any restriction in a PPVPN
   approach, it must be described in the specific AS document concerning
   the PPVPN approach.



Sumimoto, et al.         Expires December 2003                  [Page 6]


INTERNET-DRAFT                                             June 27, 2003


   3.2.3 Core network requirements

   Each specific AS document must clarify the following attributes of
   concerned PPVPN approach.

    - Routing protocols applicable to SP network routing

    - Core router awareness of mechanisms used

3.3 Metrics specific to L2 PPVPN approaches

   This section provides metrics specific to L2 PPVPN approaches. Each
   specific L2 PPVPN approach must be checked by these L2 specific
   metrics as well as generic metrics provided in the former sections.
   VPLS stands for Virtual Private LAN Service (for more detail, see [L2
   FWK]).

   3.3.1 Scope/Accuracy of Emulation

   Each specific AS document must clarify the following attributes of
   concerned PPVPN approach.

    - Difference between L2 VPN protocol and specification at customer
      interface and existing native protocols and specification (if
      exists)

   3.3.2 Addressing

   Each specific AS document must clarify

    - Whether overlapping customer L2 addresses in different VPNs
      are supported or not

    - Whether overlapping VLAN IDs for different customer are supported
      or not (in case of VPLS supporting VLANs)

   3.3.3 Loop Prevention of L2 topology

   Each specific AS document must clarify

    - Whether any mechanism are supported or not. (Especially, is STP
      supported?)

      If any mechanism supported, it must also clarify the following
      attributes.

    - Kind/scope of the mechanism. (Especially, is STP supported?
      Is Split horizon scheme over mesh topology adopted?)



Sumimoto, et al.         Expires December 2003                  [Page 7]


INTERNET-DRAFT                                             June 27, 2003


   3.3.4 Packet re-ordering

   Each specific AS document must clarify the following attributes.

    - Possibility of packet re-ordering

    - Influence of packet re-ordering

   3.3.5 Minimum MTU

   Each specific AS document must clarify the following attributes.

    - Support of MTU specified for the layer 2 technology
      (including consistency with inserting VLAN tag)

    - Guarantee of prohibition of frame fragmentation

   3.3.6 Support for MAC Services (only for VPLS)

   Each specific AS document must clarify whether MAC services (see the
   following examples) are supported or not by the concerned PPVPN
   approach.

    - Filtering of frames

    - Flooding

    - Creation of address table

    - Aging of address table

   If any constraints exist in a PPVPN approach, the corresponding
   specific AS document must show the constraints and their influence.

   3.3.7 Scalability

   L2 specific scalability metrics  are listed in this section. For
   generic scalability metrics, see section 3.1.6.

   Each specific AS document must clarify scalability concern specific
   to L2 VPN control protocol including signaling. Especially,
   scalability concern caused by use of STP must be clarified in case of
   VPLS.

4. Security considerations

   There are no additional security considerations besides those already
   described in this document.



Sumimoto, et al.         Expires December 2003                  [Page 8]


INTERNET-DRAFT                                             June 27, 2003


5. Acknowledgments

   The authors of this document would like to acknowledge the
   suggestions and comments received from the entire Layer 3
   Applicability Statement Design Team formed in the ppvpn WG. Besides
   the authors, the members of the design team include Luyuan Fang, Paul
   Knight, Dave McDysan, Thomas Nadeau, Olivier Paridaens, Yakov
   Rekhter, Eric Rosen, Chandru Sargor, Benson Schliesser, Cliff Wang
   and Rick Wilder.

6.  References

6.1 Normative References

   [GEN REQTS] Nagarajan, A., "Generic Requirements for Provider
       Provisioned VPN," Work in Progress.

   [L3 REQTS] Carugi, M. et al., "Service Requirements for Provider
       Provisioned Virtual Private Networks," work in progress.

   [L2 REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements
       for Layer 2 Provider Provisioned Virtual Private Networks", work
       in progress

   [TERMINOLOGY] Andersson, L., Madsen, T., "PPVPN Terminology", work in
       progress.

6.2 Informative References

   [L3 FWK]  Callon, R. et al., "A Framework for Provider Provisioned
       Virtual Private Networks," work in progress.

   [L2 FWK] Andersson, L., et al., "L2VPN Framework", work in progress.

   [IPsecVPN AS] De Clercq, J. et al., "Applicability Statement for
       Provider Provisioned CE-based Virtual Private Networks using
       IPsec," work in progress.

   [VR AS] Nagarajan, A. et  al., "Applicability Statement for Virtual
       Router-based Layer 3 PPVPN approaches," work in progress.

   [2547BIS AS] Rosen, E. et al., "Applicability Statement for VPNs
       Based on rfc2547bis," work in progress.

7. Authors' address

      Junichi Sumimoto (Co-editor)
      NTT Information Sharing Platform Labs.



Sumimoto, et al.         Expires December 2003                  [Page 9]


INTERNET-DRAFT                                             June 27, 2003


      3-9-11, Midori-Cho
      Musashino-Shi,  Tokyo  180-8585  Japan
      Email: sumimoto.junichi@lab.ntt.co.jp

      Marco Carugi (Co-editor)
      Nortel Networks S.A.
      Parc d'activites de Magny - Les Jeunes Bois - Chateaufort
      78928 YVELINES Cedex - FRANCE
      Email: marco.carugi@nortelnetworks.com

      Jeremy De Clercq
      Alcatel
      Fr. Wellesplein 1, 2018 Antwerpen, Belgium
      Email: jeremy.de_clercq@alcatel.be

      Ananth Nagarajan
      Consultant
      Email: ananth@maoz.com

      Muneyoshi Suzuki
      NTT Information Sharing Platform Labs.
      3-9-11, Midori-cho,
      Musashino-shi, Tokyo 180-8585, Japan
      Email: suzuki.muneyoshi@lab.ntt.co.jp



























Sumimoto, et al.         Expires December 2003                 [Page 10]