One document matched: draft-wilton-intf-vlan-yang-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. --><!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">--><!--<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">--><!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY RFC6536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6536.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC7223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7223.xml">
<!ENTITY RFC7224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7224.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-wilton-intf-vlan-yang-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Interface VLAN YANG">Interface VLAN YANG Data Models</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Robert Wilton" initials="R.G." role="editor" surname="Wilton">
<organization>Cisco Systems</organization>
<address>
<email>rwilton@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Ball" initials="D" surname="Ball">
<organization>Cisco Systems</organization>
<address>
<email>daviball@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Giles Heron" initials="G" surname="Heron">
<organization>Cisco Systems</organization>
<address>
<email>giheron@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="March" year="2015"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document defines a YANG configuration data model for the management of VLAN
sub-interfaces that augments the generic interfaces data model defined in <xref target="RFC7223">RFC 7223</xref>. It provides support for basic tag matching
to allow termination of an L2 VLAN segement into L3 services. It also provides support
for flexible matching and rewriting of L2 header fields for L2 services.
</t>
<t>
The model differs from an IEEE 802.1Q VLAN derived model in that the configuration
is interface/sub-interface based as opposed to being VLAN based.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document defines a YANG <xref target="RFC6020">RFC 6020</xref> data model for the management
of network interfaces. It defines interface-type specific extensions that augment the generic
interfaces data model defined in <xref target="RFC7223">RFC 7223</xref> to support configuration for
VLAN sub-interfaces terminated to transport services at either layer 2 or layer 3.</t>
<t>
It is defined as five separate YANG modules that each focus on a particular area of functionality.
The YANG modules defined in this internet draft are:
<list>
<t>dot1q-types.yang - Defines common types for identifying frames using fields from the 802.1Q VLAN tag</t>
<t>interface-common.yang - Defines common extensions to the IETF interface data model to support sub-interfaces</t>
<t>if-l3-vlan.yang - Defines the model for classifying L2 VLAN traffic to L3 transport services</t>
<t>flexible-encapsulation.yang - Defines the model for flexible classification of L2 traffic to L2 transport services</t>
<t>l2-bpdu-filtering.yang - Defines the model for implementing L2 BPDU filtering for VLAN services</t>
</list>
</t>
<!-- <section title="Requirements Language">
</section>-->
<section title="Terminology">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Tree Diagrams">
<t>A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
<list style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).</t>
<t>Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.</t>
<t>Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").</t>
<t>Ellipsis ("...") stands for contents of subtrees that are not
shown.</t>
</list></t>
</section>
</section>
<section title="Objectives">
<t>The aim of of the YANG models contained in this draft is to provide the core
model that is required to implement VLAN transport services on router based devices.</t>
<t>The secondary aim is to make the model cleanly extensible, both to handle greater depths of VLAN tag stacks if required,
and also to allow vendors to extend the model to include additional forms of tag matching and rewriting if desired.</t>
<t>However, the intention is that it should not be necessary to have any vendor specific extentions to any of the YANG models
defined in this document to implement standard Ethernet and VLAN services.</t>
</section>
<section title="802.1Q Types">
<t>The 802.1Q types YANG module contains type definitions for the basic fields defined in an 802.1Q VLAN tag.
It also provides YANG groupings for identifying VLAN tags in various ways that can be used by other YANG modules where required.</t>
</section>
<section title="Interfaces Common Model">
<t>The Interfaces Common model provides some basic extentions to the IETF interfaces YANG module for Ethernet and VLAN sub-interfaces.</t>
<t>The model provides: <list style="symbols">
<t>An encapsulation container and extensible choice statement for use by any interface types that allow for configurable L2 encapsulations.</t>
<t>A configurable L2 MTU leaf applicable to all packet/frame based interfaces.</t>
<t>A transport layer leaf to indicate whether the interface processes the traffic at L2 or L3.</t>
<t>A parent interface leaf useable for all types of sub-interfaces that are bound to a particular parent interface.</t>
</list></t>
<figure>
<preamble>The "interface-common" YANG module, has the following structure:</preamble>
<artwork><![CDATA[
augment /if:interfaces/if:interface:
+--rw encapsulation
+--rw (encaps-type)?
augment /if:interfaces/if:interface:
+--rw l2-mtu? uint16
augment /if:interfaces/if:interface:
+--rw transport-layer? enumeration
augment /if:interfaces/if:interface:
+--rw parent-interface? if:interface-ref
]]></artwork>
</figure>
</section>
<section title="L3 Interface VLAN Model">
<t>
The L3 Interface VLAN model provides appropriate leaves for terminating an 802.1Q VLAN tagged segment to a sub-interface based L3 service. It allows
for terminating of traffic with up to two 802.1Q VLAN tags.
</t>
<figure>
<preamble>The "if-l3-vlan" YANG module has the following structure:</preamble>
<artwork><![CDATA[
augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type:
+--:(vlan)
+--rw vlan
+--rw tags
+--rw tag* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
]]></artwork>
</figure>
</section>
<section title="Flexible Encapsulation Model">
<t>
The Flexible Encapsulation model is designed to allow for the flexible provisioning of layer 2 services. It provides the capability to classify Ethernet/VLAN
frames received on an Ethernet trunk interface to sub-interfaces based on the fields available in the layer 2 headers. Once classified to sub-interfaces, it provides the capability
to selectively modify fields within the layer 2 headers before the frame is handed off to the appropriate forwarding code for further handling.
</t>
<t>
The model supports a common core set of layer 2 header matches based on the 802.1Q tag type and VLAN Ids contained within the header up to a tag stack depth of
two tags.
</t>
<t>
The model supports flexible rewrites of the layer 2 frame header for data frames as they are processed on the interface.
It defines a set of standard tag manipulations that allow for the insertion, removal, or rewrite of one or two 802.1Q VLAN tags. The expectation is that
manipulations are generally implemented in a symmetrical fashion, i.e. if a manipulation is performed on traffic ingressing an interface then the reverse
manipulation is always performed on traffic egressing out of the same interface. However, the model also allows for asymmetrical rewrites, which may be
required to implement some forwarding models (such as E-Tree).
</t>
<t>The structure of the model is currently limited to matching or rewriting a maximum of two 802.1Q tags in the frame header but has been designed to
be easily extensible to matching/rewriting three or more VLAN tags in future, if required.</t>
<t>The final aim for the model design is for it to be cleanly extensible to add in additional match and rewrite criteria of the layer 2 header, such as
matching on the source or destination MAC address, PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame payload. Rewrites can also be
extended to allow for modification of other fields within the layer 2 frame header.</t>
<figure>
<preamble>The "flexible-encapsulation" YANG module has the following structure:</preamble>
<artwork><![CDATA[
augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type:
+--:(flexible) {flexible-encapsulation-rewrites}?
+--rw flexible
+--rw match
| +--rw (match-type)
| +--:(default)
| | +--rw default? empty
| +--:(untagged)
| | +--rw untagged? empty
| +--:(priority-tagged)
| | +--rw priority-tagged
| | +--rw tag-type? dot1q:dot1q-tag-type
| +--:(vlan-tagged)
| +--rw vlan-tagged
| +--rw tag* [index]
| | +--rw index uint8
| | +--rw dot1q-tag
| | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id union
| +--rw match-exact-tags? empty
+--rw rewrite {flexible-rewrites}?
+--rw (direction)?
+--:(symmetrical)
| +--rw symmetrical
| +--rw tag-rewrite {tag-rewrites}?
| +--rw pop-tags? uint8
| +--rw push-tags* [index]
| +--rw index uint8
| +--rw dot1q-tag
| +--rw tag-type dot1q-tag-type
| +--rw vlan-id dot1q-vlan-id
+--:(asymmetrical) {asymmetric-rewrites}?
+--rw ingress
| +--rw tag-rewrite {tag-rewrites}?
| +--rw pop-tags? uint8
| +--rw push-tags* [index]
| +--rw index uint8
| +--rw dot1q-tag
| +--rw tag-type dot1q-tag-type
| +--rw vlan-id dot1q-vlan-id
+--rw egress
+--rw tag-rewrite {tag-rewrites}?
+--rw pop-tags? uint8
+--rw push-tags* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
augment /if:interfaces/if:interface:
+--rw flexible-encapsulation
+--rw local-traffic-default-encaps
+--rw tag* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
]]></artwork>
</figure>
</section>
<section title="L2 BPDU Filtering">
<t>
The L2 BPDU Filtering model adds a single configurable leaf to specify that BPDU filtering is in operation on a trunk interface.
</t>
<figure>
<preamble>The "l2-bpdu-filtering" YANG module has the following structure:</preamble>
<artwork><![CDATA[
augment /if:interfaces/if:interface:
+--rw bpdu
+--rw filtering? enumeration {bpdu-filtering}?
]]></artwork>
</figure>
</section>
<section title="802.1Q Types YANG Module">
<t>
This YANG module has no external imports.
</t>
<t>
The expectation is that the raw 802.1Q VLAN tag fields types may end up
being standardized in IEEE rather than IETF. They are included here to
make the model complete.
</t>
<t>
However, the groupings that can be used to generally identify frames
based on the fields in the 802.1Q tag would seem to fit with wherever the
model resides.
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "dot1q-types@2015-02-26.yang"
module dot1q-types {
namespace "urn:ietf:params:xml:ns:yang:dot1q-types";
prefix dot1q;
organization
"Cisco Systems, Inc.
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
Tel: +1 1800 553-NETS
E-mail: cs-yang@cisco.com";
contact
"Robert Wilton - rwilton@cisco.com";
description
"This module contains a collection of generally useful YANG types
that are specific to 802.1Q VLANs that can be usefully shared
between multiple models.
Terms and Acronyms
802.1Q: IEEE 802.1Q VLANs
VLAN (vlan): Virtual Local Area Network
";
revision 2015-02-26 {
description "Latest revision";
reference "Internet-Draft draft-ietf-rwilton-vlan-yang-00.txt";
}
typedef PCP {
type uint8 {
range "0..7";
}
description
"Priority Code Point. PCP is a 3-bit field that refers to the
class of service applied to an 802.1Q VLAN tagged frame. The
field specifies a priority value between 0 and 7, these values
can be used by quality of service (QoS) to prioritize
different classes of traffic.";
reference "IEEE 802.1Q (2014)";
}
/*
* Defines what it means to be an 802.1Q VLAN Id, where values 0
* and 4095 are reserved.
*/
typedef dot1q-vlan-id {
type uint16 {
range "1..4094";
}
description "An 802.1Q VLAN Identifier";
reference "IEEE 802.1Q (2014)";
}
/*
* Defines the supported IEEE 802.1Q types that can be used for
* VLAN tag matching.
*/
identity dot1q-tag-vlan-type {
description "Base identity from which all 802.1Q VLAN tag types
are derived from";
}
identity c-vlan {
base dot1q-tag-vlan-type;
description
"An 802.1Q Customer-VLAN tag, normally using the 0x8100
Ethertype";
}
identity s-vlan {
base dot1q-tag-vlan-type;
description
"An 802.1Q Service-VLAN tag, using the 0x88a8 Ethertype
originally introduced in 802.1ad, and incorporated into
802.1Q (2011)";
}
typedef dot1q-tag-type {
type identityref {
base "dot1q-tag-vlan-type";
}
description "Identifies a specific 802.1Q tag type";
reference "IEEE 802.1Q (2014)";
}
/*
* Defines the type used to represent ranges of VLAN Ids.
*
* Ideally we would model that as a list of VLAN Ids in YANG, but
* the model is easier to use if this is just represented as a
* string.
*
* This type is used to match an ordered list of VLAN Ids, or
* contiguous ranges of VLAN Ids. Valid VLAN Ids must be in the
* range 1 to 4094, and included in the list in non overlapping
* ascending order.
*
* E.g. "1, 10-100, 50, 500-1000"
*/
typedef dot1q-vlan-id-ranges {
type string {
pattern "([0-9]{1,4}(-[0-9]{1,4})?(,[0-9]{1,4}" +
"(-[0-9]{1,4})?)*)";
}
description "A list of VLAN Ids, or non overlapping VLAN ranges,
in ascending order, between 1 and 4094";
}
/*
* A grouping which represents an 802.1Q VLAN tag, matching both
* the tag Ethertype and a single VLAN Id. The PCP and DEI fields
* in the 802.1Q tag are ignored for tag matching purposes.
*/
grouping dot1q-tag {
description "Grouping to allow configuration to identify a single
802.1Q VLAN tag";
container dot1q-tag {
description "Identifies an 802.1Q VLAN tag with an explicit
tag-type and a single VLAN Id";
leaf tag-type {
type dot1q-tag-type;
mandatory true;
description "VLAN tag type";
}
leaf vlan-id {
type dot1q-vlan-id;
mandatory true;
description "VLAN Id";
}
}
}
/*
* A grouping which represents an 802.1Q VLAN tag, matching both
* the tag Ethertype and a single VLAN Id or "any" to match on any
* VLAN Id. The PCP and DEI fields in the 802.1Q tag are ignored
* for tag matching purposes.
*/
grouping dot1q-tag-or-any {
description "Grouping to allow configuration to identify a single
802.1Q VLAN tag or the 'any' value to match any VLAN
Id not matched by a more specific VLAN Id match";
container dot1q-tag {
description "Identifies an 802.1Q VLAN tag with an explicit
tag-type and a single VLAN Id, or 'any' VLAN Id";
leaf tag-type {
type dot1q-tag-type;
mandatory true;
description "VLAN tag type";
}
leaf vlan-id {
type union {
type dot1q-vlan-id;
type enumeration {
enum "any" {
value 4096;
description
"Matches 'any' VLAN tag in the range 1 to 4094 that
is not matched by a more specific VLAN Id match";
}
}
}
mandatory true;
description "VLAN Id or any";
}
}
}
/*
* A grouping which represents an 802.1Q tag that matches a range
* of VLAN Ids. The PCP and DEI fields in the 802.1Q tag are
* ignored for tag matching purposes.
*/
grouping dot1q-tag-ranges {
description "Grouping to allow configuration to identify an
802.1Q VLAN tag that matches any VLAN Id within a
set of non overlapping VLAN Id ranges";
container dot1q-tag {
description "Identifies an 802.1Q VLAN tag with an explicit
tag-type and and a range of VLAN Ids";
leaf tag-type {
type dot1q-tag-type;
mandatory true;
description "VLAN tag type";
}
leaf vlan-ids {
type dot1q-vlan-id-ranges;
mandatory true;
description "VLAN Ids";
}
}
}
/*
* A grouping which represents an 802.1Q VLAN tag, matching both
* the tag Ethertype and a single VLAN Id, ordered list of ranges,
* or "any" to match on any VLAN Id. The PCP and DEI fields in the
* 802.1Q tag are ignored for tag matching purposes.
*/
grouping dot1q-tag-ranges-or-any {
description "Grouping to allow configuration to identify an
802.1Q VLAN tag that matches any specific VLAN Id
within a set of non overlapping VLAN Id ranges, or
the 'any' value to match any VLAN Id";
container dot1q-tag {
description "Identifies an 802.1Q VLAN tag with an explicit
tag-type, an ordered list of VLAN Id ranges, or
'any' VLAN Id";
leaf tag-type {
type dot1q-tag-type;
mandatory true;
description "VLAN tag type";
}
leaf vlan-id {
type union {
type dot1q-vlan-id-ranges;
type enumeration {
enum "any" {
description "Matches 'any' VLAN tag in the range 1 to
4094";
}
}
}
mandatory true;
description "VLAN Ids or any";
}
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section anchor="intf-common-yang" title="Interfaces Common YANG Module">
<t>
This YANG module augments the interface container defined in <xref target="RFC7223">RFC 7223</xref>
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "interfaces-common@2015-02-26.yang"
module interfaces-common {
namespace "urn:ietf:params:xml:ns:yang:interfaces-common";
prefix if-cmn;
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
organization
"Cisco Systems, Inc.
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
Tel: +1 1800 553-NETS
E-mail: cs-yang@cisco.com";
contact
"Robert Wilton - rwilton@cisco.com";
description
"This module contains common definitions for extending the IETF
interface YANG model (RFC 7223) with common configurable layer 2
properties";
revision 2015-02-26 {
description "Latest revision";
reference "Internet-Draft draft-ietf-rwilton-vlan-yang-00.txt";
}
/*
* Various types of interfaces support a configurable layer 2
* encapsulation, any that are supported by YANG should be
* listed here.
*
* Different encapsulations can hook into the common encaps-type
* choice statement.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag' or
if:type = 'ianaift:l2vlan'" {
description "All interface types that can have a configurable
L2 encapsulation";
}
description "Add encapsulation top level node to interface types
that support a configurable L2 encapsulation";
container encapsulation {
description
"Holds the L2 encapsulation associated with an interfaces";
choice encaps-type {
description "Extensible choice of L2 encapsulations";
}
}
}
/*
* Various types of interfaces support a configurable layer 2
* MTU, all of them that are supported by YANG should be
* listed here.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag' or
if:type = 'ianaift:l2vlan'" {
description "All interface types that can have a configurable
layer 2 MTU";
}
description "Add configurable layer-2 MTU to all appropriate
interface types";
leaf l2-mtu {
type uint16 {
range "64 .. 65535";
}
description
"The maximum size of layer 2 frame that may be transmitted
or received on the interface (excluding any FCS overhead).
In the case of Ethernet interfaces it also excludes the
4-8 byte overhead of any known (i.e. explicitly matched by
a child sub-interface) 801.1Q VLAN tags.";
}
}
/*
* Augments the IETF interfaces model with a leaf that indicates
* whether traffic is to be transported as layer 2 or layer 3.
*
* All interface types that explicitly support forwarding frames
* at layer 2 and that are supported by YANG should be listed here.
*
* Different encapsulation can hook into the common encaps-type
* choice statement.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag' or
if:type = 'ianaift:l2vlan'" {
description "Any interface types that support layer 2 transport
services";
}
description "Add a top level node to appropriate interfaces to
indicate which tranport layer an interface is
operating at";
leaf transport-layer {
type enumeration {
enum layer-2 {
value 2;
description "Layer 2 transport";
}
enum layer-3 {
value 3;
description "Layer 3 transport";
}
}
default layer-3;
description
"The transport layer at which the interface is operating at";
}
}
/*
* Add generic support for sub-interfaces.
*
* This should be extended to cover all interface types that are
* child interfaces of other interfaces.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan'" {
description "Any sub-interfaces";
}
description "Add a parent interface field to interfaces to model
sub-interfaces";
leaf parent-interface {
type if:interface-ref;
/*
* TODO - How to make this mandatory without using the
* mandatory keyword.
* - Current options appear to be:
* - Possibly define a feature "parented-sub-interfaces".
* - Create a sub-interface container with presence.
* - Enforce the constraint with a must statement.
*/
//mandatory true;
description
"This is the mandatory reference to the parent interface of
this sub-interface.";
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="L3 Interface VLAN YANG Module">
<t>
This YANG module augments the encapsultion container defined in <xref target="intf-common-yang">the Interfaces Common YANG Module</xref>
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "if-l3-vlan@2015-02-26.yang"
module if-l3-vlan {
namespace "urn:ietf:params:xml:ns:yang:if-l3-vlan";
prefix if-l3-vlan;
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
import dot1q-types {
prefix dot1q;
}
import interfaces-common {
prefix if-cmn;
}
organization
"Cisco Systems, Inc.
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
Tel: +1 1800 553-NETS
E-mail: cs-yang@cisco.com";
contact
"Robert Wilton - rwilton@cisco.com";
description
"This YANG module models L3 VLAN sub-interfaces
";
revision 2015-02-26 {
description "Latest revision";
reference "Internet-Draft draft-ietf-rwilton-vlan-yang-00.txt";
}
feature l3-vlan-sub-interfaces {
description
"This feature indicates that the device supports L3 VLAN
sub-interfaces";
}
/*
* Add support for the 802.1Q VLAN encapsulation syntax on layer 3
* terminated VLAN sub-interfaces.
*/
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" {
when "../../if:type = 'ianaift:l2vlan' and
../../if-cmn:transport-layer = 'layer-3'" {
description "Applies only to VLAN sub-interfaces that are
operating at layer 3";
}
if-feature l3-vlan-sub-interfaces;
description "Augment the generic interface encapsulation with an
encapsulation for layer 3 VLAN sub-interfaces";
/*
* Matches a VLAN, or pair of VLAN Ids to classify traffic
* into an L3 service.
*/
case vlan {
container vlan {
description
"Match VLAN tagged frames with specific VLAN Ids";
container tags {
description "Matches frames tagged with specific VLAN Ids";
list tag {
key "index";
min-elements 1;
max-elements 2;
description "The tags to match, with the outermost tag to
match with index 0";
leaf index {
type uint8 {
range "0..1";
}
/*
* Only allow matching on an inner tag (at index 1), if
* also matching on the outer tag at the same time.
*/
must "index = 0 or
count(../../tag[index = 0]/index) > 0" {
error-message
"An inner tag can only be matched on when also
matching on an outer tag";
description
"Only allow matching on an inner tag, if also
matching on the outer tag at the same time";
}
description
"The index into the tag stack, outermost tag first";
}
uses dot1q:dot1q-tag;
}
}
}
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="Flexible Encapsulation YANG Module">
<t>
This YANG module augments the encapsultion container defined in <xref target="intf-common-yang">the Interfaces Common YANG Module</xref>.
</t>
<t>
This YANG module also augments the interface container defined in <xref target="RFC7223">RFC 7223</xref>.
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "flexible-encapsulation@2015-02-26.yang"
module flexible-encapsulation {
namespace "urn:ietf:params:xml:ns:yang:flexible-encapsulation";
prefix flex;
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
import interfaces-common {
prefix if-cmn;
}
import dot1q-types {
prefix dot1q;
}
organization
"Cisco Systems, Inc.
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
Tel: +1 1800 553-NETS
E-mail: cs-yang@cisco.com";
contact
"Robert Wilton - rwilton@cisco.com";
description
"This YANG module describes interface configuration for flexible
VLAN matches and rewrites.";
revision 2015-02-26 {
description "Latest revision";
reference "Internet-Draft draft-ietf-rwilton-vlan-yang-00.txt";
}
feature flexible-encapsulation-rewrites {
description
"This feature indicates whether the network element supports
flexible Ethernet encapsulation that allows for matching VLAN
ranges and performing independent tag manipulations";
}
feature flexible-rewrites {
description
"This feature indicates whether the network element supports
specifying flexible rewrite operations";
}
feature asymmetric-rewrites {
description
"This feature indicates whether the network element supports
specifying different rewrite operations for the ingress
rewrite operation and egress rewrite operation.";
}
feature tag-rewrites {
description
"This feature indicates whether the network element supports
the flexible rewrite functionality specifying flexible tag
rewrites";
}
/*
* flexible-match grouping.
*
* This grouping represents a flexible match.
*
* The rules for a flexible match are:
* 1. default, untagged, priority tag, or a stack of tags.
* - Each tag in the stack of tags matches:
* 1. tag type (802.1Q or 802.1ad) +
* 2. tag value:
* i. single tag
* ii. set of tag ranges/values.
* iii. "any" keyword
*/
grouping flexible-match {
description "Flexible match";
choice match-type {
mandatory true;
description "Provides a choice of how the frames may be
matched";
case default {
description "Default match";
leaf default {
type empty;
description
"Default match. Matches all traffic not matched to any
other peer sub-interface by a more specific
encapsulation.";
} // leaf default
} // case default
case untagged {
description "Match untagged Ethernet frames only";
leaf untagged {
type empty;
description
"Untagged match. Matches all untagged traffic.";
} // leaf untagged
} // case untagged
case priority-tagged {
description "Match priority tagged Ethernet frames only";
container priority-tagged {
description "Priority tag match";
leaf tag-type {
type dot1q:dot1q-tag-type;
description "The 802.1Q tag type of matched priority
tagged packets";
}
}
}
case vlan-tagged {
container vlan-tagged {
description "Matches VLAN tagged frames";
list tag {
key "index";
min-elements 1;
max-elements 2;
description "The tags to match, with the outermost tag to
match assigned index 0";
leaf index {
type uint8 {
range "0..1";
}
must "index = 0 or
count(../../tag[index = 0]/index) > 0" {
error-message "An inner tag can only be matched on
when also matching on an outer tag";
description "Only allow matching on an inner tag, if
also matching on the outer tags at the
same time";
}
description
"The index into the tag stack, outermost tag first";
}
uses dot1q:dot1q-tag-ranges-or-any;
}
leaf match-exact-tags {
type empty;
description
"If set, indicates that all 802.1Q VLAN tags in the
Ethernet frame header must be explicitly matched, i.e.
the EtherType following the matched tags must not be a
802.1Q tag EtherType. If unset then extra 802.1Q VLAN
tags are allowed.";
}
}
}
} // encaps-type
}
/*
* Grouping for tag-rewrite that can be expressed either
* symmetrically, or in the ingress and/or egress directions
* independently.
*/
grouping tag-rewrite {
description "Flexible rewrite";
leaf pop-tags {
type uint8 {
range 1..2;
}
description "The number of tags to pop (or translate if used in
conjunction with push-tags)";
}
list push-tags {
key "index";
max-elements 2;
description "The number of tags to push (or translate if used
in conjunction with pop-tags)";
/*
* Server should order by increasing index.
*/
leaf index {
type uint8 {
range 0..1;
}
/*
* Only allow a push of an inner tag if an outer tag is also
* being pushed.
*/
must "index != 0 or
count(../../push-tags[index = 0]/index) > 0" {
error-message "An inner tag can only be pushed if an outer
tag is also specified";
description "Only allow a push of an inner tag if an outer
tag is also being pushed";
}
description "The index into the tag stack";
}
uses dot1q:dot1q-tag;
}
}
/*
* Grouping for all flexible rewrites of fields in the L2 header.
*
* This currently only includes flexible tag rewrites, but is
* designed to be extensible to cover rewrites of other fields in
* the L2 header if required.
*/
grouping flexible-rewrite {
description "Flexible rewrite";
/*
* Tag rewrite.
*
* All tag rewrites are formed using a combination of pop-tags
* and push-tags operations.
*/
container tag-rewrite {
if-feature tag-rewrites;
description "Tag rewrite. Translate operations are expressed
as a combination of tag push and pop operations.";
uses tag-rewrite;
}
}
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" {
when "../../if:type = 'ianaift:l2vlan' and
../../if-cmn:transport-layer = 'layer-2'" {
description "Applies only to VLAN sub-interfaces that are
operating at transport layer 2";
}
description
"Add flexible match and rewrite for VLAN sub-interfaces";
/*
* A flexible encapsulation allows for the matching of ranges and
* sets of VLAN Ids. The structure is also designed to be
* extended to allow for matching/rewriting other fields within
* the L2 frame header if required.
*/
case flexible {
if-feature flexible-encapsulation-rewrites;
description "Flexible encapsulation and rewrite";
container flexible {
description "Flexible encapsulation and rewrite";
container match {
description
"The match used to classify frames to this interface";
uses flexible-match;
}
container rewrite {
if-feature flexible-rewrites;
description "L2 frame rewrite operations";
choice direction {
description "Whether the rewrite policy is symmetrical or
asymmetrical";
case symmetrical {
container symmetrical {
uses flexible-rewrite;
description
"Symmetrical rewrite. Expressed in the ingress
direction, but the reverse operation is applied
to egress traffic";
}
}
/*
* Allow asymmetrical rewrites to be specified.
*/
case asymmetrical {
if-feature asymmetric-rewrites;
description "Asymmetrical rewrite";
container ingress {
uses flexible-rewrite;
description "Ingress rewrite";
}
container egress {
uses flexible-rewrite;
description "Egress rewrite";
}
}
}
}
}
}
}
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:l2vlan' and
if-cmn:transport-layer = 'layer-2'" {
description "Any L2 VLAN sub-interfaces";
}
description "Add flexible encapsulation configuration for VLAN
sub-interfaces";
/*
* All flexible encapsulation specific interface configuration
* (except for the actual encapsulation and rewrite) is contained
* by a flexible-encapsulation container on the interface.
*/
container flexible-encapsulation {
description
"All per interface flexible encapsulation related fields";
/*
* For encapsulations that match a range of VLANs (or Any),
* allow configuration to specify the default VLAN tag values
* to use for any traffic that is locally sourced from an
* interface on the device.
*/
container local-traffic-default-encaps {
description "The VLAN tags to use by default for locally
sourced traffic";
list tag {
key "index";
max-elements 2;
description
"The VLAN tags to use by locally sourced traffic";
leaf index {
type uint8 {
range "0..1";
}
/*
* Only allow an inner tag to be specified if an outer
* tag has also been specified.
*/
must "index = 0 or
count(../../tag[index = 0]/index) > 0" {
error-message "An inner tag can only be specified if an
outer tag has also been specified";
description "Ensure that an inner tag cannot be
specified without an outer tag'";
}
description "The index into the tag stack, outermost tag
assigned index 0";
}
uses dot1q:dot1q-tag;
}
}
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="L2 BPDU filtering YANG Module">
<t>
This YANG module augments the interface container defined in <xref target="RFC7223">RFC 7223</xref> for Etherlike (Ethernet and
802.3 LAG (802.1AX) interfaces) trunk interfaces.
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "l2-bpdu-filtering@2015-02-26.yang"
module l2-bpdu-filtering {
namespace "urn:ietf:params:xml:ns:yang:l2-bpdu-filtering";
prefix bpdu;
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
organization
"Cisco Systems, Inc.
Customer Service
Postal: 170 W Tasman Drive
San Jose, CA 95134
Tel: +1 1800 553-NETS
E-mail: cs-yang@cisco.com";
contact
"Robert Wilton - rwilton@cisco.com";
description
"This YANG module describes the extentions for 802.1Q defined
filtering of BPDUs via the destination MAC address.";
revision 2015-02-26 {
description "Latest revision";
reference "Internet-Draft draft-ietf-rwilton-vlan-yang-00.txt";
}
feature bpdu-filtering {
description
"This feature indicates that the device supports standards
compliant BPDU filtering";
}
/*
* BPDU processing applies to all Etherlike interfaces.
*/
augment "/if:interfaces/if:interface" {
when "if:type = 'ianaift:ethernetCsmacd' or
if:type = 'ianaift:ieee8023adLag'" {
description "Applies to all Etherlike interfaces";
}
description "Add BPDU related configuration to Etherlike
interfaces";
container bpdu {
description "BPDU related configuration";
/*
* The filtering leaf defines the filtering of L2 BPDUs based
* on their destination MAC address. If no value has been
* specified then the default behaviour is that there is no
* filtering.
*/
leaf filtering {
if-feature bpdu-filtering;
type enumeration {
enum c-vlan {
description "C-VLAN ingress frame filtering";
reference
"Table 8-1 C-VLAN and MAC Bridge component reserved
addresses of IEEE 802.1Q (2014)";
}
enum s-vlan {
description "S-VLAN ingress frame filtering";
reference
"Table 8-2 S-VLAN component reserved addresses of
IEEE 802.1Q (2014)";
}
enum mac-relay {
description "2-port MAC relay ingress frame filtering";
reference
"Table 8-3 TPMR component Reserved addresses of IEEE
802.1Q (2014)";
}
}
description "The type of filtering to apply to all ingress
BPDU frames on this interface. If no filtering
behavior is specified then frames are forwarded
by default unless they have been explicitly
peered by protocol specific configuration";
}
}
}
}
<CODE ENDS>
]]></artwork>
</figure>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors wish to thank Neil Ketley for his helpful comments contributing to this draft.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document defines several new YANG module and the authors politely request that IANA assigns
unique names to the YANG module files contained within this draft, and also appropriate
URIs in the "IETF XML Registry".</t>
<!-- <t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section will
be removed during conversion into an RFC by the RFC Editor.</t>-->
</section>
<section anchor="Security" title="Security Considerations">
<t>The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol <xref target="RFC6241">RFC 6241</xref>. The
lowest NETCONF layer is the secure transport layer and the mandatory
to implement secure transport is SSH <xref target="RFC6242">RFC 6242</xref>.
The NETCONF access control model <xref target="RFC6536">RFC 6536</xref>
provides the means to restrict access for particular NETCONF users
to a pre-configured subset of all available NETCONF protocol
operations and content.</t>
<t>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
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:</t>
<section title="interfaces-common.yang">
<t>The interfaces-common YANG module contains a leaf to control the L2 MTU
of an interface or sub-interface which if changed or deleted could cause
traffic loss on the affected interface or sub-interfaces, or it could
cause layer 2 tunnels to go down due to a mismatch in negotiated MTU.
The following leaf is affected:
<list style="symbols">
<t>interfaces/interface/l2-mtu</t>
</list>
</t></section>
<section title="if-l3-vlan.yang">
<t>The nodes in the if-l3-vlan YANG module are concerned with matching particular frames received on the network
device to connect them to a layer 3 forwarding instance, and as such adding/modifying/deleting these nodes has a high
risk of causing traffic to be lost because it is not being classified
correctly, or is being classified to a separate sub-interface. The
nodes, all under the subtree /interfaces/interface/encapsulation/vlan, that
are sensitive to this are:
<list style="symbols">
<t>tags</t>
<t>tags/index</t>
<t>tags/index/tag-type</t>
<t>tags/index/vlan-id</t>
</list></t>
</section>
<section title="flexible-encapsulation.yang">
<t>There are many nodes in the flexible-encapsulation YANG module that
are concerned with matching particular frames received on the network
device, and as such adding/modifying/deleting these nodes has a high
risk of causing traffic to be lost because it is not being classified
correctly, or is being classified to a separate sub-interface. The
nodes, all under the subtree /interfaces/interface/encapsulation/flexible/match, that
are sensitive to this are:
<list style="symbols">
<t>default</t>
<t>untagged</t>
<t>priority-tagged</t>
<t>priority-tagged/tag-type</t>
<t>vlan-tagged</t>
<t>vlan-tagged/index</t>
<t>vlan-tagged/index/dot1q-tag/vlan-type</t>
<t>vlan-tagged/index/dot1q-tag/vlan-id</t>
<t>vlan-tagged/match-exact-tags</t>
</list></t>
<t>There are also many modes in the flexible-encapsulation YANG module that
are concerned with rewriting the fields in the L2 header for particular frames received on the network
device, and as such adding/modifying/deleting these nodes has a high
risk of causing traffic to be dropped or incorrectly processed on peer network devices, or it could
cause layer 2 tunnels to go down due to a mismatch in negotiated MTU. The
nodes, all under the subtree /interfaces/interface/encapsulation/flexible/rewrite, that
are sensitive to this are:
<list style="symbols">
<t>symmetrical/tag-rewrite/pop-tags</t>
<t>symmetrical/tag-rewrite/push-tags</t>
<t>symmetrical/tag-rewrite/push-tags/index</t>
<t>symmetrical/tag-rewrite/push-tags/dot1q-tag/tag-type</t>
<t>symmetrical/tag-rewrite/push-tags/dot1q-tag/vlan-id</t>
<t>asymmetrical/ingress/tag-rewrite/pop-tags</t>
<t>asymmetrical/ingress/tag-rewrite/push-tags</t>
<t>asymmetrical/ingress/tag-rewrite/push-tags/index</t>
<t>asymmetrical/ingress/tag-rewrite/push-tags/dot1q-tag/tag-type</t>
<t>asymmetrical/ingress/tag-rewrite/push-tags/dot1q-tag/vlan-id</t>
<t>asymmetrical/egress/tag-rewrite/pop-tags</t>
<t>asymmetrical/egress/tag-rewrite/push-tags</t>
<t>asymmetrical/egress/tag-rewrite/push-tags/index</t>
<t>asymmetrical/egress/tag-rewrite/push-tags/dot1q-tag/tag-type</t>
<t>asymmetrical/egress/tag-rewrite/push-tags/dot1q-tag/vlan-id</t>
</list></t>
<t>Nodes in the flexible-encapsulation YANG module that are concerned with the VLAN tags
to use for traffic sourced from the network element could cause protocol sessions (such as CFM)
to fail if they are added, modified or deleted. The
nodes, all under the subtree /interfaces/interface/flexible-encapsulation/local-traffic-default-encaps that are sensitive to this are:
<list style="symbols">
<t>tag</t>
<t>tag/index</t>
<t>tag/dot1q-tag/tag-type</t>
<t>tag/dot1q-tag/vlan-id</t>
</list></t>
</section>
<section title="l2-bpdu-filtering.yang">
<t>The l2-bpdu-filtering YANG module specifies a single leaf that defines what type of L2 BPDU filtering is in effect.
Adding/modifying/deleting the following node could cause instabilities in L2 control protocols
which could indirectly cause frame loss of network outages. Affected node:
<list style="symbols">
<t>interfaces/interface/bpdu/filtering</t>
</list></t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC6020;
&RFC2119;
&RFC7223;
&RFC7224;
<!-- <reference anchor="min_ref">
<!- - the following is the minimum to make xml2rfc happy - ->
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>-->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- &RFC2629;
&RFC3552; -->
&RFC6241;
&RFC6242;
&RFC6536;
<!--&I-D.narten-iana-considerations-rfc2434bis;-->
<!-- A reference written by by an organization not a person. -->
<!-- <reference anchor="DOMINATION"
target="http://www.example.com/dominator.html">
<front>
<title>Ultimate Plan for Taking Over the World</title>
<author>
<organization>Mad Dominators, Inc.</organization>
</author>
<date year="1984" />
</front>
</reference>-->
</references>
<!-- <section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>-->
<!-- Change Log
v00 2015-03-02 RGW Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:47 |