Skip to main content

A Framework for Automating Service and Network Management with YANG
RFC 8969

Document Type RFC - Informational (January 2021) Errata
Authors Qin Wu , Mohamed Boucadair , Diego Lopez , Chongfeng Xie , Liang Geng
Last updated 2022-03-31
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Robert Wilton
Send notices to (None)
RFC 8969
Network Working Group                                        M. Douglass
Internet-Draft                                                       RPI
Intended status: Standards Track                                C. Daboo
Expires: August 8, 2014                                            Apple
                                                        February 4, 2014

                       Timezone Service Protocol
                   draft-douglass-timezone-service-10

Abstract

   This document defines a timezone service protocol that allows
   reliable, secure and fast delivery of timezone data to client systems
   such as calendaring and scheduling applications or operating systems.

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 August 8, 2014.

Copyright Notice

   Copyright (c) 2014 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
   (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.

Douglass & Daboo         Expires August 8, 2014                 [Page 1]
Internet-Draft          Timezone Service Protocol          February 2014

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Glossary of terms  . . . . . . . . . . . . . . . . . . . .  4
   2.  Architectural Overview . . . . . . . . . . . . . . . . . . . .  5
   3.  General Considerations . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Timezone Identifiers . . . . . . . . . . . . . . . . . . .  6
     3.2.  Timezone Aliases . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Timezone Localized Names . . . . . . . . . . . . . . . . .  7
     3.4.  Truncated Timezones  . . . . . . . . . . . . . . . . . . .  7
   4.  Timezones Service Protocol . . . . . . . . . . . . . . . . . .  8
     4.1.  Server Protocol  . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Timezone Queries . . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Timezone Formats . . . . . . . . . . . . . . . . . . .  9
       4.1.3.  Conditional Timezone Requests  . . . . . . . . . . . .  9
       4.1.4.  Expanded Timezone Data . . . . . . . . . . . . . . . .  9
       4.1.5.  Server Requirements  . . . . . . . . . . . . . . . . . 10
       4.1.6.  Error Responses  . . . . . . . . . . . . . . . . . . . 10
       4.1.7.  Extensions . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Client Guidelines  . . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  Discovery  . . . . . . . . . . . . . . . . . . . . . . 10
         4.2.1.1.  Timezone Service SRV Service Labels  . . . . . . . 11
         4.2.1.2.  Timezone Service TXT records . . . . . . . . . . . 11
         4.2.1.3.  Timezone Service Well-Known URI  . . . . . . . . . 12
           4.2.1.3.1.  Example: well-known URI redirects to
                       actual context path  . . . . . . . . . . . . . 12
       4.2.2.  Initial Synchronization of All Timezones . . . . . . . 12
       4.2.3.  Subsequent Synchronization of All Timezones  . . . . . 13
   5.  Request Parameters . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  "action" Parameter . . . . . . . . . . . . . . . . . . . . 13
     5.2.  "format" Parameter . . . . . . . . . . . . . . . . . . . . 13
     5.3.  "changedsince" Parameter . . . . . . . . . . . . . . . . . 14
     5.4.  "start" Parameter  . . . . . . . . . . . . . . . . . . . . 14
     5.5.  "end" Parameter  . . . . . . . . . . . . . . . . . . . . . 14
     5.6.  "lang" Parameter . . . . . . . . . . . . . . . . . . . . . 14
     5.7.  "tzid" Parameter . . . . . . . . . . . . . . . . . . . . . 15
     5.8.  "name" Parameter . . . . . . . . . . . . . . . . . . . . . 15
     5.9.  "truncate" Parameter . . . . . . . . . . . . . . . . . . . 15
   6.  Actions  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  "capabilities" Action  . . . . . . . . . . . . . . . . . . 16
       6.1.1.  Example: Get Capabilities  . . . . . . . . . . . . . . 17
     6.2.  "list" Action  . . . . . . . . . . . . . . . . . . . . . . 19
       6.2.1.  Example: List timezone identifiers . . . . . . . . . . 21
     6.3.  "get" Action . . . . . . . . . . . . . . . . . . . . . . . 21
       6.3.1.  Example: Get timezone  . . . . . . . . . . . . . . . . 23
       6.3.2.  Example: Get timezone alias  . . . . . . . . . . . . . 24
       6.3.3.  Example: Get truncated timezone  . . . . . . . . . . . 24

Douglass & Daboo         Expires August 8, 2014                 [Page 2]lt;https://tools.ietf.org/html/draft-ietf-trill-yang-
              oam-05>.

   [TWAMP-DATA-MODEL]
              Civil, R., Morton, A., Rahman, R., Jethanandani, M., and
              K. Pentikousis, "Two-Way Active Measurement Protocol
              (TWAMP) Data Model", Work in Progress, Internet-Draft,
              draft-ietf-ippm-twamp-yang-13, 2 July 2018,
              <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-
              13>.

   [UNI-TOPOLOGY]
              Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A
              YANG Model for User-Network Interface (UNI) Topologies",
              Work in Progress, Internet-Draft, draft-ogondio-opsawg-
              uni-topology-01, 2 April 2020,
              <https://tools.ietf.org/html/draft-ogondio-opsawg-uni-
              topology-01>.

Appendix A.  Layered YANG Module Examples Overview

   This appendix lists a set of YANG data models that can be used for
   the delivery of connectivity services.  These models can be
   classified as service, network, or device models.

   It is not the intent of this appendix to provide an inventory of
   tools and mechanisms used in specific network and service management
   domains; such inventory can be found in documents such as [RFC7276].

   The reader may refer to the YANG Catalog
   (<https://www.yangcatalog.org>) or the public Github YANG repository
   (<https://github.com/YangModels/yang>) to query existing YANG models.
   The YANG Catalog includes some metadata to indicate the module type
   ('module-classification') [NETMOD-MODEL].  Note that the mechanism
   defined in [RFC8819] allows to associate tags with YANG modules in
   order to help classifying the modules.

A.1.  Service Models: Definition and Samples

   As described in [RFC8309], the service is "some form of connectivity
   between customer sites and the Internet or between customer sites
   across the network operator's network and across the Internet".  More
   concretely, an IP connectivity service can be defined as the IP
   transfer capability characterized by a (Source Nets, Destination
   Nets, Guarantees, Scope) tuple where "Source Nets" is a group of
   unicast IP addresses, "Destination Nets" is a group of IP unicast
   and/or multicast addresses, and "Guarantees" reflects the guarantees
   (expressed, for example, in terms of QoS, performance, and
   availability) to properly forward traffic to the said "Destination"
   [RFC7297].  The "Scope" denotes the network perimeter (e.g., between
   Provider Edge (PE) routers or Customer Nodes) where the said
   guarantees need to be provided.

   For example:

   *  The L3SM [RFC8299] defines the L3VPN service ordered by a customer
      from a network operator.

   *  The L2SM [RFC8466] defines the L2VPN service ordered by a customer
      from a network operator.

   *  The Virtual Network (VN) model [ACTN-VN-YANG] provides a YANG data
      model applicable to any mode of VN operation.

   L2SM and L3SM are customer service models as per [RFC8309].

A.2.  Schema Mount

   Modularity and extensibility were among the leading design principles
   of the YANG data modeling language.  As a result, the same YANG
   module can be combined with various sets of other modules and thus
   form a data model that is tailored to meet the requirements of a
   specific use case.  [RFC8528] defines a mechanism, denoted "schema
   mount", that allows for mounting one data model consisting of any
   number of YANG modules at a specified location of another (parent)
   schema.

A.3.  Network Models: Samples

   L2NM [OPSAWG-L2NM] and L3NM [OPSAWG-L3SM-L3NM] are examples of YANG
   network models.

   Figure 9 depicts a set of additional network models such as topology
   and tunnel models:

     +-------------------------------+-------------------------------+
     |      Topology YANG modules    |     Tunnel YANG modules       |
     +-------------------------------+-------------------------------+
     |  +------------------+         |                               |
     |  |Network Topologies|         | +------+  +-----------+       |
     |  |       Model      |         | |Other |  | TE Tunnel |       |
     |  +--------+---------+         | |Tunnel|  +----+------+       |
     |           |   +---------+     | +------+       |              |
     |           +---+Service  |     |     +----------+---------+    |
     |           |   |Topology |     |     |          |         |    |
     |           |   +---------+     |     |          |         |    |
     |           |   +---------+     |+----+---+ +----+---+ +---+---+|
     |           +---+Layer 3  |     ||MPLS-TE | |RSVP-TE | | SR-TE ||
     |           |   |Topology |     || Tunnel | | Tunnel | |Tunnel ||
     |           |   +---------+     |+--------+ +--------+ +-------+|
     |           |   +---------+     |                               |
     |           +---+TE       |     |                               |
     |           |   |Topology |     |                               |
     |           |   +---------+     |                               |
     |           |   +---------+     |                               |
     |           +---+Layer 3  |     |                               |
     |               |Topology |     |                               |
     |               +---------+     |                               |
     +-------------------------------+-------------------------------+

              Figure 9: Sample Resource-Facing Network Models

   Examples of topology YANG modules are listed below:

   Network Topologies Model:
      [RFC8345] defines a base model for network topology and
      inventories.  Network topology data includes link, node, and
      terminate-point resources.

   TE Topology Model:
      [RFC8795] defines a YANG data model for representing and
      manipulating TE topologies.

      This module is extended from the network topology model defined in
      [RFC8345] and includes content related to TE topologies.  This
      model contains technology-agnostic TE topology building blocks
      that can be augmented and used by other technology-specific TE
      topology models.

   Layer 3 Topology Model:
      [RFC8346] defines a YANG data model for representing and
      manipulating Layer 3 topologies.  This model is extended from the
      network topology model defined in [RFC8345] and includes content
      related to Layer 3 topology specifics.

   Layer 2 Topology Model:
      [RFC8944] defines a YANG data model for representing and
      manipulating Layer 2 topologies.  This model is extended from the
      network topology model defined in [RFC8345] and includes content
      related to Layer 2 topology specifics.

   Examples of tunnel YANG modules are provided below:

   Tunnel Identities:
      [RFC8675] defines a collection of YANG identities used as
      interface types for tunnel interfaces.

   TE Tunnel Model:
      [TEAS-YANG-TE] defines a YANG module for the configuration and
      management of TE interfaces, tunnels, and LSPs.

   Segment Routing (SR) Traffic Engineering (TE) Tunnel Model:
      [TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and
      defines a YANG module for SR-TE-specific data.

   MPLS-TE Model:
      [TEAS-YANG-TE] augments the TE generic and MPLS-TE model(s) and
      defines a YANG module for MPLS-TE configurations, state, RPC, and
      notifications.

   RSVP-TE MPLS Model:
      [TEAS-YANG-RSVP] augments the RSVP-TE generic module with
      parameters to configure and manage signaling of MPLS RSVP-TE LSPs.

   Other sample network models are listed hereafter:

   Path Computation API Model:
      [TEAS-YANG-PATH-COMP] defines a YANG module for a stateless RPC
      that complements the stateful solution defined in [TEAS-YANG-TE].

   OAM Models (including Fault Management (FM) and Performance
   Monitoring):
      [RFC8532] defines a base YANG module for the management of OAM
      protocols that use Connectionless Communications.  [RFC8533]
      defines a retrieval method YANG module for connectionless OAM
      protocols.  [RFC8531] defines a base YANG module for connection-
      oriented OAM protocols.  These three models are intended to
      provide consistent reporting, configuration, and representation
      for connectionless OAM and connection-oriented OAM separately.

      Alarm monitoring is a fundamental part of monitoring the network.
      Raw alarms from devices do not always tell the status of the
      network services or necessarily point to the root cause.
      [RFC8632] defines a YANG module for alarm management.

A.4.  Device Models: Samples

   Network Element models (listed in Figure 10) are used to describe how
   a service can be implemented by activating and tweaking a set of
   functions (enabled in one or multiple devices, or hosted in cloud
   infrastructures) that are involved in the service delivery.  For
   example, the L3VPN service will involve many PEs and require
   manipulating the following modules:

   *  Routing management [RFC8349]

   *  BGP [IDR-BGP-MODEL]

   *  PIM [PIM-YANG]

   *  NAT management [RFC8512]

   *  QoS management [QOS-MODEL]

   *  ACLs [RFC8519]

   Figure 10 uses IETF-defined data models as an example.

                                           +------------------------+
                                         +-+     Device Model       |
                                         | +------------------------+
                                         | +------------------------+
                     +---------------+   | |   Logical Network      |
                     |               |   +-+     Element Model      |
                     | Architecture  |   | +------------------------+
                     |               |   | +------------------------+
                     +-------+-------+   +-+ Network Instance Model |
                             |           | +------------------------+
                             |           | +------------------------+
                             |           +-+   Routing Type Model   |
                             |             +------------------------+
     +-------+----------+----+------+------------+-----------+------+
     |       |          |           |            |           |      |
   +-+-+ +---+---+ +----+----+   +--+--+    +----+----+   +--+--+   |
   |ACL| |Routing| |Transport|   | OAM |    |Multicast|   |  PM | Others
   +---+ +-+-----+ +----+----+   +--+--+    +-----+---+   +--+--+
           | +-------+  | +------+  | +--------+  | +-----+  | +-----+
           +-+Core   |  +-+ MPLS |  +-+  BFD   |  +-+IGMP |  +-+TWAMP|
           | |Routing|  | | Base |  | +--------+  | |/MLD |  | +-----+
           | +-------+  | +------+  | +--------+  | +-----+  | +-----+
           | +-------+  | +------+  +-+LSP Ping|  | +-----+  +-+OWAMP|
           +-+  BGP  |  +-+ MPLS |  | +--------+  +-+ PIM |  | +-----+
           | +-------+  | | LDP  |  | +--------+  | +-----+  | +-----+
           | +-------+  | +------+  +-+MPLS-TP |  | +-----+  +-+LMAP |
           +-+  ISIS |  | +------+    +--------+  +-+ MVPN|    +-----+
           | +-------+  +-+ MPLS |                  +-----+
           | +-------+    |Static|
           +-+  OSPF |    +------+
           | +-------+
           | +-------+
           +-+  RIP  |
           | +-------+
           | +-------+
           +-+  VRRP |
           | +-------+
           | +-------+
           +-+SR/SRv6|
           | +-------+
           | +-------+
           +-+ISIS-SR|
           | +-------+
           | +-------+
           +-+OSPF-SR|
             +-------+

                 Figure 10: Network Element Models Overview

A.4.1.  Model Composition

   Logical Network Element Model:
      [RFC8530] defines a logical network element model that can be used
      to manage the logical resource partitioning that may be present on
      a network device.  Examples of common industry terms for logical
      resource partitioning are Logical Systems or Logical Routers.

   Network Instance Model:
      [RFC8529] defines a network instance module.  This module can be
      used to manage the virtual resource partitioning that may be
      present on a network device.  Examples of common industry terms
      for virtual resource partitioning are VRF instances and Virtual
      Switch Instances (VSIs).

A.4.2.  Device Management

   The following list enumerates some YANG modules that can be used for
   device management:

   *  [RFC8348] defines a YANG module for the management of hardware.

   *  [RFC7317] defines the "ietf-system" YANG module that provides many
      features such as the configuration and the monitoring of system or
      system control operations (e.g., shutdown, restart, and setting
      time) identification.

   *  [RFC8341] defines a network configuration access control YANG
      module.

A.4.3.  Interface Management

   The following provides some YANG modules that can be used for
   interface management:

   *  [RFC7224] defines a YANG module for interface type definitions.

   *  [RFC8343] defines a YANG module for the management of network
      interfaces.

A.4.4.  Some Device Model Examples

   The following provides an overview of some device models that can be
   used within a network.  This list is not comprehensive.

   L2VPN:
      [L2VPN-YANG] defines a YANG module for MPLS-based Layer 2 VPN
      services (L2VPN) [RFC4664] and includes switching between the
      local attachment circuits.  The L2VPN model covers point-to-point
      Virtual Private Wire Service (VPWS) and Multipoint Virtual Private
      LAN Service (VPLS).  These services use signaling of Pseudowires
      across MPLS networks using LDP [RFC8077][RFC4762] or BGP
      [RFC4761].

   EVPN:
      [EVPN-YANG] defines a YANG module for Ethernet VPN services.  The
      model is agnostic of the underlay.  It applies to MPLS as well as
      to Virtual eXtensible Local Area Network (VxLAN) encapsulation.
      The module is also agnostic to the services, including E-LAN,
      E-LINE, and E-TREE services.

   L3VPN:
      [L3VPN-YANG] defines a YANG module that can be used to configure
      and manage BGP L3VPNs [RFC4364].  It contains VRF-specific
      parameters as well as BGP-specific parameters applicable for
      L3VPNs.

   Core Routing:
      [RFC8349] defines the core routing YANG data model, which is
      intended as a basis for future data model development covering
      more-sophisticated routing systems.  It is expected that other
      Routing technology YANG modules (e.g., VRRP, RIP, ISIS, or OSPF
      models) will augment the Core Routing base YANG module.

   MPLS:
      [RFC8960] defines a base model for MPLS that serves as a base
      framework for configuring and managing an MPLS switching
      subsystem.  It is expected that other MPLS technology YANG modules
      (e.g., MPLS LSP Static, LDP, or RSVP-TE models) will augment the
      MPLS base YANG module.

   BGP:
      [IDR-BGP-MODEL] defines a YANG module for configuring and managing
      BGP, including protocol, policy, and operational aspects based on
      data center, carrier, and content provider operational
      requirements.

   Routing Policy:
      [RTGWG-POLICY] defines a YANG module for configuring and managing
      routing policies based on operational practice.  The module
      provides a generic policy framework that can be augmented with
      protocol-specific policy configuration.

   SR/SRv6:
      [SPRING-SR-YANG] defines a YANG module for segment routing
      configuration and operation.

   BFD:
      Bidirectional Forwarding Detection (BFD) [RFC5880] is a network
      protocol that is used for liveness detection of arbitrary paths
      between systems.  [BFD-YANG] defines a YANG module that can be
      used to configure and manage BFD.

   Multicast:
      [PIM-YANG] defines a YANG module that can be used to configure and
      manage Protocol Independent Multicast (PIM) devices.

      [RFC8652] defines a YANG module that can be used to configure and
      manage Internet Group Management Protocol (IGMP) and Multicast
      Listener Discovery (MLD) devices.

      [SNOOPING-YANG] defines a YANG module that can be used to
      configure and manage Internet Group Management Protocol (IGMP) and
      Multicast Listener Discovery (MLD) snooping devices.

      [MVPN-YANG] defines a YANG data model to configure and manage
      Multicast in MPLS/BGP IP VPNs (MVPNs).

   PM:
      [TWAMP-DATA-MODEL] defines a YANG data model for client and server
      implementations of the Two-Way Active Measurement Protocol
      (TWAMP).

      [STAMP-YANG] defines the data model for implementations of
      Session-Sender and Session-Reflector for Simple Two-way Active
      Measurement Protocol (STAMP) mode using YANG.

      [RFC8194] defines a YANG data model for Large-Scale Measurement
      Platforms (LMAPs).

   ACL:
      An Access Control List (ACL) is one of the basic elements used to
      configure device-forwarding behavior.  It is used in many
      networking technologies such as Policy-Based Routing, firewalls,
      etc.  [RFC8519] describes a YANG data model of ACL basic building
      blocks.

   QoS:
      [QOS-MODEL] describes a YANG module of Differentiated Services for
      configuration and operations.

   NAT:
      For the sake of network automation and the need for programming
      the Network Address Translation (NAT) function in particular, a
      YANG data model for configuring and managing the NAT is essential.

      [RFC8512] defines a YANG module for the NAT function covering a
      variety of NAT flavors such as Network Address Translation from
      IPv4 to IPv4 (NAT44), Network Address and Protocol Translation
      from IPv6 Clients to IPv4 Servers (NAT64), customer-side
      translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit
      Address Mappings (EAMs) for SIIT, IPv6-to-IPv6 Network Prefix
      Translation (NPTv6), and Destination NAT.

      [RFC8513] specifies a Dual-Stack Lite (DS-Lite) YANG module.

   Stateless Address Sharing:
      [RFC8676] specifies a YANG module for Address plus Port (A+P)
      address sharing, including Lightweight 4over6, Mapping of Address
      and Port with Encapsulation (MAP-E), and Mapping of Address and
      Port using Translation (MAP-T) softwire mechanisms.

Acknowledgements

   Thanks to Joe Clark, Greg Mirsky, Shunsuke Homma, Brian Carpenter,
   Adrian Farrel, Christian Huitema, Tommy Pauly, Ines Robles, and
   Olivier Augizeau for the review.

   Many thanks to Robert Wilton for the detailed AD review.

   Thanks to Éric Vyncke, Roman Danyliw, Erik Kline, and Benjamin Kaduk
   for the IESG review.

Contributors

   Christian Jacquenet
   Orange
   Rennes, 35000
   France

   Email: Christian.jacquenet@orange.com

   Luis Miguel Contreras Murillo
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com

   Oscar Gonzalez de Dios
   Telefonica
   Madrid
   Spain

   Email: oscar.gonzalezdedios@telefonica.com

   Weiqiang Cheng
   China Mobile

   Email: chengweiqiang@chinamobile.com

   Young Lee
   Sung Kyun Kwan University

   Email: younglee.tx@gmail.com

Authors' Addresses

   Qin Wu (editor)
   Huawei
   101 Software Avenue
   Yuhua District
   Nanjing
   Jiangsu, 210012
   China

   Email: bill.wu@huawei.com

   Mohamed Boucadair (editor)
   Orange
   Rennes 35000
   France

   Email: mohamed.boucadair@orange.com

   Diego R. Lopez
   Telefonica I+D
   Spain

   Email: diego.r.lopez@telefonica.com

   Chongfeng Xie
   China Telecom
   Beijing
   China

   Email: xiechf@chinatelecom.cn

   Liang Geng
   China Mobile

   Email: gengliang@chinamobile.com