l2tpext Working Group Q. Sun
Internet-Draft I. Farrer
Intended status: Standards Track Deutsche Telekom AG
Expires: January 7, 2016 B. Liu
Huawei Technologies
G. Heron
Cisco Systems
July 6, 2015
A YANG Data Model for Keyed IPv6 Tunnels
draft-sun-l2tpext-keyed-v6-tunnel-yang-01
Abstract
This document defines a YANG data model for the configuration and
management of Keyed IPv6 tunnels. The data model includes
configuration data and state data. Due to the stateless nature of
keyed IPv6 tunnels, a model for NETCONF notifications is not
necessary.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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 January 7, 2016.
Sun, et al. Expires January 7, 2016 [Page 1]
Internet-Draft YANG for softwire July 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Notations . . . . . . . . . . . . . . . 3
1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 3
1.1.3. YANG Terms . . . . . . . . . . . . . . . . . . . . . 3
1.1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 3
2. YANG Model Overview . . . . . . . . . . . . . . . . . . . . . 4
3. Keyed IPv6 Tunnel YANG Tree Diagrams . . . . . . . . . . . . 4
4. Keyed IPv6 Tunnel YANG Model . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Keyed IPv6 Tunnels [I-D.ietf-l2tpext-keyed-ipv6-tunnel] defines a
mechanism for transporting L2 Ethernet frames over IPv6 using L2TPv3
tunnel encapsulation with a mandatory 64-bit cookie. This is used
for connecting L2 Ethernet circuits identified by their IPv6
addresses. It is a static L2 tunnelling mechanism that leverages the
key property that IPv6 offers: a vast number of unique IP addresses,
to identify a tunnel. This differs from differentiating tunnels
based on Session ID as defined in [RFC3931]. The layer 2 circuit is
mapped to an IPv6 address on the network side so typically, there is
a "one session per tunnel" pattern.
Since the control plane of L2TPv3 is not used by Keyed IPv6 tunnels,
Sun, et al. Expires January 7, 2016 [Page 2]
Internet-Draft YANG for softwire July 2015
the parameters for running Keyed IPv6 tunnel need to be pre-
configured. NETCONF [RFC6241]/YANG [RFC6020] provide mechanisms for
such configuration. This document defines a YANG data model for the
configuration and management of Keyed IPv6 Tunnels.
1.1. Terminology
1.1.1. Requirements Notations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.1.2. NETCONF Terms
The following terms are defined in [RFC6241] and are not redefined
here:
o Client
o Server
o Operation
1.1.3. YANG Terms
The following terms are defined in [RFC6020] and are not redefined
here:
o configuration data
o data node
o data tree
o module
o namespace
o YANG
1.1.4. Tree Diagrams
A simplified graphical representation of the data model is provided
in this document. The meaning of the symbols in these diagrams is as
follows:
o Brackets "[" and "]" enclose list keys.
Sun, et al. Expires January 7, 2016 [Page 3]
Internet-Draft YANG for softwire July 2015
o Abbreviations before data node names: "rw" means configuration
data (read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2. YANG Model Overview
The YANG model includes two modules, one for configuration and one
for state. To correctly identify a tunnel and create the mapping
between the L2 circuit and the IPv6 address, the tuple of source
interface, local IPv6 address and remote IPv6 address MUST be unique.
Because Session ID is not mandatory for a Keyed IPv6 tunnel to
function, Session ID related parameters are optional in the model.
Cookies MUST be 64-bit long according to the Section 3 of
[I-D.ietf-l2tpext-keyed-ipv6-tunnel]. The requirement for 64-bit
cookie constrains interoperability with existing RFC3931
implementations to those configured with a 64-bit cookie.
The data model also includes read-only counters so that statistics
for sent and received octets and packets, received packets with
errors, and packets that could not be sent due to errors can be read.
This model defines three features for OAM parameters. Those features
enable devices to perform related OAM operations on the tunnel if
related functions are supported.
3. Keyed IPv6 Tunnel YANG Tree Diagrams
This section describes the tree diagram for the Keyed IPv6 Tunnel
YANG model:
Sun, et al. Expires January 7, 2016 [Page 4]
Internet-Draft YANG for softwire July 2015
module: ietf-keyed-v6-tunnel
+--rw tunnelConfigurations
| +--rw tunnelConfiguration* [tunnelName]
| | +--rw tunnelName string
| | +--rw srcInterface if:interface-ref
| | +--rw localIPv6 inet:ipv6-address
| | +--rw remoteIPv6 inet:ipv6-address
| | +--rw localSessionId? uint32
| | +--rw remoteSessionId? uint32
| | +--rw localCookies
| | | +--rw localCookie* [cookieName]
| | | +--rw cookieName string
| | | +--rw cookieValue uint64
| | +--rw remoteCookie uint64
| | +--rw retainFCS? empty
| | +--rw enable-vccv!
| | | +--rw enable-bfd? empty
| | +--rw enable-bfd? empty
| +--rw disable-pmtu? empty
| +--rw enable-fragmentation!
| +--rw fragment-mru? uint16
+--ro tunnelStates
+--ro tunnelState* [tunnelName]
+--ro tunnelName string
+--ro sentPacket? yang:zero-based-counter64
+--ro sentByte? yang:zero-based-counter64
+--ro rcvdPacket? yang:zero-based-counter64
+--ro rcvdByte? yang:zero-based-counter64
+--ro droppedPacket? yang:zero-based-counter64
+--ro droppedByte? yang:zero-based-counter64
+--ro fragmentCounter? yang:zero-based-counter64
Figure 1: Keyed IPv6 Tunnel Tree
The data model defines a configuration container and a state
container.
In the configuration container, "srcInterface" is used to identify a
L2 circuit endpoint. "localIPv6" and "remoteIPv6" respectively
represent the local (source) and remote (destination) IPv6 addresses
for the tunnel. The srcInterface and localIPv6 both uniquely
identify a tunnel endpoint. If a virtual interface is used, the
localIPv6 and remoteIPv6 as a pair MUST also be unique. "localCookie"
is a list and has two cookies: one is the newly configured cookie,
and the other is previously configured. This is used for the purpose
of correctly receiving packets while changing cookies.
Sun, et al. Expires January 7, 2016 [Page 5]
Internet-Draft YANG for softwire July 2015
Features are defined for FCS-Retention, VCCV, BFD, VCCV-BFD and
fragmentation, so that devices supporting those features (or some of
which) can enable related functions.
4. Keyed IPv6 Tunnel YANG Model
This module imports typedefs from [RFC6991] and [RFC7223].
<CODE BEGINS> file "ietf-keyed-v6-tunnel@2015-07-06.yang"
module ietf-keyed-v6-tunnel {
namespace "urn:ietf:params:xml:ns:yang:ietf-keyed-v6-tunnel";
prefix k6tun;
import ietf-interfaces {
prefix if;
}
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
organization "IETF l2tpext Working Group";
contact
"qui.sun@external.telekom.de
ian.farrer@telekom.de
leo.liubing@huawei.com
giheron@cisco.com
";
description
"Keyed IPv6 L2TPv3 Tunnel";
revision 2015-07-06 {
description
"General clean-up"
;
reference
"draft-sun-l2tpext-keyed-v6-tunnel-yang-01";
}
revision 2015-03-09 {
description
"Initial version.
";
reference
Sun, et al. Expires January 7, 2016 [Page 6]
Internet-Draft YANG for softwire July 2015
"draft-sun-l2tpext-keyed-v6-tunnel-yang-00";
}
/*
* features
*/
feature FCS-Retention {
description
"Device supports the retention of frame check sequence (FCS)
as per Section 4.7 of RFC4720";
}
feature VCCV {
description
"Device supports the Pseudowire Virtual Circuit Connectivity
Verification (VCCV) as per RFC5085";
}
feature BFD {
description
"Device supports BFD over the tunnel as per RFC5883";
}
feature VCCV-BFD {
description
"Device supports BFD over VCCV as per RFC5885";
}
feature l2tpv3-fragmentation {
description
"Device supports L2TPv3 fragmentation as per RFC4623";
}
/*
* typedefs
*/
/*
* groupings
*/
/*
* config parameters
*/
container tunnelConfigurations {
list tunnelConfiguration {
key "tunnelName";
unique "srcInterface remoteIPv6";
unique "localIPv6 remoteIPv6";
leaf tunnelName {
type string;
description "name of this keyed tunnel";
Sun, et al. Expires January 7, 2016 [Page 7]
Internet-Draft YANG for softwire July 2015
}
leaf srcInterface {
type if:interface-ref;
mandatory true;
description
"Source interface that identifies the L2 circuit
endpoint.";
}
leaf localIPv6 {
type inet:ipv6-address;
mandatory true;
description "IPv6 address for local end of keyed tunnel";
}
leaf remoteIPv6 {
type inet:ipv6-address;
mandatory true;
description "IPv6 address for remote end of keyed tunnel";
}
leaf localSessionId {
type uint32;
default 0xFFFFFFFF;
description
"Since IPv6 address is used to determine the tunnel
and there is one session per tunnel, the Session ID
can be ignored upon receipt. For compatibility with
other tunnel termination platforms supporting two-stage
resolution (IPv6 address + Session ID) the Session ID
is configured with a random value other than all zeros.
If both ends support one-stage (IPv6 address), then
the Session ID is recommended to be set to all ones.";
}
leaf remoteSessionId {
type uint32;
default 0xFFFFFFFF;
description
"Since IPv6 address is used to determine the tunnel
and there is one session per tunnel, the Session ID
can be ignored upon receipt. For compatibility with
other tunnel termination platforms supporting two-stage
resolution (IPv6 address + Session ID) the Session ID
is configured with a random value other than all zeros.
If both ends support one-stage (IPv6 address), then
the Session ID is recommended to be set to all ones.";
}
container localCookies {
list localCookie {
key "cookieName";
leaf cookieName {
Sun, et al. Expires January 7, 2016 [Page 8]
Internet-Draft YANG for softwire July 2015
type string;
description "name identifying this cookie";
}
min-elements 2;
max-elements 2;
leaf cookieValue {
type uint64;
mandatory true;
description "value of this cookie";
}
description
"List of local cookies - must have two entries at
all times to enable lossless cookie rollover";
}
description
"The length of cookie MUST be 64-bit. It MUST be
possible to change the cookie value at any time
in a manner that does not drop any legitimate
tunneled packets - i.e. the receiver
must be willing to accept both 'old' and 'new'
cookie values during a change of cookie value.";
}
leaf remoteCookie {
type uint64;
mandatory true;
description
"The length of cookie MUST be 64-bit. Only be one
remote cookie is used for sending packets.";
}
leaf retainFCS {
if-feature FCS-Retention;
type empty;
description
"If this parameter presents, the router is configued
to retain FCS. Any such router for a tunnel MUST
retain the FCS for all frames sent over that tunnel.
";
}
container enable-vccv {
if-feature VCCV;
presence "Enable VCCV [RFC5085]";
leaf enable-bfd {
if-feature VCCV-BFD;
type empty;
description "Enable VCCV-BFD [RFC5885].";
}
description "Enable VCCV [RFC5085]";
}
Sun, et al. Expires January 7, 2016 [Page 9]
Internet-Draft YANG for softwire July 2015
leaf enable-bfd {
if-feature BFD;
type empty;
description
"Enable BFD over the tunnel [RFC5883].";
}
leaf disable-pmtu {
type empty;
description "Disable IPv6 PMTU discovery [RFC1981]";
}
container enable-fragmentation {
if-feature l2tpv3-fragmentation;
presence "Enable L2TPv3 fragmentation [RFC4623]";
leaf fragment-mru {
type uint16;
description "Explicit override for fragmentation MRU";
}
description
"Default is to fragment to PMTU (or 1500 if PMTU disabled)
minus 52 octet encaps overhead";
}
description
"keyed-v6-tunnel typically supports one l2tpv3 session
per tunnel. The srcInterface and localIPv6 both uniquely
identify a tunnel endpoint. If a virtual interface
is used, the localIPv6 and remoteIPv6 as a pair MUST
also be unique.
";
}
description
"container for list of keyed-v6-tunnel entries";
}
container tunnelStates {
config false;
list tunnelState {
key "tunnelName";
leaf tunnelName {
type string;
description "name of this keyed tunnel";
}
leaf sentPacket {
type yang:zero-based-counter64;
description
"number of packets sent over tunnel";
}
leaf sentByte {
type yang:zero-based-counter64;
description
Sun, et al. Expires January 7, 2016 [Page 10]
Internet-Draft YANG for softwire July 2015
"total sent bytes (of inner packets)";
}
leaf rcvdPacket {
type yang:zero-based-counter64;
description
"number of packets received from tunnel";
}
leaf rcvdByte {
type yang:zero-based-counter64;
description
"total received bytes (of inner packets)";
}
leaf droppedPacket {
type yang:zero-based-counter64;
description
"Number of dropped packets";
}
leaf droppedByte {
type yang:zero-based-counter64;
description
"Total dropped bytes (of inner packets)";
}
leaf fragmentCounter {
type yang:zero-based-counter64;
description
"This is used for counting the fragments of inner
packets.";
}
description "per-tunnel statistics";
}
description "container for list of tunnel statistics";
}
}
<CODE ENDS>
5. Security Considerations
The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
secure transport layer and the mandatory to implement secure
transport is SSH [RFC6242]. The NETCONF access control model
[RFC6536] provides the means to restrict access for particular
NETCONF users to a pre-configured subset of all available NETCONF
protocol operations and content.
There are a number of data nodes defined in this YANG module which
are writable/creatable/deletable (i.e. config true, which is the
default). These data nodes may be considered sensitive or vulnerable
Sun, et al. Expires January 7, 2016 [Page 11]
Internet-Draft YANG for softwire July 2015
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:
subtrees and data nodes and state why they are sensitive
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g. via get, get-config or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
subtrees and data nodes and state why they are sensitive
6. IANA Considerations
TBD
7. Acknowledgements
The authors would like to thank Haoxing Shen for his valuable
comments.
8. References
8.1. Normative References
[I-D.ietf-l2tpext-keyed-ipv6-tunnel]
Konstantynowicz, M., Heron, G., Schatzmayr, R., and W.
Henderickx, "Keyed IPv6 Tunnel", draft-ietf-l2tpext-keyed-
ipv6-tunnel-04 (work in progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
Sun, et al. Expires January 7, 2016 [Page 12]
Internet-Draft YANG for softwire July 2015
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014.
8.2. Informative References
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
Authors' Addresses
Qi Sun
Deutsche Telekom AG
CTO-ATI,Landgrabenweg 151
Bonn, NRW 53227
Germany
Email: qui.sun@external.telekom.de
Ian Farrer
Deutsche Telekom AG
CTO-ATI,Landgrabenweg 151
Bonn, NRW 53227
Germany
Email: ian.farrer@telekom.de
Bing Liu
Huawei Technologies
Q14, Huawei Campus, No.156 Beiqing Road
Beijing, Hai-Dian District 100095
P.R. China
Email: leo.liubing@huawei.com
Sun, et al. Expires January 7, 2016 [Page 13]
Internet-Draft YANG for softwire July 2015
Giles Heron
Cisco Systems
9-11 New Square, Bedfont Lakes
Feltham, Middlesex TW14 8HA
United Kingdom
Email: giheron@cisco.com
Sun, et al. Expires January 7, 2016 [Page 14]
