Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols
RFC 8531
| Document | Type | RFC - Proposed Standard (April 2019) Errata | |
|---|---|---|---|
| Authors | Deepak Kumar , Qin Wu , Zitao Wang | ||
| Last updated | 2020-01-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Benoît Claise | |
| Send notices to | (None) |
RFC 8531
ANIMA WG M. Behringer, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track T. Eckert
Expires: July 15, 2017
S. Bjarnason
Arbor Networks
January 11, 2017
An Autonomic Control Plane
draft-ietf-anima-autonomic-control-plane-05
Abstract
Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of
configuration. This document defines an "Autonomic Control Plane",
with the primary use as a control plane for autonomic functions. It
also serves as a "virtual out of band channel" for OAM communications
over a network that is not configured, or mis-configured.
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 July 15, 2017.
Copyright Notice
Copyright (c) 2017 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
Behringer, et al. Expires July 15, 2017 [Page 1]
Internet-Draft An Autonomic Control Plane January 2017
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
2. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4
2.1. An Infrastructure for Autonomic Functions . . . . . . . . 4
2.2. Secure Bootstrap over an Unconfigured Network . . . . . . 5
2.3. Data Plane Independent Permanent Reachability . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Self-Creation of an Autonomic Control Plane . . . . . . . . . 8
5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Domain Certificate with ANIMA information . . . . . . 8
5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9
5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 10
5.2.1. L2 topology considerations . . . . . . . . . . . . . 10
5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 11
5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 11
5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 12
5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 12
5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 13
5.5. Security Association protocols . . . . . . . . . . . . . 14
5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 15
5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 15
5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 15
5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 15
5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 16
5.6. GRASP instance details . . . . . . . . . . . . . . . . . 16
5.7. Context Separation . . . . . . . . . . . . . . . . . . . 16
5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 17
5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 17
5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 18
5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 19
5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 20
5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 21
5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 21
5.10. General ACP Considerations . . . . . . . . . . . . . . . 21
6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 22
6.1. Connecting a Non-Autonomic Controller / NMS system . . . 22
6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 23
7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 23
8. Self-Protection Properties . . . . . . . . . . . . . . . . . 24
9. The Administrator View . . . . . . . . . . . . . . . . . . . 25
quot;Time interval between echo requests.";
}
Kumar, et al. Standards Track [Page 38]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
leaf packet-size {
type uint32 {
range "64..10000";
}
description
"Size of continuity-verification packets, in octets.";
}
}
output {
uses monitor-stats {
description
"Stats of Continuity Check.";
}
}
}
rpc traceroute {
if-feature "traceroute";
description
"Generates Traceroute or Path Trace and returns response.
References RFC 7276 for common Toolset name -- for
MPLS-TP OAM, it's Route Tracing, and for TRILL OAM, it's
Path Tracing tool. Starts with TTL of one and increments
by one at each hop until the destination is reached or TTL
reaches max value.";
input {
leaf md-name-string {
type leafref {
path "/domains/domain/md-name-string";
}
mandatory true;
description
"Indicate which MD the defect belongs to.";
}
leaf md-level {
type leafref {
path "/domains/domain/md-level";
}
description
"The Maintenance Domain Level.";
}
leaf ma-name-string {
type leafref {
path "/domains/domain/mas/ma/ma-name-string";
}
mandatory true;
description
"Indicate which MA the defect is associated with.";
Kumar, et al. Standards Track [Page 39]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
}
uses cos;
uses time-to-live;
leaf command-sub-type {
type identityref {
base command-sub-type;
}
description
"Defines different command types.";
}
leaf source-mep {
type leafref {
path "/domains/domain/mas/ma/mep/mep-name";
}
description
"Source MEP.";
}
container destination-mep {
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
description
"Destination MEP.";
}
leaf count {
type uint32;
default "1";
description
"Number of traceroute probes to send. In protocols where a
separate message is sent at each TTL, this is the number
of packets to be sent at each TTL.";
}
leaf interval {
type time-interval;
description
"Time interval between echo requests.";
}
}
output {
list response {
key "response-index";
leaf response-index {
type uint8;
description
"Arbitrary index for the response. In protocols that
guarantee there is only a single response at each TTL,
Kumar, et al. Standards Track [Page 40]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
the TTL can be used as the response index.";
}
uses time-to-live;
container destination-mep {
description
"MEP from which the response has been received";
uses mep-address;
uses mep-id {
description
"Only applicable if the destination is a MEP.";
}
}
container mip {
if-feature "mip";
leaf interface {
type if:interface-ref;
description
"MIP interface.";
}
uses mip-address;
description
"MIP responding with traceroute";
}
uses monitor-stats {
description
"Stats of traceroute.";
}
description
"List of responses.";
}
}
}
}
<CODE ENDS>
Kumar, et al. Standards Track [Page 41]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
6. Base Mode
The Base Mode ("default mode" described in Section 4) defines the
default configuration that MUST be present in the devices that comply
with this document. Base Mode allows users to have a "zero-touch"
experience. Several parameters require technology-specific
definition.
6.1. MEP Address
In the Base Mode of operation, the MEP Address is by default the IP
address of the interface on which the MEP is located.
6.2. MEP ID for Base Mode
In the Base Mode of operation, each device creates a single MEP
associated with a virtual OAM port with no physical layer (NULL PHY).
The MEP-ID associated with this MEP is zero (0). The choice of
MEP-ID of zero is explained below.
MEP-ID is a 2-octet field by default. It is never used on the wire
except when using CCM. It is important to have a method that can
derive the MEP-ID of Base Mode in an automatic manner with no user
intervention. The IP address cannot be directly used for this
purpose, as the MEP-ID is a much smaller field. For the Base Mode of
operation, MEP-ID is set to zero by default.
The CCM packet uses the MEP-ID in the payload. CCM MUST NOT be used
in the Base Mode. Hence, CCM MUST be disabled on the Maintenance
Association of the Base Mode.
If CCM is required, users MUST configure a separate Maintenance
Association and assign unique values for the corresponding MEP IDs.
CFM [IEEE802.1Q] defines MEP-ID as an unsigned integer in the range 1
to 8191. In this document, we propose extending the range to 0 to
65535. Value 0 is reserved for the MEP-ID in the Base Mode operation
and MUST NOT be used for other purposes.
6.3. Maintenance Association
The ID of the Maintenance Association (MA-ID) [IEEE802.1Q] has a
flexible format and includes two parts: Maintenance Domain Name and
Short MA name. In the Base Mode of operation, the value of the
Maintenance Domain Name must be the character string
"GenericBaseMode" (excluding the quotes). In the Base Mode
Kumar, et al. Standards Track [Page 42]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
operation, the Short MA Name format is set to a 2-octet integer
format (value 3 in Short MA Format field [IEEE802.1Q]) and the Short
MA name is set to 65532 (0xFFFC).
7. Connection-Oriented OAM YANG Data Model Applicability
The "ietf-connection-oriented-oam" module defined in this document
provides a technology-independent abstraction of key OAM constructs
for connection-oriented protocols. This module can be further
extended to include technology-specific details, e.g., adding new
data nodes with technology-specific functions and parameters into
proper anchor points of the base model, so as to develop a
technology-specific connection-oriented OAM model.
This section demonstrates the usability of the connection-oriented
YANG OAM data model to various connection-oriented OAM technologies,
e.g., TRILL and MPLS-TP. Note that, in this section, we only present
several snippets of technology-specific model extensions for
illustrative purposes. The complete model extensions should be
worked on in respective protocol working groups.
7.1. Generic YANG Data Model Extension for TRILL OAM
The TRILL OAM YANG module [TRILL-YANG-OAM] is augmenting the
connection-oriented OAM module for both configuration and RPC
commands.
In addition,the TRILL OAM YANG module also requires the base TRILL
module ([TRILL-YANG]) to be supported, as there is a strong
relationship between those modules.
The configuration extensions for connection-oriented OAM include the
MD configuration extension, technology type extension, MA
configuration extension, Connectivity-Context extension, MEP
Configuration extension, and ECMP extension. In the RPC extension,
the continuity-check and path-discovery RPC are extended with TRILL-
specific parameters.
7.1.1. MD Configuration Extension
MD level configuration parameters are management information that can
be inherited in the TRILL OAM model and set by the connection-
oriented base model as default values. For example, domain name can
be set to area-ID in the TRILL OAM case. In addition, at the
Maintenance Domain Level (i.e., at root level), the domain data node
can be augmented with technology type.
Kumar, et al. Standards Track [Page 43]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
Note that MD level configuration parameters provide context
information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly
identify root causes of network failures.
7.1.1.1. Technology Type Extension
No TRILL technology type has been defined in the connection-oriented
base model. Therefore, a technology type extension is required in
the TRILL OAM model. The technology type "trill" is defined as an
identity that augments the base "technology-types" defined in the
connection-oriented base model:
identity trill{
base co-oam:technology-types;
description
"trill type";
}
7.1.2. MA Configuration Extension
MA level configuration parameters are management information that can
be inherited in the TRILL OAM model and set by the connection-
oriented base model as default values. In addition, at the
Maintenance Association (MA) level (i.e., at the second level), the
MA data node can be augmented with a connectivity-context extension.
Note that MA level configuration parameters provide context
information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly
identify root causes of network failures.
7.1.2.1. Connectivity-Context Extension
In TRILL OAM, one example of connectivity-context is either a 12-bit
VLAN ID or a 24-bit Fine-Grained Label. The connection-oriented base
model defines a placeholder for context-id. This allows other
technologies to easily augment that to include technology-specific
extensions. The snippet below depicts an example of augmenting
connectivity-context to include either a VLAN ID or Fine-Grained
Label.
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:connectivity-context:
+--:(connectivity-context-vlan)
| +--rw connectivity-context-vlan? vlan
+--:(connectivity-context-fgl)
+--rw connectivity-context-fgl? fgl
Kumar, et al. Standards Track [Page 44]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
7.1.3. MEP Configuration Extension
The MEP configuration definition in the connection-oriented base
model already supports configuring the interface of MEP with either a
MAC address or IP address. In addition, the MEP address can be
represented using a 2-octet RBridge Nickname in TRILL OAM. Hence,
the TRILL OAM model augments the MEP configuration in the base model
to add a nickname case to the MEP address choice node as follows:
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:mep-address:
+--:( mep-address-trill)
| +--rw mep-address-trill? tril-rb-nickname
In addition, at the Maintenance association End Point (MEP) level
(i.e., at the third level), the MEP data node can be augmented with
an ECMP extension.
7.1.3.1. ECMP Extension
Since TRILL supports ECMP path selection, flow-entropy in TRILL is
defined as a 96-octet field in the Layer-Independent OAM Management
in the Multi-Layer Environment (LIME) model extension for TRILL OAM.
The snippet below illustrates its extension.
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep:
+--rw flow-entropy-trill? flow-entropy-trill
augment /co-oam:domains/co-oam:domain
/co-oam:mas/co-oam:ma/co-oam:mep/co-oam:session:
+--rw flow-entropy-trill? flow-entropy-trill
Kumar, et al. Standards Track [Page 45]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
7.1.4. RPC Extension
In the TRILL OAM YANG data model, the continuity-check and path-
discovery RPC commands are extended with TRILL-specific requirements.
The snippet below depicts an example of the TRILL OAM RPC extension.
augment /co-oam:continuity-check/co-oam:input:
+--ro (out-of-band)?
| +--:(ipv4-address)
| | +--ro ipv4-address? inet:ipv4-address
| +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean
augment /co-oam:continuity-check/co-oam:input:
+--ro flow-entropy-trill? flow-entropy-trill
augment /co-oam:continuity-check/co-oam:output:
+--ro upstream-rbridge? tril-rb-nickname
+--ro next-hop-rbridge* tril-rb-nickname
augment /co-oam:path-discovery/co-oam:input:
+--ro (out-of-band)?
| +--:(ipv4-address)
| | +--ro ipv4-address? inet:ipv4-address
| +--:(ipv6-address)
| | +--ro ipv6-address? inet:ipv6-address
| +--:(trill-nickname)
| +--ro trill-nickname? tril-rb-nickname
+--ro diagnostic-vlan? boolean
augment /co-oam:path-discovery/co-oam:input:
+--ro flow-entropy-trill? flow-entropy-trill
augment /co-oam:path-discovery/co-oam:output/co-oam:response:
+--ro upstream-rbridge? tril-rb-nickname
+--ro next-hop-rbridge* tril-rb-nickname
7.2. Generic YANG Data Model Extension for MPLS-TP OAM
The MPLS-TP OAM YANG module can augment the connection-oriented OAM
module with some technology-specific details. [MPLS-TP-OAM-YANG]
presents the YANG data model for MPLS-TP OAM.
The configuration extensions for connection-oriented OAM include the
MD configuration extension, Technology type extension, Technology
Subtype extension, MA configuration extension, and MEP Configuration
extension.
Kumar, et al. Standards Track [Page 46]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
7.2.1. MD Configuration Extension
MD level configuration parameters are management information that can
be inherited in the MPLS-TP OAM model and set by the connection-
oriented OAM base model as default values. For example, domain name
can be set to area-ID or the provider's Autonomous System Number
(ASN) [RFC6370] in the MPLS-TP OAM case. In addition, at the
Maintenance Domain Level (i.e., at root level), the domain data node
can be augmented with technology type and technology subtype.
Note that MD level configuration parameters provide context
information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly
identify root causes of network failures
7.2.1.1. Technology Type Extension
No MPLS-TP technology type has been defined in the connection-
oriented base model, hence it is required in the MPLS-TP OAM model.
The technology type "mpls-tp" is defined as an identity that augments
the base "technology-types" defined in the connection-oriented base
model:
identity mpls-tp{
base co-oam:technology-types;
description
"mpls-tp type";
}
7.2.1.2. Technology Subtype Extension
In MPLS-TP, since different encapsulation types such as IP/UDP
encapsulation and PW-ACH encapsulation can be employed, the
"technology-sub-type" data node is defined and added into the MPLS-TP
OAM model to further identify the encapsulation types within the
MPLS-TP OAM model. Based on it, we also define a technology subtype
for IP/UDP encapsulation and PW-ACH encapsulation. Other
encapsulation types can be defined in the same way. The snippet
below depicts an example of several encapsulation types.
Kumar, et al. Standards Track [Page 47]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
identity technology-sub-type {
description
"Certain implementations can have different
encapsulation types such as IP/UDP, PW-ACH, and so on.
Instead of defining separate models for each
encapsulation, we define a technology subtype to
further identify different encapsulations.
Technology subtype is associated at the MA level."; }
identity technology-sub-type-udp {
base technology-sub-type;
description
"Technology subtype is IP/UDP encapsulation.";
}
identity technology-sub-type-ach {
base technology-sub-type;
description
"Technology subtype is PW-ACH encapsulation.";
}
}
augment "/co-oam:domains/co-oam:domain"
+ "/co-oam:mas/co-oam:ma" {
leaf technology-sub-type {
type identityref {
base technology-sub-type;
}
}
}
7.2.2. MA Configuration Extension
MA level configuration parameters are management information that can
be inherited in the MPLS-TP OAM model and set by the connection-
oriented OAM base model as default values. Examples of MA Name are
MPLS-TP LSP MEG_ID, MEG Section ID, or MEG PW ID [RFC6370].
Note that MA level configuration parameters provide context
information for the management system to correlate faults, defects,
and network failures with location information; this helps quickly
identify root causes of network failures.
7.2.3. MEP Configuration Extension
In MPLS-TP, MEP-ID is either a variable-length label value in case of
G-ACH encapsulation or a 2-octet unsigned integer value in case of
IP/UDP encapsulation. One example of MEP-ID is MPLS-TP LSP_MEP_ID
Kumar, et al. Standards Track [Page 48]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
[RFC6370]. In the connection-oriented base model, MEP-ID is defined
as a choice/case node that can support an int32 value, and the same
definition can be used for MPLS-TP with no further modification. In
addition, at the Maintenance association End Point (MEP) level (i.e.,
at the third level), the MEP data node can be augmented with a
session extension and interface extension.
8. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model [RFC8341] provides the
means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in the YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive in some
network environments. Write operations (e.g., edit-config) to these
data nodes without proper protection can have a negative effect on
network operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:
/co-oam:domains/co-oam:domain/
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep
/co-oam:domains/co-oam:domain/co-oam:mas/co-oam:ma/co-oam:mep/
co-oam:session
Unauthorized access to any of these lists can adversely affect OAM
management system handling of end-to-end OAM and coordination of OAM
within underlying network layers. This may lead to inconsistent
configuration, reporting, and presentation for the OAM mechanisms
used to manage the network.
Kumar, et al. Standards Track [Page 49]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
9. IANA Considerations
This document registers a URI in the "IETF XML Registry" [RFC3688].
The following registration has been made:
URI: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document registers a YANG module in the "YANG Module Names"
registry [RFC6020].
name: ietf-connection-oriented-oam
namespace: urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam
prefix: co-oam
reference: RFC 8531
10. References
10.1. Normative References
[IEEE802.1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks-Bridges and Bridged Networks", IEEE Std 802.1Q.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
Kumar, et al. Standards Track [Page 50]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<https://www.rfc-editor.org/info/rfc6370>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
10.2. Informative References
[G.800] "Unified functional architecture of transport networks",
ITU-T Recommendation G.800, 2016.
[G.8013] "OAM functions and mechanisms for Ethernet based
networks", ITU-T Recommendation G.8013/Y.1731, 2013.
[MEF-17] MEF Forum, "Service OAM Requirements & Framework - Phase
1&Behringer, et al. Expires July 15, 2017 [Page 2]
Internet-Draft An Autonomic Control Plane January 2017
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 27
13.1. Initial version . . . . . . . . . . . . . . . . . . . . 27
13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 27
13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 27
13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 27
13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 27
13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 28
13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 28
13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 29
13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 29
13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 29
13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Background on the choice of routing protocol . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is currently being defined in the
document [I-D.ietf-anima-reference-model]
Autonomic functions need a stable and robust infrastructure to
communicate on. This infrastructure should be as robust as possible,
and it should be re-usable by all autonomic functions. [RFC7575]
calls it the "Autonomic Control Plane". This document defines the
Autonomic Control Plane.
Today, the management and control plane of networks typically runs in
the global routing table, which is dependent on correct configuration
and routing. Misconfigurations or routing problems can therefore
disrupt management and control channels. Traditionally, an out of
band network has been used to recover from such problems, or
personnel is sent on site to access devices through console ports
(craft ports). However, both options are operationally expensive.
In increasingly automated networks either controllers or distributed
autonomic service agents in the network require a control plane which
is independent of the network they manage, to avoid impacting their
own operations.
Behringer, et al. Expires July 15, 2017 [Page 3]
Internet-Draft An Autonomic Control Plane January 2017
This document describes options for a self-forming, self-managing and
self-protecting "Autonomic Control Plane" (ACP) which is inband on
the network, yet as independent as possible of configuration,
addressing and routing problems (for details how this achieved, see
Section 5). It therefore remains operational even in the presence of
configuration errors, addressing or routing issues, or where policy
could inadvertently affect control plane connectivity. The Autonomic
Control Plane serves several purposes at the same time:
o Autonomic functions communicate over the ACP. The ACP therefore
supports directly Autonomic Networking functions, as described in
[I-D.ietf-anima-reference-model]. For example, GRASP
[I-D.ietf-anima-grasp] can run securely inside the ACP.
o An operator can use it to log into remote devices, even if the
data plane is misconfigured or unconfigured.
o A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the network
in between is not yet configured; no data-plane dependent
bootstrap configuration is required. An example of such a secure
bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra]
This document describes some use cases for the ACP in Section 2, it
defines the requirements in Section 3, Section 4 gives an overview
how an Autonomic Control Plane is constructed, and in Section 5 the
detailed process is explained. Section 6 explains how non-autonomic
nodes and networks can be integrated, and Section 5.5 the first
channel types for the ACP.
The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] describes how the ACP can be
used to provide stable connectivity for OAM applications. It also
explains on how existing management solutions can leverage the ACP in
parallel with traditional management models, when to use the ACP
versus the data plane, how to integrate IPv4 based management, etc.
2. Use Cases for an Autonomic Control Plane
2.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimise
the complexity of the network. This way, there is only need for a
single discovery mechanism, a single security mechanism, and other
processes that distributed functions require.
Behringer, et al. Expires July 15, 2017 [Page 4]
Internet-Draft An Autonomic Control Plane January 2017
2.2. Secure Bootstrap over an Unconfigured Network
Today, bootstrapping a new device typically requires all devices
between a controlling node (such as an SDN controller) and the new
device to be completely and correctly addressed, configured and
secured. Therefore, bootstrapping a network happens in layers around
the controller. Without console access (for example through an out
of band network) it is not possible today to make devices securely
reachable before having configured the entire network between.
With the ACP, secure bootstrap of new devices can happen without
requiring any configuration on the network. A new device can
automatically be bootstrapped in a secure fashion and be deployed
with a domain certificate. This does not require any configuration
on intermediate nodes, because they can communicate through the ACP.
2.3. Data Plane Independent Permanent Reachability
Today, most critical control plane protocols and network management
protocols are running in the data plane (global routing table) of the
network. This leads to undesirable dependencies between control and
management plane on one side and the data plane on the other: Only if
the data plane is operational, will the other planes work as
expected.
Data plane connectivity can be affected by errors and faults, for
example certain AAA misconfigurations can lock an administrator out
of a device; routing or addressing issues can make a device
unreachable; shutting down interfaces over which a current management
session is running can lock an admin irreversibly out of the device.
Traditionally only console access can help recover from such issues.
Data plane dependencies also affect NOC/SDN controller applications:
Certain network changes are today hard to operate, because the change
itself may affect reachability of the devices. Examples are address
or mask changes, routing changes, or security policies. Today such
changes require precise hop-by-hop planning.
The ACP provides reachability that is largely independent of the data
plane, which allows control plane and management plane to operate
more robustly:
o For management plane protocols, the ACP provides the functionality
of a "Virtual-out-of-band (VooB) channel", by providing
connectivity to all devices regardless of their configuration or
global routing table.
Behringer, et al. Expires July 15, 2017 [Page 5]
Internet-Draft An Autonomic Control Plane January 2017
o For control plane protocols, the ACP allows their operation even
when the data plane is temporarily faulty, or during transitional
events, such as routing changes, which may affect the control
plane at least temporarily. This is specifically important for
autonomic service agents, which could affect data plane
connectivity.
The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] explains the use cases for the
ACP in significantly more detail and explains how the ACP can be used
in practical network operations.
3. Requirements
The Autonomic Control Plane has the following requirements:
ACP1: The ACP SHOULD provide robust connectivity: As far as
possible, it should be independent of configured addressing,
configuration and routing. Requirements 2 and 3 build on this
requirement, but also have value on their own.
ACP2: The ACP MUST have a separate address space from the data
plane. Reason: traceability, debug-ability, separation from
data plane, security (can block easily at edge).
ACP3: The ACP MUST use autonomically managed address space. Reason:
easy bootstrap and setup ("autonomic"); robustness (admin
can't mess things up so easily). This document suggests to
use ULA addressing for this purpose.
ACP4: The ACP MUST be generic. Usable by all the functions and
protocols of the AN infrastructure. It MUST NOT be tied to a
particular protocol.
ACP5: The ACP MUST provide security: Messages coming through the ACP
MUST be authenticated to be from a trusted node, and SHOULD
(very strong SHOULD) be encrypted.
The default mode of operation of the ACP is hop-by-hop, because this
interaction can be built on IPv6 link local addressing, which is
autonomic, and has no dependency on configuration (requirement 1).
It may be necessary to have ACP connectivity over non-autonomic
nodes, for example to link autonomic nodes over the general Internet.
This is possible, but then has a dependency on routing over the non-
autonomic hops.
Behringer, et al. Expires July 15, 2017 [Page 6]
Internet-Draft An Autonomic Control Plane January 2017
4. Overview
The Autonomic Control Plane is constructed in the following way (for
details, see Section 5):
1. An autonomic node creates a virtual routing and forwarding (VRF)
instance, or a similar virtual context.
2. It determines, following a policy, a candidate peer list. This
is the list of nodes to which it should establish an Autonomic
Control Plane. Default policy is: To all adjacent nodes in the
same domain.
3. For each node in the candidate peer list, it authenticates that
node and negotiates a mutually acceptable channel type.
4. It then establishes a secure tunnel of the negotiated channel
type. These tunnels are placed into the previously set up VRF.
This creates an overlay network with hop-by-hop tunnels.
5. Inside the ACP VRF, each node sets up a virtual interface with
its ULA IPv6 address.
6. Each node runs a lightweight routing protocol, to announce
reachability of the virtual addresses inside the ACP.
Note:
o Non-autonomic NMS systems or controllers have to be manually
connected into the ACP.
o Connecting over non-autonomic Layer-3 clouds initially requires a
tunnel between autonomic nodes.
o None of the above operations (except manual ones) is reflected in
the configuration of the device.
The following figure illustrates the ACP.
Behringer, et al. Expires July 15, 2017 [Page 7]
quot;, MEF 17, April 2007.
[MPLS-TP-OAM-YANG]
Zhang, L., Zheng, L., Aldrin, S., and G. Mirsky, "YANG
Data Model for MPLS-TP Operations, Administration, and
Maintenance (OAM)", Work in Progress, draft-zhang-mpls-tp-
yang-oam-05, October 2017.
Kumar, et al. Standards Track [Page 51]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
<https://www.rfc-editor.org/info/rfc6325>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R.
Watve, "Requirements for Operations, Administration, and
Maintenance (OAM) in Transparent Interconnection of Lots
of Links (TRILL)", RFC 6905, DOI 10.17487/RFC6905, March
2013, <https://www.rfc-editor.org/info/rfc6905>.
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
3rd, "Transparent Interconnection of Lots of Links (TRILL)
Operations, Administration, and Maintenance (OAM)
Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014,
<https://www.rfc-editor.org/info/rfc7174>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
3rd, D., Aldrin, S., and Y. Li, "Transparent
Interconnection of Lots of Links (TRILL): Fault
Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,
<https://www.rfc-editor.org/info/rfc7455>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
Kumar, et al. Standards Track [Page 52]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
[RFC8532] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and
S. Raghavan, "Generic YANG Data Model for the Management
of Operations, Administration, and Maintenance (OAM)
Protocols That Use Connectionless Communications",
RFC 8532, DOI 10.17487/RFC8532, April 2019,
<https://www.rfc-editor.org/info/rfc8532>.
[TRILL-YANG]
Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H.,
and L. Xia, "TRILL YANG Data Model", Work in Progress,
draft-ietf-trill-yang-04, December 2015.
[TRILL-YANG-OAM]
Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
and H. Weiguo, "YANG Data Model for TRILL Operations,
Administration, and Maintenance (OAM)", Work in Progress,
draft-ietf-trill-yang-oam-05, March 2017.
Acknowledgments
Giles Heron came up with the idea of developing a YANG data model as
a way of creating a unified OAM API set (interface); this document
was largely inspired by that. Alexander Clemm provided many valuable
tips, comments, and remarks that helped to refine the YANG data model
presented in this document.
Carlos Pignataro, David Ball, Mahesh Jethanandani, Benoit Claise,
Ladislav Lhotka, Jens Guballa, Yuji Tochio, Gregory Mirsky, Huub van
Helvoort, Tom Taylor, Dapeng Liu, Mishael Wexler, and Adi Molkho
contributed to and participated in the development of this document.
Contributors
Tissa Senevirathne
Consultant
Email: tsenevir@gmail.com
Norman Finn
CISCO Systems
510 McCarthy Blvd
Milpitas, CA 95035
United States of America
Email: nfinn@cisco.com
Kumar, et al. Standards Track [Page 53]
RFC 8531 Connection-Oriented OAM YANG Data Model April 2019
Samer Salam
CISCO Systems
595 Burrard St. Suite 2123
Vancouver, BC V7X 1J1
Canada
Email: ssalam@cisco.com
Authors' Addresses
Deepak Kumar
CISCO Systems
510 McCarthy Blvd
Milpitas, CA 95035
United States of America
Email: dekumar@cisco.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Michael Wang
Huawei Technologies, Co., Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: wangzitao@huawei.com
Kumar, et al. Standards Track [Page 54]