Internet DRAFT - draft-zhuang-opswg-netvpn-model-considerations

draft-zhuang-opswg-netvpn-model-considerations







Network Working Group                                          S. Zhuang
Internet-Draft                                                    Huawei
Intended status: Informational                          October 19, 2015
Expires: April 21, 2016


          Considerations on Layered Network VPN Service Model
           draft-zhuang-opswg-netvpn-model-considerations-00

Abstract

   VPN is one typical service provided by carrier IP network.  Network
   VPN service model can provide the northbound interface of network-
   level VPN service of the controller to try to simplify the VPN
   provision without involving too much details of VPN implementation on
   the device.  This document gives exploratory description about the
   requirement of network-level VPN service and how to define the data
   model which will provide the guidance for the future definition of
   the concrete data model.

Requirements Language

   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].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 21, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Zhuang                   Expires April 21, 2016                 [Page 1]

Internet-Draft     Considerations on Network VPN Model      October 2015


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Consideration on VPN Service Model  . . . . . . . . . . . . .   4
   4.  Network VPN Service Models  . . . . . . . . . . . . . . . . .   5
     4.1.  VPN Instance  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Basic Parameters  . . . . . . . . . . . . . . . . . .   5
       4.1.2.  Enhanced Services . . . . . . . . . . . . . . . . . .   5
     4.2.  Access Side . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Basic Parameters  . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Enhanced Services . . . . . . . . . . . . . . . . . .   6
     4.3.  Network Side  . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.1.  Basic Parameters  . . . . . . . . . . . . . . . . . .   6
       4.3.2.  Enhanced Services . . . . . . . . . . . . . . . . . .   6
     4.4.  Design of Data Model  . . . . . . . . . . . . . . . . . .   6
   5.  Network L3VPN Service Models  . . . . . . . . . . . . . . . .   7
     5.1.  Augment of VPN Instance . . . . . . . . . . . . . . . . .   7
     5.2.  Augment of Access Side  . . . . . . . . . . . . . . . . .   8
       5.2.1.  Basic Parameters  . . . . . . . . . . . . . . . . . .   8
       5.2.2.  Enhanced Services . . . . . . . . . . . . . . . . . .   8
     5.3.  Augment of Network Side . . . . . . . . . . . . . . . . .   8
       5.3.1.  Basic Parameters  . . . . . . . . . . . . . . . . . .   8
       5.3.2.  Enhanced Services . . . . . . . . . . . . . . . . . .   8
     5.4.  Design of Data Model  . . . . . . . . . . . . . . . . . .   8
   6.  Network L2VPN Service Models  . . . . . . . . . . . . . . . .   9
     6.1.  Network L2VPN Service Model . . . . . . . . . . . . . . .   9
       6.1.1.  Augment of VPN Instance . . . . . . . . . . . . . . .   9
       6.1.2.  Augment of Access Side  . . . . . . . . . . . . . . .  10
       6.1.3.  Augment of Network Side . . . . . . . . . . . . . . .  10
       6.1.4.  Design of Data Model  . . . . . . . . . . . . . . . .  10
     6.2.  P2P Network L2VPN Service Model . . . . . . . . . . . . .  11
     6.3.  MP2MP Network L2VPN Service Model . . . . . . . . . . . .  11
       6.3.1.  Augment of VPN Instance . . . . . . . . . . . . . . .  12
       6.3.2.  Augment of Access Side  . . . . . . . . . . . . . . .  12
       6.3.3.  Augment of Network Side . . . . . . . . . . . . . . .  12
       6.3.4.  Design of Data Model  . . . . . . . . . . . . . . . .  13
   7.  Pre-configuration and Operational Data  . . . . . . . . . . .  13



Zhuang                   Expires April 21, 2016                 [Page 2]

Internet-Draft     Considerations on Network VPN Model      October 2015


   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   VPN is one typical service provided by carrier IP network which is
   widely deployed to bear different service traffic.  There are all
   kinds of VPN technologies implemented by the device such as
   L3VPN[RFC4364], MVPN[RFC6514],EVPN[RFC7432], BGP-based VPLS[RFC4761],
   and BGP-AD-based VPLS[RFC6074] etc.  Owing to difference of these VPN
   technologies and too much technical details of VPN involving BGP,
   IGP, MPLS, Tunnel, etc., it proposes many challenges for operation
   and management of VPN services.  As the controller is introduced in
   the network, network VPN service model can be introduced to try to
   simplify the VPN provision without involving too much details of VPN
   implementation on the device.  Network VPN service model can provide
   the northbound interface of network-level VPN service of the
   controller which can be converted by the controller to the device-
   level configuration.

   This document gives exploratory description about the requirement of
   network-level VPN service and how to define the data model which will
   provide the guidance for the future definition of the concrete data
   model.

2.  Terminology and Definitions

   AC: Attachment Circuit

   CE: Customer Edge, It is an edge device on a customer network,
   providing interfaces that are directly connected to the Service
   Provider (SP) network.  A CE can be a router, a switch, or a host.
   Usually, a CE neither senses the VPN nor supports MPLS.

   PE: Provider Edge, It is an edge device on an SP network.  A PE is
   directly connected to the CE.  On an MPLS network, PEs process all
   VPN services.  Therefore, the requirements on the performance of PEs
   are rather high.

   PW: Pseudo Wire

   L2VPN: Layer 2 Virtual Private Network




Zhuang                   Expires April 21, 2016                 [Page 3]

Internet-Draft     Considerations on Network VPN Model      October 2015


   L3VPN: Layer 3 Virtual Private Network

   VPN: Virtual Private Network

   VRF: VPN Routing and Forwarding table

3.  Consideration on VPN Service Model

   The network VPN service model is defined to satisfy the common
   requirement of most VPN services, the model is not a configuration
   model to be used directly on network elements.  This model provides
   an abstracted view of the VPN service configuration components.  It
   will be used for a controller to take this as an input and use
   specific configurations models to configure the different network
   elements to deliver the VPN service.

   The controller will process the data model of the VPN service and
   finally notify the network device to deliver the VPN service.

   Now there are several device-level data models about VPN are proposed
   in IETF.  [I-D.shah-bess-l2vpn-yang] describes a YANG data model for
   Layer 2 VPN services over MPLS networks.  [I-D.li-bess-l3vpn-yang]
   defines a YANG data model that can be used to configure and manage
   L3VPN (BGP/MPLS IP VPN).  [I-D.brissette-bess-evpn-yang] describes a
   YANG data model for Ethernet VPN services.  The operators are
   normally interested in common attributes of different VPN
   technologies without involving too much technical details of VPN
   technologies implemented on the device.  The generic network VPN data
   model is made up of these common properties and the properties which
   the network-level VPN need such as the group PEs on which the VPN
   instance distributed.

   Owing to different requirements and technical background of the users
   of VPN services, the input of the network VPN service model shows the
   wide diversity.  For instance, users of network VPN service do not
   have to care about it is L3VPN, L2VPN or EVPN that is actually being
   used.  And a common end identification of ACs of VPN services only
   needs to be designated instead of concrete IP or MAC addresses.
   These concrete identifications can be allocated by a controller
   automatically.  On the other hand, some users prefer to designate the
   exact VPN such as L3VPN in the case IP address for the identification
   of ACs should be designated instead of allocated by the controller.
   Owing to the different characteristics of L3VPN, L2VPN and EVPN,
   there should be different augment based on the base network VPN
   service models.

   The relationship of network VPN service model, network L2VPN service
   model and network L3VPN service model is shown in the following



Zhuang                   Expires April 21, 2016                 [Page 4]

Internet-Draft     Considerations on Network VPN Model      October 2015


   figure.  Network EVPN service model will be described in the future
   version.

                              +----------------------+
                              | Network VPN service  |  o: augment
                              +----------------------+
                               o                   o
                              /                     \
                             /                       \
                 +-----------------------+ +-----------------------+
                 | Network L2VPN service | | Network L3VPN service |
                 +-----------------------+ +-----------------------+
                    o                   o
                   /                     \
                  /                       \
      +---------------------------+ +-----------------------------+
      | P2P Network L2VPN service | | MP2MP Network L2VPN service |
      +---------------------------+ +-----------------------------+
          Figure 1: Relationship of Network VPN Service Model,
         Network L2VPN Service Model, Network L3VPN Service Model


4.  Network VPN Service Models

   The Network VPN Service Model can be mapped to any VPN, and the
   parameters of L3VPN and L2VPN will be automatically generated by the
   controller when convert the network-level service model to the
   device-level configuration.  The common properties of network VPN
   services can be divided into three parts: VPN instance level, access
   side of VPN instance, network side of VPN instance.

4.1.  VPN Instance

4.1.1.  Basic Parameters

   The basic parameters of VPN instance should includes the id, name,
   admin-status and operate-status etc.

4.1.2.  Enhanced Services

4.1.2.1.  Protection

   Protection parameters should be defined to provide the high-
   availability service for the VPN instance.  The protect-policy can
   specify the protect-type for Network VPN Service.






Zhuang                   Expires April 21, 2016                 [Page 5]

Internet-Draft     Considerations on Network VPN Model      October 2015


4.2.  Access Side

4.2.1.  Basic Parameters

   Access side needs to provide a set of ACs.  These ACs need to be
   specified by explicit way.  The parameters of AC should include id,
   name, ne-id, admin-status, operate-status, role, etc.

4.2.2.  Enhanced Services

4.2.2.1.  QoS Service

   For a specific AC in the VPN, It needs to ensure that the traffic
   flow in accordance with the SLA between PEs and CEs.  The CAR of the
   QoS services policy can be carried out in accordance with the
   specified bandwidth limit.  For complex QoS process, it may need to
   specify additional parameters through QoS profile.

4.3.  Network Side

4.3.1.  Basic Parameters

   Network side needs to provide a set of PEs, and needs to establish
   the relationship between the PEs for VPN.

   Network side needs to provide the type of inter-connection: Mesh Full
   or Hub-Spoke.  This needs to specify the role of PEs, especially for
   the VPN Hub-Spoke type, the PEs need to be specified as Hub PE or
   Spoke PE.

   Through the above information, the controller can automatically
   generate the configuration data of PEs of the network side.

4.3.2.  Enhanced Services

4.3.2.1.  Tunnel Service

   Tunnel is an important service to bear the traffic of VPN instance
   with different service requirements in the network side.  The
   parameters of tunnel service should include the tunnel type, tunnel
   mode, protection policy, etc.

4.4.  Design of Data Model

   Following is a simplified tree representation of the data model for
   Network VPN Service configuration.





Zhuang                   Expires April 21, 2016                 [Page 6]

Internet-Draft     Considerations on Network VPN Model      October 2015


   module: net-vpn
      +--rw service
         +--rw vpn-instances
            +--rw vpn-instance* [id]
               +--rw id
               +--rw name
               +--rw admin-status?
               +--rw operate-status?
               +--rw acs
               |  +--rw ac* [id]
               |     +--rw id
               |     +--ro name?
               |     +--rw ne-id
               |     +--rw admin-status?
               |     +--rw operate-status?
               |     +--rw role?
               |     +--rw qos-policy ?
               +--rw networks
               |  +--rw node* [ne-id]
               |     +--rw ne-id
               |     +--ro name?
               +--rw protect-policy
               |  +--rw protect-type?
               |  +--rw revertive-type?
               |  +--rw wtr?
               +--rw tunnel-service
                  +--rw type?
                  +--rw mode?
                  +--rw protect-policy
                     +--rw protect-type?
                     +--rw revertive-type?
                     +--rw wtr?


5.  Network L3VPN Service Models

   Network L3VPN Service Model can be extended on the basis of the
   Network VPN Service Model which will introduce more Layer 3
   parameters in the VPN instance level, access side and network side.
   It will be used by a controller to be converted to configuration data
   of multiple network elements to deliver the L3VPN service.

5.1.  Augment of VPN Instance

   Until now there is no more augment to be defined.  It needs to be
   discussed.





Zhuang                   Expires April 21, 2016                 [Page 7]

Internet-Draft     Considerations on Network VPN Model      October 2015


5.2.  Augment of Access Side

5.2.1.  Basic Parameters

   AC of Network L3VPN service model needs to use IPv4 or IPv6 addresses
   to identify.  There can be a variety of scenarios that access side
   can support IPv4 access, IPv6 access, IPv6 and IPv4 mixed access and
   other scenarios.

5.2.2.  Enhanced Services

5.2.2.1.  Routing Service

   L3VPN needs to obtain the routes of the access side.  It needs to
   define the parameters required to obtain routing information,
   including routing protocol types used between PE-CE, etc.  Routing
   protocols currently in use between PEs and CEs can be OSPF/ISIS/BGP.
   Static routes can also be used.  When using static routes, parameters
   of a specified route must be specified.

5.3.  Augment of Network Side

5.3.1.  Basic Parameters

   Until now there is no more augment to be defined.  It needs to be
   discussed.

5.3.2.  Enhanced Services

5.3.2.1.  Routing Service

   In the network side routes of L3VPNs needs to be redistributed among
   different L3VPN instances, including Intranet, extranet, etc.. It
   needs to define the route-distribution-policy between different VPN
   instances.

   Backup of VPN routes, called VPN fast re-route (FRR), is also an
   important feature for the high-availability of network side.  It
   should also be specified in the model.

5.4.  Design of Data Model

   Following is a simplified tree representation of the data model for
   Network L3VPN Service configuration.







Zhuang                   Expires April 21, 2016                 [Page 8]

Internet-Draft     Considerations on Network VPN Model      October 2015


   module: net-l3vpn
   augment /net-vpn:service/net-vpn:vpn-instances/
            net-vpn:vpn-instance/net-vpn:acs/net-vpn:ac:
      +--rw ip-address?
      +--rw mask-length?
      +--rw protocols?
      +--rw static-routes
         +--rw static-route* [ip-prefix mask-length]
            +--rw ip-prefix
            +--rw mask-length
            +--rw next-hop?
            +--rw preference?

   augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance:
      +--rw service-type?
      +--vpn-attributes*[node]
          +--node
          +--rw rt-type
          +--import-rt-value
          +--export-rt-value
          +--vpn-frr

6.  Network L2VPN Service Models

   Network L2VPN Service Model can be extended on the basis of the
   Network VPN Service Model which will introduce more Layer 2
   parameters in the VPN instance level, access side and network side.
   It will be used by a controller to be converted to configuration data
   of multiple network elements to deliver the L2VPN service.

6.1.  Network L2VPN Service Model

6.1.1.  Augment of VPN Instance

6.1.1.1.  Basic Parameters

   Until now there is no more augment to be defined.  It needs to be
   discussed.

6.1.1.2.  Enhanced Services

6.1.1.2.1.  Redundancy Group

   The redundancy-group is a generic redundancy construct which can hold
   primary and backup members of AC and PWs.  This flexibility permits
   combinations of:

   o  primary and backup AC



Zhuang                   Expires April 21, 2016                 [Page 9]

Internet-Draft     Considerations on Network VPN Model      October 2015


   o  primary and backup PW

   o  primary AC and backup PW

   o  primary PW and backup AC

6.1.2.  Augment of Access Side

6.1.2.1.  Basic Parameters

   AC of Network L2VPN service model needs to use additional VLAN ID to
   identify.

6.1.2.2.  Enhanced Services

6.1.2.2.1.  L2 Service

   There can be flexible L2 access services augmented to specify the
   following l2-access parameters:

   o  VLAN access mode: Bundle mode or independent mode

   o  A variety of operations of VLAN access: Swapping, Transition,
      Mapping etc.

   o  Role of VLAN access: E-Tree's root/leaf, etc.

   o  Multi-homing related Service.

6.1.3.  Augment of Network Side

6.1.3.1.  Basic Parameters

   In the network side, Network L2VPN Service model should be able to
   specify a list of PWs of the given service instance.  Each entry of
   the PW can be specified by the pw id, ingress network element id,
   egress network element id, etc.

6.1.4.  Design of Data Model

   Following is a simplified tree representation of the data model for
   Network L2VPN Service configuration.









Zhuang                   Expires April 21, 2016                [Page 10]

Internet-Draft     Considerations on Network VPN Model      October 2015


   module: net-l2vpn
   augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance:
      +--rw l2vpn
         +--rw pw-trails
         |  +--rw pw-trail* [id]
         |     +--rw id
         |     +--rw role?
         |     +--rw pw-lists
         |        +--rw pw-list* [id]
         |           +--rw id
         |           +--rw ingress-ne-id?
         |           +--rw egress-ne-id?
         |           +--rw tunnels
         |              +--rw tunnel* [tunnel-id]
         |                 +--rw tunnel-id?
         +--rw redundancy-groups
            +--rw redundancy-group* [name]

   augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance/
            net-vpn:acs/net-vpn:ac:
      +--rw l2-access
         +--rw access-type?
         +--rw dot1q-vlan-bitmap?
         +--rw qinq-svlan-bitmap?
         +--rw qinq-cvlan-bitmap?
         +--rw access-action?
         +--rw action-vlan-id?


6.2.  P2P Network L2VPN Service Model

   P2P Network L2VPN Service Model can be extended on the basis of the
   Network VPN Service Model.  It can be used by a controller to be
   converted to configuration data of multiple network elements to
   deliver the VPWS service.  Until now there is no more augment to be
   defined.  It needs to be discussed.

6.3.  MP2MP Network L2VPN Service Model

   MP2MP Network L2VPN Service Model can be extended on the basis of the
   Network VPN Service Model.  It can be used by a controller to be
   converted to configuration data of multiple network elements to
   deliver the VPLS service.








Zhuang                   Expires April 21, 2016                [Page 11]

Internet-Draft     Considerations on Network VPN Model      October 2015


6.3.1.  Augment of VPN Instance

6.3.1.1.  Basic Parameters

   Until now there is no more augment to be defined.  It needs to be
   discussed.

6.3.1.2.  Enhanced Services

   Until now there is no more augment to be defined.  It needs to be
   discussed.

6.3.2.  Augment of Access Side

6.3.2.1.  Basic Parameters

   Until now there is no more augment to be defined.  It needs to be
   discussed.

6.3.2.2.  Enhanced Services

6.3.2.2.1.  Split Horizon Group

   This split-horizon forwarding behavior is typical in VPLS instance.
   Split Horizon Group can define a group to prevent the traffic from
   specific member to be forwarded to other members in the same group.
   The augmented parameter should be introduced to specify the split
   horizon group the specific AC belongs to.

6.3.3.  Augment of Network Side

6.3.3.1.  Basic Parameters

   Until now there is no more augment to be defined.  It needs to be
   discussed.

6.3.3.2.  Enhanced Services

6.3.3.2.1.  Network Hierarchy

   H-VPLS can provide hierarchy of network service.  In a basic H-VPLS
   model, PEs can be classified into the types such as UPE and SPE.  The
   augmented parameter should be introduced to specify these type of PEs
   for the purpose of H-VPLS.







Zhuang                   Expires April 21, 2016                [Page 12]

Internet-Draft     Considerations on Network VPN Model      October 2015


6.3.3.2.2.  Split Horizon Group

   This split-horizon forwarding behavior is typical in VPLS instance.
   Split Horizon Group can define a group to prevent the traffic from
   specific member to be forwarded to other members in the same group.
   The augmented parameter should be introduced to specify the split
   horizon group the specific PW belongs to.

6.3.3.2.3.  PBB VPLS

   It will be defined in the future version of the draft.

6.3.4.  Design of Data Model

   Following is a simplified tree representation of the data model for
   Network MP2MP L2VPN Service configuration.

   module: net-mp2mp-l2vpn

   augment /net-l2vpn:service/net-l2vpn:vpn-instances/
            net-l2vpn:vpn-instance/net-l2vpn:pw-trails/
            net-l2vpn:pw-trail/:
      +--rw split-horizon-group? //Identify a split horizon group

   augment /net-l2vpn:service/net-l2vpn:vpn-instances/
            net-l2vpn:vpn-instance/net-l2vpn:networks/
            net-l2vpn:node:
      +--rw role-in-hierarchy?        //0: UPE; 1: SPE

   augment /net-l2vpn:service/net-l2vpn:vpn-instances/
            net-l2vpn:vpn-instance/net-l2vpn:acs/net-l2vpn:ac:
      +--rw split-horizon-group? //Identify a split horizon group


7.  Pre-configuration and Operational Data

   This document focuses on the design of the data model of the service
   configuration which the business users care about.  Actually system
   administrators have to configure the pre-configuration data to help
   the controller convert the network service configuration to the
   device-level configuration.  The typical of pre-configuration of
   network VPN service models may provide the policy of the models
   conversion and the resources used for conversion.  For example the
   MP2MP Network L2VPN service model can be implemented in LDP-based
   VPLS, BGP-based VPLS, or BGP-AD-based VPLS mode.  The pre-
   configuration can define the policy to select the implementation mode
   for specific MP2MP Network L2VPN service model.  On the other hand,
   for the BGP-based VPLS, Route Targets are needed to be allocated



Zhuang                   Expires April 21, 2016                [Page 13]

Internet-Draft     Considerations on Network VPN Model      October 2015


   automatically by the controller.  The pre-configuration can define
   the resource pool of Route Target for allocation.

   It's challenging to define the operational data of network service
   data model because the normal users and the system administrators
   have different perspective.  The business users maybe care only about
   the limited maintenance information but the system administrators
   need to know more details.  For the MP2MP Network L2VPN service
   model, the state information of the ACs and PWs may be sufficient to
   the business users but system administrators maybe need to know more
   implementation details of network VPN service models such as the
   automatically allocated router targets, etc.  There should be further
   discussion.

8.  Contributors

   The following people have substantially contributed to the design of
   network VPN service model of this document:

   Li Zhang
   Huawei
   Email: monica.zhangli@huawei.com

9.  IANA Considerations

   This document makes no request of IANA.

10.  Security Considerations

   This document does not introduce new security threat.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

11.2.  Informative References

   [I-D.brissette-bess-evpn-yang]
              Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh,
              T., Hussain, I., and J. Rabadan, "Yang Data Model for
              EVPN", draft-brissette-bess-evpn-yang-00 (work in
              progress), October 2015.




Zhuang                   Expires April 21, 2016                [Page 14]

Internet-Draft     Considerations on Network VPN Model      October 2015


   [I-D.ietf-l3sm-l3vpn-service-model]
              Litkowski, S., Shakir, R., Tomotaki, L., and K. D'Souza,
              "YANG Data Model for L3VPN service delivery", draft-ietf-
              l3sm-l3vpn-service-model-01 (work in progress), August
              2015.

   [I-D.ietf-rtgwg-mrt-frr-architecture]
              Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
              A., Tantsura, J., and R. White, "An Architecture for IP/
              LDP Fast-Reroute Using Maximally Redundant Trees", draft-
              ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
              October 2015.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and r. rjs@rob.sh, "Segment Routing Architecture", draft-
              ietf-spring-segment-routing-06 (work in progress), October
              2015.

   [I-D.li-bess-l3vpn-yang]
              Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B.
              Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess-
              l3vpn-yang-00 (work in progress), October 2015.

   [I-D.shah-bess-l2vpn-yang]
              Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z.,
              Zhuang, S., Wang, H., Chen, H., Bocci, M., Hardwick, J.,
              Esale, S., Tiruveedhula, K., Singh, T., Hussain, I., Wen,
              B., Walker, J., Delregno, N., Jalil, L., and M. Joecylyn,
              "YANG Data Model for MPLS-based L2VPN", draft-shah-bess-
              l2vpn-yang-00 (work in progress), October 2015.

   [RFC4110]  Callon, R. and M. Suzuki, "A Framework for Layer 3
              Provider-Provisioned Virtual Private Networks (PPVPNs)",
              RFC 4110, DOI 10.17487/RFC4110, July 2005,
              <http://www.rfc-editor.org/info/rfc4110>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <http://www.rfc-editor.org/info/rfc4364>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.






Zhuang                   Expires April 21, 2016                [Page 15]

Internet-Draft     Considerations on Network VPN Model      October 2015


   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
              "Provisioning, Auto-Discovery, and Signaling in Layer 2
              Virtual Private Networks (L2VPNs)", RFC 6074,
              DOI 10.17487/RFC6074, January 2011,
              <http://www.rfc-editor.org/info/rfc6074>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
              2015, <http://www.rfc-editor.org/info/rfc7432>.

Author's Address

   Shunwan Zhuang
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zhuangshunwan@huawei.com


























Zhuang                   Expires April 21, 2016                [Page 16]