Skip to main content

Layer 3 VPN Network Model
draft-aguado-opsawg-l3sm-l3nm-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Alejandro Aguado , Oscar Gonzalez de Dios , Victor Lopez , Daniel Voyer , Luis Angel Munoz
Last updated 2019-05-21
Replaced by draft-ietf-opsawg-l3sm-l3nm, draft-ietf-opsawg-l3sm-l3nm, RFC 9182
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-aguado-opsawg-l3sm-l3nm-00
Internet Engineering Task Force                                A. Aguado
Internet-Draft                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                                V. Lopez
Expires: November 22, 2019                                    Telefonica
                                                                D. Voyer
                                                             Bell Canada
                                                                L. Munoz
                                                                Vodafone
                                                            May 21, 2019

                       Layer 3 VPN Network Model
                    draft-aguado-opsawg-l3sm-l3nm-00

Abstract

   RFC 8299 [RFC8299] defines a L3VPN Service Model (L3SM) YANG data
   model that can be used for communication between customers and
   network operators.  It assumes that there is a monolithic management
   system with full control of transport resources.  This approach (that
   is valid for the customer to network operator conversation) limits
   the usage of the model to the role of a Customer Service Model,
   according to the terminology defined in RFC 8309 [RFC8309].

   There is a need for a YANG model for use between the entity that
   interacts directly with the customer (service orchestrator) and the
   entity in charge of network orchestration and control which,
   according to RFC 8309 [RFC8309], can be referred as Service Delivery
   Model.  In some cases, the control of the network is further expanded
   into per- domain control.

   This document uses the L3SM model defined in RFC 8299 [RFC8299], and
   extends it to facilitate communication between the service
   orchestrator and transport orchestrator (MSDC), and an MDSC and
   domain controllers.  The resulting model is called the L3VPN Network
   Model (L3NM).

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 https://datatracker.ietf.org/drafts/current/.

Aguado, et al.          Expires November 22, 2019               [Page 1]
Internet-Draft                    l3nm                          May 2019

   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 November 22, 2019.

Copyright Notice

   Copyright (c) 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Reference architecture  . . . . . . . . . . . . . . . . . . .   4
   3.  Yang model extensions . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Bearer ethernet Encapsulation . . . . . . . . . . . . . .   8
     3.2.  Multi-Domain Resource Management  . . . . . . . . . . . .   8
     3.3.  Remote Far-End Configuration  . . . . . . . . . . . . . .   8
     3.4.  Provide Edge Identification Point . . . . . . . . . . . .   9
   4.  Design of the data model  . . . . . . . . . . . . . . . . . .   9
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   RFC 8299 [RFC8299] defines a L3VPN Service Model (L3SM) YANG data
   model that can be used for communication between customers and
   network operators.  Although the intention to provide an abstracted
   view of the customer's requested services is clear, the assumption is

Aguado, et al.          Expires November 22, 2019               [Page 2]
Internet-Draft                    l3nm                          May 2019

   that the model is applied at the top of a monolithic management
   system with full control of transport resources.  That assumption
   substantially limits the usage of the L3SM to the role of a Customer
   Service Model, according to the terminology defined in RFC 8309
   [RFC8309].

   This document defines a set of extensions of the YANG model described
   in RFC 8299 [RFC8299] via augmentation.  The augmentations facilitate
   the use the resulting model in communications with the transport
   orchestrator, also known as the MDSC (Multi-Domain Service
   Coordinator) in the terminology of the framework for Abstraction and
   Control of TE Networks (ACTN) defined in RFC 8453 [RFC8453].  The
   MDSC is functional component responsible for orchestration of the
   network resources and instigate connections across the operator's
   networks.

   The data model defined in this document is called the L3VPN Network
   Model (L3NM).  It enables further capabilities, such as resource
   management or to serve as a multi-domain orchestration interface,
   where transport resources must be synchronized.

   This document does not obsolete, but complements, the definitions in
   RFC 8299 [RFC8299].  It aims to provide a wider scope for the L3SM
   via augmentation, but does not attempt to address all deployment
   cases especially those where the L3VPN connectivity is supported
   through the coordination of different VPNs in different underlying
   networks.  More complex deployment scenarios involving the
   coordination of different VPN instances and different technologies to
   provide end-to-end VPN connectivity is out of scope of this document,
   but is discussed in [I-D.evenwu-opsawg-yang-composed-vpn].

1.1.  Terminology

   This document assumes that the reader is familiar with the contents
   of RFC 6241 [RFC6241], RFC 7950 [RFC7950], RFC 8299 [RFC8299],
   RFC 8309 [RFC8309], and [RFC8453] and uses terminology from those
   documents.  Tree diagrams used in this document follow the notation
   defined in [RFC8340].

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

Aguado, et al.          Expires November 22, 2019               [Page 3]
Internet-Draft                    l3nm                          May 2019

2.  Reference architecture

   Figure 1 shows where the L3NM is used in a management stack.  The
   figure is an expansion of the architecture presented in Section 5 of
   RFC 8299 [RFC8299] and decomposes the box marked "orchestration" in
   that figure into three separate functional components called "Service
   Orchestration", "Network Orchestration", and "Domain Orchestration".

   At the same time, terminology from RFC 8309 [RFC8309] is introduced
   to show the distinction between the "Customer Service Model", the
   "Service Delivery Model", the "Network Configuration Model", and the
   "Device Configuration Model".  In that context, the "Domain
   Orchestration" and "Config Manager" roles may be performed by
   "Controllers".

Aguado, et al.          Expires November 22, 2019               [Page 4]
Internet-Draft                    l3nm                          May 2019

                                     +---------------+
                                   |   Customer    |
                                   +---------------+
                   Customer Service Model  |
                          l3vpn-svc        |
                                   +---------------+
                                   |    Service    |
                                   | Orchestration |
                                   +---------------+
                 Service Delivery Model    |
                         l3nm-svc          |
                  (l3vpn-svc + extensions) |
                                   +---------------+
                                   |   Network     |
                                   | Orchestration |
                                   +---------------+
             Network Configuration Model  |
                                __________|____________
                               |                       |
                      +---------------+       +---------------+
                      |    Domain     |       |     Domain    |
                      | Orchestration |       | Orchestration |
                      +---------------+       +---------------+
           Device         |        |                   |
           Configuration  |        |                   |
           Model          |        |                   |
                     +---------+   |                   |
                     | Config  |   |                   |
                     | Manager |   |                   |
                     +---------+   |                   |
                          |        |                   |
                          | NETCONF/CLI..................
                          |        |                   |
                   +------------------------------------------------+
                                       Network

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

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

                     Site A                               Site B

                          Figure 1: L3SM and L3NM

Aguado, et al.          Expires November 22, 2019               [Page 5]
Internet-Draft                    l3nm                          May 2019

   The L3SM and L3NM may also be set in the context of the ACTN
   architecture [RFC8453].  Figure 2 shows the Customer Network
   Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and
   the Provisioning Network Controller (PNC).  It also shows the
   interfaces between these functional units: the CNC-MDSC Interface
   (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface
   (SBI).

Aguado, et al.          Expires November 22, 2019               [Page 6]
Internet-Draft                    l3nm                          May 2019

                  ----------------------------------
                  | Customer                         |
                  |  -----------------------------   |
                  | |             CNC             |  |
                  |  -----------------------------   |
                   ----:-----------------------:-----
                       :                       :
                       : L3SM                  : L3SM
                       :                       :
              ---------:---------     -------------------
             | MDSC    :         |   |       MDSC        |
             |  ---------------  |   |     (parent)      |
             | |    Service    | |    -------------------
             | | Orchestration | |             :
             |  ---------------  |             : L3NM
             |         :         |             :
             |         : L3NM    |    -------------------
             |         :         |   |       MDSC        |
             |  ---------------  |   |      (child)      |
             | |    Network    | |    -------------------
             | | Orchestration | |             :
             |  ---------------  |             :
              ---------:---------              :
                       :                       :
                       : Network Configuration :
                       :                       :
           ------------:-------       ---------:------------
          | Domain     :       |     |         : Domain     |
          | Controller :       |     |         : Controller |
          |        ---------   |     |     ---------        |
          |       |   PNC   |  |     |    |   PNC   |       |
          |        ---------   |     |     ---------        |
           ------------:-------       ---------:------------
                       :                       :
                       : Device Configuration  :
                       :                       :
                   --------                --------
                  | Device |              | Device |
                   --------                --------

              Figure 2: L3SM and L3NM in the Context of ACTN

3.  Yang model extensions

   The scenarios covered include: the integration of ethernet and
   encapsulation parameters, the extension for transport resources (e.g.
   RTs and RDs) to be orchestrated from the management system, far-end

Aguado, et al.          Expires November 22, 2019               [Page 7]
Internet-Draft                    l3nm                          May 2019

   configuration of PEs not managed by the management system and the
   definition for PE identification.

3.1.  Bearer ethernet Encapsulation

   The definition of a L3 VPN is commonly defined not only at the IP
   layer, but also requires to identify parameters at the Ethernet
   layer, such as encapsulation (e.g.  VLAN, QinQ, QinAny, VxLAN, etc).
   This specification is not supported in [RFC8299], whilst it suggests
   that any extension on this direction shall be implemented via
   augmentation of the bearer container.  The extension defined to cope
   with these parameters uses the connection container inside the site-
   network-access defined by the the [RFC8466].  This container defines
   protocol parameters to enable connectivity at Layer 2.  In the
   context of L3SM, the augmentation includes only mandatory parameters
   for the service configuration, which are mainly related to the
   interface encapsulation.  Other definitions from L2SM connection
   container are left aside.  For example, LAG information is not
   required and it shall be configured prior to the service
   configuration, being the aggregated interface identified in the model
   as the bearer-reference, as discussed later in Section 4.4.

3.2.  Multi-Domain Resource Management

   The implementation of L3 VPN services which spans across
   administratively separated domains (i.e. that under the
   administration of different management systems or controllers)
   requires some network resources to be synchronised between systems.
   Particularly, there are two resources that must be orchestrated and
   synchronised to avoid asymmetric (non-functional) configuration, or
   the usage of unavailable resources.  For example, RTs shall be
   synchronised between PEs.  When every PE is controlled by the same
   management system, RT allocation can be performed by the system.  In
   cases where the service spans across multiple management systems,
   this task shall be synchronised and, therefore, the service model
   must allow this specification.  In addition, RDs must be also
   synchronised to avoid collisions in RD allocation between separated
   systems.  A incorrect allocation might lead into same RD and IP
   prefixes being exported by different PE routers.

3.3.  Remote Far-End Configuration

   Depending on the control plane implementation, different network
   scenarios might require additional information for the L3 VPN service
   to be configured and active.  For example, an L3 VPN Option C
   service, if no reflection of IPv4 VPN routes is configured via ASBR
   or route reflector, may require additional configuration (e.g. a new
   BGP neighbour) to be coordinated between both management systems.

Aguado, et al.          Expires November 22, 2019               [Page 8]
Internet-Draft                    l3nm                          May 2019

   This definition requires for every management system participant on
   the VPN to receive not just their own sites and site-network-
   accesses, but also to receive information about external ones,
   identified as an external site-network-access-type.  In addition,
   this particular site-network-access is augmented to include the
   loopback address of the far-end (remote/external) PE router.

3.4.  Provide Edge Identification Point

   RFC8299 states that The "bearer-reference" parameter is used in cases
   where the customer has already ordered a network connection to the SP
   apart from the IP VPN site and wants to reuse this connection.  The
   string used is an internal reference from the SP and describe the
   already-available connection.  Oftenly, a client interface (either a
   customer one or an interface used by the SP) is already in place and
   connected, although it has not being used previously.  In some other
   cases (e.g. for stitching purposes), the termination of a VPN service
   is done over logical terminations within a PE router.

   The bearer-reference must serve as a strict unequivocal parameters to
   identify the connection between a PE and a client (CE).  This means
   that, despite the type is maintained as a string and there is no
   restriction in the way this data is formed, the bearer-reference must
   serve as the unique way to identify the PE router and the client
   interface.  This, together with the encapsulation augments proposed
   in 4.1, serves as the way to identify the client interface and
   configure L2 specific parameters.

4.  Design of the data model

   The augments defined in this document are organised per scenario, as
   per defined in Section 4.  The case described 4.4 does not need any
   further extension of the data model and only requires a more
   restricted definition on how the data model is used for PE router and
   client port identification, so no augment is implemented for this
   scenario.

   The augments implemented are distributed as follows.  The first
   augment implements the extensions for RT and RD definition for the L3
   VPN, following the YANG definitions from BESS-L3VPN.  The second
   augment copes with the information from a remote PE not directly
   under the management system supervision.  This augment does not
   follow any previously defined model and includes the loopback IP
   address of the external router.  The last augment includes
   information below layer 3 that is required for the service.  In
   particular, we include information related to clients interface
   encapsulation and aggregation.

Aguado, et al.          Expires November 22, 2019               [Page 9]
Internet-Draft                    l3nm                          May 2019

   The high-level model structure proposed by this document is as shown
   below:

            |-------------------- EXAMPLE --------------------|

Aguado, et al.          Expires November 22, 2019              [Page 10]
Internet-Draft                    l3nm                          May 2019

module: ietf-l3vpn-svc-ext
  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access:
    +--rw transport
       +--rw vpn-targets
          +--rw vpn-target* [route-target]
          |  +--rw route-target         rt-types:route-target
          |  +--rw route-target-type    rt-types:route-target-type
          +--rw route-policy?   -> /rt-pol:routing-policy/policy-definitions/policy-definition/name
  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access:
    +--rw far-end
       +--rw address?   inet:ip-address
  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access/l3vpn-svc:bearer:
    +--rw ethernet
       +--rw connection
          +--rw encapsulation-type?   identityref
          +--rw eth-inf-type?         identityref
          +--rw tagged-interface
          |  +--rw type?                identityref
          |  +--rw dot1q-vlan-tagged {dot1q}?
          |  |  +--rw tg-type?    identityref
          |  |  +--rw cvlan-id    uint16
          |  +--rw priority-tagged
          |  |  +--rw tag-type?   identityref
          |  +--rw qinq {qinq}?
          |  |  +--rw tag-type?   identityref
          |  |  +--rw svlan-id    uint16
          |  |  +--rw cvlan-id    uint16
          |  +--rw qinany {qinany}?
          |  |  +--rw tag-type?   identityref
          |  |  +--rw svlan-id    uint16
          |  +--rw vxlan {vxlan}?
          |     +--rw vni-id       uint32
          |     +--rw peer-mode?   identityref
          |     +--rw peer-list* [peer-ip]
          |        +--rw peer-ip    inet:ip-address
          +--rw untagged-interface
          |  +--rw speed?                 uint32
          |  +--rw mode?                  neg-mode
          |  +--rw phy-mtu?               uint32
          |  +--rw lldp?                  boolean
          |  +--rw oam-802.3ah-link {oam-3ah}?
          |  |  +--rw enabled?   boolean
          |  +--rw uni-loop-prevention?   boolean

                                 Figure 3

Aguado, et al.          Expires November 22, 2019              [Page 11]
Internet-Draft                    l3nm                          May 2019

5.  Acknowledgements

   Thanks to Adrian Farrel and Miguel Cros for the suggestions on the
   document

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   All the security considerations of RFC 8299 [RFC8299] apply to this
   document.  Subsequent versions will provide additional security
   considerations.

8.  References

8.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,
              <https://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
              "YANG Data Model for L3VPN Service Delivery", RFC 8299,
              DOI 10.17487/RFC8299, January 2018,
              <https://www.rfc-editor.org/info/rfc8299>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

Aguado, et al.          Expires November 22, 2019              [Page 12]
Internet-Draft                    l3nm                          May 2019

Authors' Addresses

   Alejandro Aguado
   Telefonica
   Madrid
   ES

   Email: alejandro.aguadomartin.ext@telefonica.com

   Oscar Gonzalez de Dios (editor)
   Telefonica
   Madrid
   ES

   Email: oscar.gonzalezdedios@telefonica.com

   Victor Lopez
   Telefonica
   Madrid
   ES

   Email: victor.lopezalvarez@telefonica.com

   Daniel Voyer
   Bell Canada
   CA

   Email: daniel.voyer@bell.ca

   Luis Angel Munoz
   Vodafone
   ES

   Email: luis-angel.munoz@vodafone.com

Aguado, et al.          Expires November 22, 2019              [Page 13]