Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8299

Proposed STD
Pages: 188
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~vpn

YANG Data Model for L3VPN Service Delivery

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

Obsoletes:    8049


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        Q. Wu, Ed.
Request for Comments: 8299                                        Huawei
Obsoletes: 8049                                             S. Litkowski
Category: Standards Track                                         Orange
ISSN: 2070-1721                                              L. Tomotaki
                                                                 Verizon
                                                                K. Ogaki
                                                        KDDI Corporation
                                                            January 2018


               YANG Data Model for L3VPN Service Delivery

Abstract

   This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 provider-provisioned VPN service.  This document is limited
   to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
   model is intended to be instantiated at the management system to
   deliver the overall service.  It is not a configuration model to be
   used directly on network elements.  This model provides an abstracted
   view of the Layer 3 IP VPN service configuration components.  It will
   be up to the management system to take this model as input and use
   specific configuration models to configure the different network
   elements to deliver the service.  How the configuration of network
   elements is done is out of scope for this document.

   This document obsoletes RFC 8049; it replaces the unimplementable
   module in that RFC with a new module with the same name that is not
   backward compatible.  The changes are a series of small fixes to the
   YANG module and some clarifications to the text.

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/rfc8299.

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.2. Requirements Language ......................................5
      1.3. Tree Diagrams ..............................................5
      1.4. Summary of Changes from RFC 8049 ...........................5
           1.4.1. Implementation Issues with RFC 8049 .................7
           1.4.2. Impact Assessment ...................................7
   2. Acronyms ........................................................8
   3. Definitions ....................................................10
   4. Layer 3 IP VPN Service Model ...................................10
   5. Service Data Model Usage .......................................11
   6. Design of the Data Model .......................................12
      6.1. Features and Augmentation .................................22
      6.2. VPN Service Overview ......................................22
           6.2.1. VPN Service Topology ...............................23
           6.2.2. Cloud Access .......................................26
           6.2.3. Multicast Service ..................................29
           6.2.4. Extranet VPNs ......................................30
      6.3. Site Overview .............................................32
           6.3.1. Devices and Locations ..............................33
           6.3.2. Site Network Accesses ..............................34
      6.4. Site Role .................................................36
      6.5. Site Belonging to Multiple VPNs ...........................37
           6.5.1. Site VPN Flavor ....................................37
           6.5.2. Attaching a Site to a VPN ..........................41

Top      ToC       Page 3 
      6.6. Deciding Where to Connect the Site ........................47
           6.6.1. Constraint: Device .................................48
           6.6.2. Constraint/Parameter: Site Location ................48
           6.6.3. Constraint/Parameter: Access Type ..................49
           6.6.4. Constraint: Access Diversity .......................50
           6.6.5. Infeasible Access Placement ........................59
           6.6.6. Examples of Access Placement .......................60
           6.6.7. Route Distinguisher and VRF Allocation .............80
      6.7. Site Network Access Availability ..........................81
      6.8. Traffic Protection ........................................82
      6.9. Security ..................................................83
           6.9.1. Authentication .....................................83
           6.9.2. Encryption .........................................84
      6.10. Management ...............................................85
      6.11. Routing Protocols ........................................86
           6.11.1. Handling of Dual Stack ............................87
           6.11.2. LAN Directly Connected to SP Network ..............88
           6.11.3. LAN Directly Connected to SP Network with
                   Redundancy ........................................89
           6.11.4. Static Routing ....................................89
           6.11.5. RIP Routing .......................................89
           6.11.6. OSPF Routing ......................................90
           6.11.7. BGP Routing .......................................92
      6.12. Service ..................................................93
           6.12.1. Bandwidth .........................................94
           6.12.2. MTU ...............................................94
           6.12.3. QoS ...............................................94
           6.12.4. Multicast ........................................103
      6.13. Enhanced VPN Features ...................................104
           6.13.1. Carriers' Carriers ...............................104
      6.14. External ID References ..................................105
      6.15. Defining NNIs ...........................................105
           6.15.1. Defining an NNI with the Option A Flavor .........107
           6.15.2. Defining an NNI with the Option B Flavor .........111
           6.15.3. Defining an NNI with the Option C Flavor .........113
   7. Service Model Usage Example ...................................114
   8. Interaction with Other YANG Models ............................120
   9. YANG Module ...................................................125
   10. Security Considerations ......................................184
   11. IANA Considerations ..........................................185
   12. References ...................................................185
      12.1. Normative References ....................................185
      12.2. Informative References ..................................187
   Acknowledgements .................................................188
   Contributors .....................................................188
   Authors' Addresses ...............................................188

Top      ToC       Page 4 
1.  Introduction

   This document defines a Layer 3 VPN service data model written in
   YANG.  The 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.

   This document obsoletes [RFC8049]; it creates a new module with the
   same name as the module defined in [RFC8049].  The changes from
   [RFC8049] are listed in full in Section 1.4.  They are small in
   scope, but include fixes to the module to make it possible to
   implement.

   The YANG module described in [RFC8049] cannot be implemented because
   of issues around the use of XPATH.  These issues are explained in
   Section 1.4.1.

   Section 11 of [RFC7950] describes when it is permissible to reuse a
   module name.  Section 1.4.2 provides an impact assessment in this
   context.

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

   The terminology for describing YANG data models is found in
   [RFC7950].

Top      ToC       Page 5 
   This document presents some configuration examples using XML
   representation.

1.2.  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.3.  Tree Diagrams

   A simplified graphical representation of the data model is presented
   in Section 6.

   The meanings of the symbols in these diagrams are as follows:

   o  Brackets "[" and "]" enclose list keys.

   o  Curly braces "{" and "}" contain names of optional features that
      make the corresponding node conditional.

   o  Abbreviations before data node names: "rw" means configuration
      data (read-write), and "ro" means state data (read-only).

   o  Symbols after data node names: "?" means an optional node, and "*"
      denotes a "list" or "leaf-list".

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.

1.4.  Summary of Changes from RFC 8049

   This document revises and obsoletes L3VPN Service Model [RFC8049],
   drawing on insights gained from L3VPN Service Model deployments and
   on feedback from the community.  The major changes are as follows:

   o  Change type from 16-bit integer to string for the leaf id under
      "qos-classification-policy" container.

   o  Stick to using ordered-by user and remove inefficiency to map
      service model sequence number to device model sequence number.

Top      ToC       Page 6 
   o  Remove mandating the use of deviations and add "if-feature target-
      sites" under the leaf-list target-sites in Section 6.12.2.1 of
      [RFC8049].

   o  Change in keywords from [RFC2119] and [RFC8174] on operation of
      the management system in the third paragraph of Section 6.6,
      Section 6.6.5, and Section 7.

   o  Fix incomplete description statements.

   o  Add YANG statement to check that Stateless Address
      Autoconfiguration (SLAAC) parameters are used only for IPv6.

   o  Fix strange wording in Section 6.11.7.

   o  Change the use of the absolute paths to the use of relative paths
      in the "must" statement or "path" statement for vpn-policy-id leaf
      node, management container, location leaf node, devices container,
      location case, location-reference leaf, device case, device-
      reference leaf to make configuration is only applicable to the
      current sites.

   o  Change "must" statement to "when" statement for management
      container device container.

   o  Fix optional parameter issues by adding a default or description
      for others or make some of them mandatory.

   o  Define new grouping vpn-profile-cfg for all the identifiers
      provided by SP to the customer.  The identifiers include cloud-
      identifier, std-qos-profile, OAM profile-name, and provider-
      profile for encryption.

   o  Add in the XPATH string representation of identityrefs and remove
      unqualified name.  Change from YANG 1.0 Support to YANG 1.1
      Support.

   o  Remove "when" statement from leaf nat44-customer-address.

   o  Fixed broken example and Add mandatory element in the examples.

   o  Remove redundant parameters in the cloud access.

   o  Specify provider address and a list of start-end addresses from
      provider address for DHCP case.

   o  Add a few text to clarify what the site is in Section 6.3.

Top      ToC       Page 7 
   o  Add multi-filter and multiVPN per entry support for VPN policy.

   o  Modify description for svc-input-bandwidth leaf and svc-output-
      bandwidth leaf to make it consistent with the text in
      Section 6.12.1.

   o  Clarify the rational of the model in the Section 5.

   o  Add text to clarify the way to achieve Per-VPN QoS policy.

1.4.1.  Implementation Issues with RFC 8049

   [RFC8049] made an initial attempt to define a YANG data model
   forL3VPN services.  After it was published it was discovered that,
   while the YANG compiled it was broken from an implementation
   perspective.  That is, it was impossible to build a functional
   implementation of the module.

   Section 1.4 provides a full list of the changes since [RFC8049].
   Some of these changes remove ambiguities from the documented YANG,
   while other changes fix the implementation issues.

   1.  Several uses of 'must' expressions in the module were broken
       badly enough that the module was not usable in the form it was
       published.  While some compilers and YANG checkers found no
       issues (most YANG tools do not attempt to parse these
       expressions), other tools that really understand the XPATH in the
       expressions refused to compile them.

       The changes needed to fix these expressions were small and local.

   2.  The second issue relates to how Access Control List (ACL) rules
       were sorted.  In [RFC8049] the English language text and the text
       in the YANG definition contradicted each other.  Furthermore, the
       model used classic ACL rule numbering notation for something that
       was semantically very different (ordered-by user) in the YANG
       thus creating the potential for misunderstanding.

   3.  Further to point 2, the ACL modeling in [RFC8049] was
       incompatible with work going on in other IETF documents such as
       [ACL-YANG].

1.4.2.  Impact Assessment

   When changing the content of a YANG module, care must be taken to
   ensure that there are no interoperability issues caused by a failure
   to enable backward compatibility.

Top      ToC       Page 8 
   Section 11 of [RFC7950] clearly describes the circumstances under
   which it is not acceptable to maintain a module name.

      ...changes to published modules are not allowed if they have any
      potential to cause interoperability problems between a client
      using an original specification and a server using an updated
      specification.

   The module defined in this document is not backward compatible with
   that defined in [RFC8049], but it is important to understand that
   there is no possibility of an interoperability issue between the
   module defined in this document and that presented in [RFC8049]
   because that module could not be implemented for the reasons
   described in Section 1.4.1.  Thus, noting the rules set out in
   [RFC7950], it was decided to retain the module name in this document.

2.  Acronyms

   AAA: Authentication, Authorization, and Accounting.

   ACL: Access Control List.

   ADSL: Asymmetric DSL.

   AH: Authentication Header.

   AS: Autonomous System.

   ASBR: Autonomous System Border Router.

   ASM: Any-Source Multicast.

   BAS: Broadband Access Switch.

   BFD: Bidirectional Forwarding Detection.

   BGP: Border Gateway Protocol.

   BSR: Bootstrap Router.

   CE: Customer Edge.

   CLI: Command Line Interface.

   CsC: Carriers' Carriers.

   CSP: Cloud Service Provider.

Top      ToC       Page 9 
   DHCP: Dynamic Host Configuration Protocol.

   DSLAM: Digital Subscriber Line Access Multiplexer.

   ESP: Encapsulating Security Payload.

   GRE: Generic Routing Encapsulation.

   IGMP: Internet Group Management Protocol.

   LAN: Local Area Network.

   MLD: Multicast Listener Discovery.

   MTU: Maximum Transmission Unit.

   NAT: Network Address Translation.

   NETCONF: Network Configuration Protocol.

   NNI: Network-to-Network Interface.

   OAM: Operations, Administration, and Maintenance.

   OSPF: Open Shortest Path First.

   OSS: Operations Support System.

   PE: Provider Edge.

   PIM: Protocol Independent Multicast.

   POP: Point of Presence.

   QoS: Quality of Service.

   RD: Route Distinguisher.

   RIP: Routing Information Protocol.

   RP: Rendezvous Point.

   RT: Route Target.

   SFTP: Secure FTP.

   SLA: Service Level Agreement.

Top      ToC       Page 10 
   SLAAC: Stateless Address Autoconfiguration.

   SP: Service Provider.

   SPT: Shortest Path Tree.

   SSM: Source-Specific Multicast.

   VM: Virtual Machine.

   VPN: Virtual Private Network.

   VRF: VPN Routing and Forwarding.

   VRRP: Virtual Router Redundancy Protocol.

3.  Definitions

   Customer Edge (CE) Device: A CE is equipment dedicated to a
   particular customer; it is directly connected (at Layer 3) to one or
   more PE devices via attachment circuits.  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
   attachment circuits.

   Provider Edge (PE) Device: A PE is equipment managed by the SP; it
   can support multiple VPNs for different customers and is directly
   connected (at Layer 3) to one or more CE devices via attachment
   circuits.  A PE is usually located at an SP point of presence (POP)
   and is managed by the SP.

   PE-Based VPNs: The PE devices know that certain traffic is VPN
   traffic.  They forward the traffic (through tunnels) based on the
   destination IP address of the packet and, optionally, based on other
   information in the IP header of the packet.  The PE devices are
   themselves the tunnel endpoints.  The tunnels may make use of various
   encapsulations to send traffic over the SP network (such as, but not
   restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).

4.  Layer 3 IP VPN Service Model

   A Layer 3 IP VPN service is a collection of sites that are authorized
   to exchange traffic between each other over a shared IP
   infrastructure.  This Layer 3 VPN service model aims at providing a
   common understanding of how the corresponding IP VPN service is to be
   deployed over the shared infrastructure.  This service model is
   limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110],
   and [RFC4364].

Top      ToC       Page 11 
5.  Service Data Model Usage

                   l3vpn-svc |
                     Model   |
                             |
                      +------------------+         +-----+
                      |   Orchestration  | < --- > | OSS |
                      +------------------+         +-----+
                         |            |
                 +----------------+   |
                 | Config manager |   |
                 +----------------+   |
                         |            |
                         | NETCONF/CLI ...
                         |            |
           +------------------------------------------------+
                                Network

                              +++++++
                              + AAA +
                              +++++++

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

                 Site A                               Site B

   The idea of the L3 IP VPN service model is to propose an abstracted
   interface between customers and network operators to manage
   configuration of components of an L3VPN service.  The model is
   intended to be used in a mode where the network operator's system is
   the server and the customer's system is the client.  A typical
   scenario would be to use this model as an input for an orchestration
   layer that will be responsible for translating it to an orchestrated
   configuration of network elements that will be part of the service.
   The network elements can be routers but can also be servers (like
   AAA); the network's configuration is not limited to these examples.
   The configuration of network elements can be done via the CLI,
   NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of
   a specific configuration (BGP, VRF, BFD, etc.), or some other
   technique, as preferred by the operator.

   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.


Next Section