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

Document Type Active Internet-Draft (individual)
Last updated 2019-07-08
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Yang Validation 47 errors, 1 warnings.
Additional URLs
- Yang catalog entry for ietf-l3vpn-ntw@2019-07-04.yang
- Yang impact analysis for draft-aguado-opsawg-l3sm-l3nm
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                                A. Aguado
Internet-Draft                                  O. Gonzalez de Dios, Ed.
Intended status: Standards Track                                V. Lopez
Expires: January 9, 2020                                      Telefonica
                                                                D. Voyer
                                                             Bell Canada
                                                                L. Munoz
                                                                Vodafone
                                                            July 8, 2019

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

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 January 9, 2020                [Page 1]
Internet-Draft                    l3nm                         July 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 January 9, 2020.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Reference architecture  . . . . . . . . . . . . . . . . . . .   4
   3.  Yang model explanation  . . . . . . . . . . . . . . . . . . .   7
     3.1.  Structure of the model  . . . . . . . . . . . . . . . . .   8
     3.2.  sites and bearers . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Bearer ethernet Encapsulation . . . . . . . . . . . . . .   8
     3.4.  Multi-Domain Resource Management  . . . . . . . . . . . .   8
     3.5.  Remote Far-End Configuration  . . . . . . . . . . . . . .   9
     3.6.  Provide Edge Identification Point . . . . . . . . . . . .   9
   4.  Design of the data model  . . . . . . . . . . . . . . . . . .  10
   5.  Yang module . . . . . . . . . . . . . . . . . . . . . . . . .  20
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  96
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  96
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  96
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  97
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  97
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  97
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  97
     11.2.  Informative References . . . . . . . . . . . . . . . . .  97
Show full document text