Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8466

Proposed STD
Pages: 158
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: L2SM

A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery

Part 1 of 8, p. 1 to 10
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                            B. Wen
Request for Comments: 8466                                       Comcast
Category: Standards Track                               G. Fioccola, Ed.
ISSN: 2070-1721                                           Telecom Italia
                                                                  C. Xie
                                                           China Telecom
                                                                L. Jalil
                                                                 Verizon
                                                            October 2018


                         A YANG Data Model for
        Layer 2 Virtual Private Network (L2VPN) Service Delivery

Abstract

   This document defines a YANG data model that can be used to configure
   a Layer 2 provider-provisioned VPN service.  It is up to a management
   system to take this as an input and generate specific configuration
   models to configure the different network elements to deliver the
   service.  How this configuration of network elements is done is out
   of scope for this document.

   The YANG data model defined in this document includes support for
   point-to-point Virtual Private Wire Services (VPWSs) and multipoint
   Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
   using the Label Distribution Protocol (LDP) and the Border Gateway
   Protocol (BGP) as described in RFCs 4761 and 6624.

   The YANG data model defined in this document conforms to the Network
   Management Datastore Architecture defined in RFC 8342.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8466.

Top      ToC       Page 2 
Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Requirements Language . . . . . . . . . . . . . . . .   5
     1.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  The Layer 2 VPN Service Model . . . . . . . . . . . . . . . .   7
     3.1.  Layer 2 VPN Service Types . . . . . . . . . . . . . . . .   7
     3.2.  Layer 2 VPN Physical Network Topology . . . . . . . . . .   7
   4.  Service Data Model Usage  . . . . . . . . . . . . . . . . . .   9
   5.  Design of the Data Model  . . . . . . . . . . . . . . . . . .  11
     5.1.  Features and Augmentation . . . . . . . . . . . . . . . .  20
     5.2.  VPN Service Overview  . . . . . . . . . . . . . . . . . .  20
       5.2.1.  VPN Service Type  . . . . . . . . . . . . . . . . . .  21
       5.2.2.  VPN Service Topologies  . . . . . . . . . . . . . . .  22
         5.2.2.1.  Route Target Allocation . . . . . . . . . . . . .  22
         5.2.2.2.  Any-to-Any  . . . . . . . . . . . . . . . . . . .  22
         5.2.2.3.  Hub-and-Spoke . . . . . . . . . . . . . . . . . .  22
         5.2.2.4.  Hub-and-Spoke Disjoint  . . . . . . . . . . . . .  23
       5.2.3.  Cloud Access  . . . . . . . . . . . . . . . . . . . .  24
       5.2.4.  Extranet VPNs . . . . . . . . . . . . . . . . . . . .  27
       5.2.5.  Frame Delivery Service  . . . . . . . . . . . . . . .  28
     5.3.  Site Overview . . . . . . . . . . . . . . . . . . . . . .  30
       5.3.1.  Devices and Locations . . . . . . . . . . . . . . . .  31
       5.3.2.  Site Network Accesses . . . . . . . . . . . . . . . .  32
         5.3.2.1.  Bearer  . . . . . . . . . . . . . . . . . . . . .  33
         5.3.2.2.  Connection  . . . . . . . . . . . . . . . . . . .  33
     5.4.  Site Roles  . . . . . . . . . . . . . . . . . . . . . . .  38

Top      ToC       Page 3 
     5.5.  Site Belonging to Multiple VPNs . . . . . . . . . . . . .  38
       5.5.1.  Site VPN Flavors  . . . . . . . . . . . . . . . . . .  38
         5.5.1.1.  Single VPN Attachment: site-vpn-flavor-single . .  39
         5.5.1.2.  Multi-VPN Attachment: site-vpn-flavor-multi . . .  39
         5.5.1.3.  NNI: site-vpn-flavor-nni  . . . . . . . . . . . .  40
         5.5.1.4.  E2E: site-vpn-flavor-e2e  . . . . . . . . . . . .  41
       5.5.2.  Attaching a Site to a VPN . . . . . . . . . . . . . .  41
         5.5.2.1.  Referencing a VPN . . . . . . . . . . . . . . . .  41
         5.5.2.2.  VPN Policy  . . . . . . . . . . . . . . . . . . .  43
     5.6.  Deciding Where to Connect the Site  . . . . . . . . . . .  48
       5.6.1.  Constraint: Device  . . . . . . . . . . . . . . . . .  49
       5.6.2.  Constraint/Parameter: Site Location . . . . . . . . .  50
       5.6.3.  Constraint/Parameter: Access Type . . . . . . . . . .  51
       5.6.4.  Constraint: Access Diversity  . . . . . . . . . . . .  52
     5.7.  Route Distinguisher and Network Instance Allocation . . .  53
     5.8.  Site-Network-Access Availability  . . . . . . . . . . . .  54
     5.9.  SVC MTU . . . . . . . . . . . . . . . . . . . . . . . . .  56
     5.10. Service . . . . . . . . . . . . . . . . . . . . . . . . .  56
       5.10.1.  Bandwidth  . . . . . . . . . . . . . . . . . . . . .  56
       5.10.2.  QoS  . . . . . . . . . . . . . . . . . . . . . . . .  57
         5.10.2.1.  QoS Classification . . . . . . . . . . . . . . .  57
         5.10.2.2.  QoS Profile  . . . . . . . . . . . . . . . . . .  58
       5.10.3.  Support for BUM  . . . . . . . . . . . . . . . . . .  59
     5.11. Site Management . . . . . . . . . . . . . . . . . . . . .  60
     5.12. MAC Loop Protection . . . . . . . . . . . . . . . . . . .  61
     5.13. MAC Address Limit . . . . . . . . . . . . . . . . . . . .  61
     5.14. Enhanced VPN Features . . . . . . . . . . . . . . . . . .  62
       5.14.1.  Carriers' Carriers . . . . . . . . . . . . . . . . .  62
     5.15. External ID References  . . . . . . . . . . . . . . . . .  63
     5.16. Defining NNIs and Inter-AS Support  . . . . . . . . . . .  64
       5.16.1.  Defining an NNI with the Option A Flavor . . . . . .  66
       5.16.2.  Defining an NNI with the Option B Flavor . . . . . .  70
       5.16.3.  Defining an NNI with the Option C Flavor . . . . . .  73
     5.17. Applicability of L2SM in Inter-provider and Inter-domain
           Orchestration . . . . . . . . . . . . . . . . . . . . . .  74
   6.  Interaction with Other YANG Modules . . . . . . . . . . . . .  76
   7.  Service Model Usage Example . . . . . . . . . . . . . . . . .  77
   8.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  82
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 152
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 153
     11.1.  Normative References . . . . . . . . . . . . . . . . . . 153
     11.2.  Informative References . . . . . . . . . . . . . . . . . 155
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . . 157
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 158

Top      ToC       Page 4 
1.  Introduction

   This document defines a YANG data model for the Layer 2 VPN (L2VPN)
   service.  This model defines service configuration elements that can
   be used in communication protocols between customers and network
   operators.  Those elements can also be used as input to automated
   control and configuration applications and can generate specific
   configuration models to configure the different network elements to
   deliver the service.  How this configuration of network elements is
   done is out of scope for this document.

   Further discussion of the way that services are modeled in YANG and
   the relationship between "customer service models" like the one
   described in this document and configuration models can be found in
   [RFC8309] and [RFC8199].  Sections 4 and 6 also provide more
   information on how this service model could be used and how it fits
   into the overall modeling architecture.

   The YANG data model defined in this document includes support for
   point-to-point Virtual Private Wire Services (VPWSs) and multipoint
   Virtual Private LAN Services (VPLSs) that use Pseudowires signaled
   using the Label Distribution Protocol (LDP) and the Border Gateway
   Protocol (BGP) as described in [RFC4761] and [RFC6624].  It also
   conforms to the Network Management Datastore Architecture (NMDA)
   [RFC8342].

1.1.  Terminology

   The following terms are defined in [RFC6241] and are not redefined
   here:

   o  client

   o  configuration data

   o  server

   o  state data

   The following terms are defined in [RFC7950] and are not redefined
   here:

   o  augment

   o  data model

   o  data node

Top      ToC       Page 5 
   The terminology for describing YANG data models is found in
   [RFC7950].

1.1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Tree Diagrams

   Tree diagrams used in this document follow the notation defined in
   [RFC8340].

2.  Definitions

   This document uses the following terms:

   Service Provider (SP):  The organization (usually a commercial
      undertaking) responsible for operating the network that offers VPN
      services to clients and customers.

   Customer Edge (CE) Device:  Equipment that is dedicated to a
      particular customer and is directly connected to one or more PE
      devices via Attachment Circuits (ACs).  A CE is usually located at
      the customer premises and is usually dedicated to a single VPN,
      although it may support multiple VPNs if each one has separate
      ACs.  The CE devices can be routers, bridges, switches, or hosts.

   Provider Edge (PE) Device:  Equipment managed by the SP that can
      support multiple VPNs for different customers and is directly
      connected to one or more CE devices via ACs.  A PE is usually
      located at an SP Point of Presence (POP) and is managed by the SP.

   Virtual Private LAN Service (VPLS):  A VPLS is a provider service
      that emulates the full functionality of a traditional LAN.  A VPLS
      makes it possible to interconnect several LAN segments over a
      packet switched network (PSN) and makes the remote LAN segments
      behave as one single LAN.

   Virtual Private Wire Service (VPWS):  A VPWS is a point-to-point
      circuit (i.e., link) connecting two CE devices.  The link is
      established as a logical Layer 2 circuit through a PSN.  The CE in
      the customer network is connected to a PE in the provider network
      via an AC: the AC is either a physical or logical circuit.  A VPWS

Top      ToC       Page 6 
      differs from a VPLS in that the VPLS is point-to-multipoint while
      the VPWS is point-to-point.  In some implementations, a set of
      VPWSs is used to create a multi-site L2VPN network.

   Pseudowire (PW):  A Pseudowire is an emulation of a native service
      over a PSN.  The native service may be ATM, Frame Relay, Ethernet,
      low-rate Time-Division Multiplexing (TDM), or Synchronous Optical
      Network / Synchronous Digital Hierarchy (SONET/SDH), while the PSN
      may be MPLS, IP (either IPv4 or IPv6), or Layer 2 Tunneling
      Protocol version 3 (L2TPv3).

   MAC-VRF:  A Virtual Routing and Forwarding table for Media Access
      Control (MAC) addresses on a PE.  It is sometimes also referred to
      as a Virtual Switching Instance (VSI).

   UNI:  User-to-Network Interface.  The physical demarcation point
      between the customer's area of responsibility and the provider's
      area of responsibility.

   NNI:  Network-to-Network Interface.  A reference point representing
      the boundary between two networks that are operated as separate
      administrative domains.  The two networks may belong to the same
      provider or to two different providers.

   This document uses the following abbreviations:

   BSS:  Business Support System

   BUM:  Broadcast, Unknown Unicast, or Multicast

   CoS:  Class of Service

   LAG:  Link Aggregation Group

   LLDP:  Link Layer Discovery Protocol

   OAM:  Operations, Administration, and Maintenance

   OSS:  Operations Support System

   PDU:  Protocol Data Unit

   QoS:  Quality of Service

Top      ToC       Page 7 
3.  The Layer 2 VPN Service Model

   A Layer 2 VPN (L2VPN) service is a collection of sites that are
   authorized to exchange traffic between each other over a shared
   infrastructure of a common technology.  The L2VPN Service Model
   (L2SM) described in this document provides a common understanding of
   how the corresponding L2VPN service is to be deployed over the shared
   infrastructure.

   This document presents the L2SM using the YANG data modeling language
   [RFC7950] as a formal language that is both human readable and
   parsable by software for use with protocols such as the Network
   Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040].

   This service model is limited to VPWS-based VPNs and VPLS-based VPNs
   as described in [RFC4761] and [RFC6624] and to Ethernet VPNs (EVPNs)
   as described in [RFC7432].

3.1.  Layer 2 VPN Service Types

   From a technology perspective, a set of basic L2VPN service types
   include:

   o  Point-to-point VPWSs that use LDP-signaled Pseudowires or
      L2TP-signaled Pseudowires [RFC6074].

   o  Multipoint VPLSs that use LDP-signaled Pseudowires or
      L2TP-signaled Pseudowires [RFC6074].

   o  Multipoint VPLSs that use a BGP control plane as described in
      [RFC4761] and [RFC6624].

   o  IP-only LAN Services (IPLSs) that are a functional subset of VPLS
      services [RFC7436].

   o  BGP MPLS-based EVPN services as described in [RFC7432] and
      [RFC7209].

   o  EVPN VPWSs as specified in [RFC8214].

3.2.  Layer 2 VPN Physical Network Topology

   Figure 1 below depicts a typical SP's physical network topology.
   Most SPs have deployed an IP, MPLS, or Segment Routing (SR)
   multi-service core infrastructure.  Ingress Layer 2 service frames
   will be mapped to either an Ethernet Pseudowire (e.g., Pseudowire
   Emulation Edge to Edge (PWE3)) or a Virtual Extensible Local Area

Top      ToC       Page 8 
   Network (VXLAN) PE-to-PE tunnel.  The details of these tunneling
   mechanisms are left to the provider's discretion and are not part of
   the L2SM.

   An L2VPN provides end-to-end Layer 2 connectivity over this
   multi-service core infrastructure between two or more customer
   locations or a collection of sites.  ACs are placed between CE
   devices and PE devices that backhaul Layer 2 service frames from the
   customer over the access network to the provider network or remote
   site.  The demarcation point (i.e., UNI) between the customer and the
   SP can be placed between either (1) customer nodes and the CE device
   or (2) the CE device and the PE device.  The actual bearer connection
   between the CE and the PE will be described in the L2SM.

   The SP may also choose a "seamless MPLS" approach to expand the PWE3
   or VXLAN tunnel between sites.

   The SP may leverage Multiprotocol BGP (MP-BGP) to autodiscover and
   signal the PWE3 or VXLAN tunnel endpoints.

             Site A  |                          |Site B
    ---     ----     |        VXLAN/PW          |               ---
   |   |   |    |    |<------------------------>|              |   |
   | C +---+ CE |    |                          |              | C |
   |   |   |    |    |         ---------        |              |   |
    ---     ----\    |        (         )       |              /---
                 \  -|--     (           )     -|--     ----  /
                  \|    |   (             )   |    |   |    |/
                   | PE +---+ IP/MPLS/SR  +---+ PE +---+ CE |
                  /|    |   (  Network    )   |    |   |    |\
                 /  ----     (           )     ----     ----  \
    ---     ----/             (         )                      \---
   |   |   |    |              ----+----                       |   |
   | C +---+ CE |                  |                           | C |
   |   |   |    |                --+--                         |   |
    ---     ----                | PE  |                         ---
                                 --+--
                                   |      Site C
                                 --+--
                                | CE  |
                                 --+--
                                   |
                                 --+--
                                |  C  |
                                 -----

            Figure 1: Reference Network for the Use of the L2SM

Top      ToC       Page 9 
   From the customer's perspective, however, all the CE devices are
   connected over a simulated LAN environment as shown in Figure 2.
   Broadcast and multicast packets are sent to all participants in the
   same bridge domain.

                        CE---+----+-----+---CE
                             |    |     |
                             |    |     |
                             |    |     |
                        CE---+    CE    +---CE

                  Figure 2: Customer's View of the L2VPN

4.  Service Data Model Usage

   The L2SM provides an abstracted interface to request, configure, and
   manage the components of an L2VPN service.  The model is used by a
   customer who purchases connectivity and other services from an SP to
   communicate with that SP.

   A typical usage for this model is as an input to an orchestration
   layer that is responsible for translating it into configuration
   commands for the network elements that deliver/enable the service.
   The network elements may be routers, but also servers (like
   Authentication, Authorization, and Accounting (AAA)) that are
   necessary within the network.

   The configuration of network elements may be done using the Command
   Line Interface (CLI) or any other configuration (or "southbound")
   interface such as NETCONF [RFC6241] in combination with device-
   specific and protocol-specific YANG data models.

   This way of using the service model is illustrated in Figure 3 and is
   described in more detail in [RFC8309] and [RFC8199].  The split of
   the orchestration function between a "service orchestrator" and a
   "network orchestrator" is clarified in [RFC8309].  The usage of this
   service model is not limited to this example: it can be used by any
   component of the management system but not directly by network
   elements.

   The usage and structure of this model should be compared to the
   Layer 3 VPN service model defined in [RFC8299].

Top      ToC       Page 10 
          ----------------------------
         | Customer Service Requester |
          ----------------------------
              |
              |
        L2SM  |
              |
              |
            -----------------------
           | Service Orchestration |
            -----------------------
              |
              |     Service             +-------------+
              |     Delivery    +------>| Application |
              |     Model       |       |   BSS/OSS   |
              |                 V       +-------------+
            -----------------------
           | Network Orchestration |
            -----------------------
              |            |
      +----------------+   |
      | Config manager |   |
      +----------------+   |  Device
              |            |  Models
              |            |
   --------------------------------------------
                     Network
                                 +++++++
                                 + AAA +
                                 +++++++

         ++++++++   Bearer    ++++++++           ++++++++      ++++++++
         + CE A + ----------- + PE A +           + PE B + ---- + CE B +
         ++++++++  Connection ++++++++           ++++++++      ++++++++

                    Site A                               Site B

         Figure 3: Reference Architecture for the Use of the L2SM

   The Metro Ethernet Forum (MEF) [MEF-6] has also developed an
   architecture for network management and operations, but the work of
   the MEF embraces all aspects of lifecycle service orchestration,
   including billing, Service Level Agreements (SLAs), order management,
   and lifecycle management.  The IETF's work on service models is
   typically smaller and offers a simple, self-contained service YANG
   module.  See [RFC8309] for more details.


Next Section