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