draft-ietf-netmod-sub-intf-vlan-model-04.txt   draft-ietf-netmod-sub-intf-vlan-model-05.txt 
Internet Engineering Task Force R. Wilton, Ed. Internet Engineering Task Force R. Wilton, Ed.
Internet-Draft D. Ball Internet-Draft D. Ball
Intended status: Informational T. Singh Intended status: Standards Track T. Singh
Expires: January 3, 2019 Cisco Systems Expires: September 7, 2019 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
July 2, 2018 March 6, 2019
Sub-interface VLAN YANG Data Models Sub-interface VLAN YANG Data Models
draft-ietf-netmod-sub-intf-vlan-model-04 draft-ietf-netmod-sub-intf-vlan-model-05
Abstract Abstract
This document defines YANG modules to add support for classifying This document defines YANG modules to add support for classifying
traffic received on interfaces as Ethernet/VLAN framed packets to traffic received on interfaces as Ethernet/VLAN framed packets to
sub-interfaces based on the fields available in the Ethernet/VLAN sub-interfaces based on the fields available in the Ethernet/VLAN
frame headers. These modules allow configuration of Layer 3 and frame headers. These modules allow configuration of Layer 3 and
Layer 2 sub-interfaces (e.g. attachment circuits) that can Layer 2 sub-interfaces (e.g. attachment circuits) that can
interoperate with IETF based forwarding protocols; such as IP and interoperate with IETF based forwarding protocols; such as IP and
L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN. The
sub-interfaces also interoperate with VLAN tagged traffic orginating sub-interfaces also interoperate with VLAN tagged traffic orginating
from an IEEE 802.1Q compliant bridge. Primarily the classification from an IEEE 802.1Q compliant bridge.
is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
also has support for matching on some other layer 2 frame header
fields and is designed to be extensible to match on other arbitrary
header fields.
The model differs from an IEEE 802.1Q bridge model in that the The model differs from an IEEE 802.1Q bridge model in that the
configuration is interface/sub-interface based as opposed to being configuration is interface/sub-interface based as opposed to being
based on membership of an 802.1Q VLAN bridge. based on membership of an 802.1Q VLAN bridge.
The YANG data models in this document conforms to the Network
Management Datastore Architecture (NMDA) defined in RFC 8342.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019. This Internet-Draft will expire on September 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4 2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4
2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 4
3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5
4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5 4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5
5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7 5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7
6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19
7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. WG version -04 . . . . . . . . . . . . . . . . . . . . . 23 9.1. WG version -05 . . . . . . . . . . . . . . . . . . . . . 24
9.2. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24 9.2. WG version -04 . . . . . . . . . . . . . . . . . . . . . 24
9.3. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24 9.3. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24
9.4. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24 9.4. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24
9.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24 9.5. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24
9.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24 9.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25 11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25
11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 25 11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29
A.1. Sub-interface based configuration model overview . . . . 29 A.1. Sub-interface based configuration model overview . . . . 29
A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30
A.3. Possible Overlap Between the Two Models . . . . . . . . . 30 A.3. Possible Overlap Between the Two Models . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
This document defines two YANG [RFC7950] modules that augment the This document defines two YANG [RFC7950] modules that augment the
encapsulation choice YANG element defined in Interface Extensions encapsulation choice YANG element defined in Interface Extensions
YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data
model defined in [RFC8343]. The two modules provide configuration model defined in [RFC8343]. The two modules provide configuration
nodes to support classification of Ethernet/VLAN traffic to sub- nodes to support classification of Ethernet/VLAN traffic to sub-
interfaces, that can have interface based feature and service interfaces, that can have interface based feature and service
skipping to change at page 4, line 9 skipping to change at page 4, line 9
Sub-interface: A sub-interface is a small augmentation of a regular Sub-interface: A sub-interface is a small augmentation of a regular
interface in the standard YANG module for Interface Management that interface in the standard YANG module for Interface Management that
represents a subset of the traffic handled by its parent interface. represents a subset of the traffic handled by its parent interface.
As such, it supports both configuration and operational data using As such, it supports both configuration and operational data using
any other YANG models that augment or reference interfaces in the any other YANG models that augment or reference interfaces in the
normal way. It is defined in Interface Extensions YANG normal way. It is defined in Interface Extensions YANG
[I-D.ietf-netmod-intf-ext-yang]. [I-D.ietf-netmod-intf-ext-yang].
1.2. Tree Diagrams 1.2. Tree Diagrams
A simplified graphical representation of the data model is used in Tree diagrams used in this document follow the notation defined in
this document. The meaning of the symbols in these diagrams is as [RFC8340].
follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(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 or 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. Objectives 2. Objectives
The primary aim of the YANG modules contained in this draft is to The primary aim of the YANG modules contained in this draft is to
provide the core model that is required to implement VLAN transport provide the core model that is required to implement VLAN transport
services on router based devices that is fully compatible with IEEE services on router based devices that is fully compatible with IEEE
802.1Q compliant bridges. 802.1Q compliant bridges.
A secondary aim is for the modules to be structured in such a way A secondary aim is for the modules to be structured in such a way
that they can be cleanly extended in future. that they can be cleanly extended in future.
2.1. Interoperability with IEEE 802.1Q compliant bridges 2.1. Interoperability with IEEE 802.1Q compliant bridges
The modules defined in this document are designed to fully The modules defined in this document are designed to fully
interoperate with IEEE 802.1Q compliant bridges. In particular, the interoperate with IEEE 802.1Q compliant bridges. In particular, the
models are restricted to only matching, adding, or rewriting the models are restricted to only matching, adding, or rewriting the
802.1Q VLAN tags in frames in ways that are compatible with IEEE 802.1Q VLAN tags in frames in ways that are compatible with IEEE
802.1Q compliant bridges. 802.1Q compliant bridges.
2.2. Extensibility
The modules are structured in such a way that they can be sensibly
extended. In particular:
The tag stack is represented as a list to allow a tag stack of
more than two tags to be supported if necessary in future.
The tag stack list elements allow other models, or vendors, to
include additional forms of tag matching and rewriting. The
intention, however, is that it should not be necessary to have any
vendor specific extensions to any of the YANG models defined in
this document to implement standard Ethernet and VLAN services.
3. L3 Interface VLAN Model 3. L3 Interface VLAN Model
The L3 Interface VLAN model provides appropriate leaves for The L3 Interface VLAN model provides appropriate leaves for
termination of an 802.1Q VLAN tagged segment to a sub-interface based termination of an 802.1Q VLAN tagged segment to a sub-interface based
L3 service. It allows for termination of traffic with up to two L3 service. It allows for termination of traffic with up to two
802.1Q VLAN tags. 802.1Q VLAN tags.
The "if-l3-vlan" YANG module has the following structure: The "if-l3-vlan" YANG module has the following structure:
module: ietf-if-l3-vlan module: ietf-if-l3-vlan
augment /if:interfaces/if:interface/if-cmn:encapsulation/ augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type: if-cmn:encaps-type:
+--:(dot1q-vlan) +--:(dot1q-vlan)
+--rw dot1q-vlan +--rw dot1q-vlan
+--rw outer-tag! +--rw outer-tag
| +--rw tag-type dot1q-tag-type | +--rw tag-type dot1q-tag-type
| +--rw vlan-id ieee:vlanid | +--rw vlan-id vlanid
+--rw second-tag! +--rw second-tag!
+--rw tag-type dot1q-tag-type +--rw tag-type dot1q-tag-type
+--rw vlan-id ieee:vlanid +--rw vlan-id vlanid
4. Flexible Encapsulation Model 4. Flexible Encapsulation Model
The Flexible Encapsulation model is designed to allow for the The Flexible Encapsulation model is designed to allow for the
flexible provisioning of layer 2 services. It provides the flexible provisioning of layer 2 services. It provides the
capability to classify Ethernet/VLAN frames received on an Ethernet capability to classify Ethernet/VLAN frames received on an Ethernet
trunk interface to sub-interfaces based on the fields available in trunk interface to sub-interfaces based on the fields available in
the layer 2 headers. Once classified to sub-interfaces, it provides the layer 2 headers. Once classified to sub-interfaces, it provides
the capability to selectively modify fields within the layer 2 the capability to selectively modify fields within the layer 2
headers before the frame is handed off to the appropriate forwarding headers before the frame is handed off to the appropriate forwarding
skipping to change at page 6, line 11 skipping to change at page 5, line 31
data frames as they are processed on the interface. It defines a set data frames as they are processed on the interface. It defines a set
of standard tag manipulations that allow for the insertion, removal, of standard tag manipulations that allow for the insertion, removal,
or rewrite of one or two 802.1Q VLAN tags. The expectation is that or rewrite of one or two 802.1Q VLAN tags. The expectation is that
manipulations are generally implemented in a symmetrical fashion, manipulations are generally implemented in a symmetrical fashion,
i.e. if a manipulation is performed on ingress traffic on an i.e. if a manipulation is performed on ingress traffic on an
interface then the reverse manipulation is always performed on egress interface then the reverse manipulation is always performed on egress
traffic out of the same interface. However, the model also allows traffic out of the same interface. However, the model also allows
for asymmetrical rewrites, which may be required to implement some for asymmetrical rewrites, which may be required to implement some
forwarding models (such as E-Tree). forwarding models (such as E-Tree).
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.
The final aim for the model design is for it to be cleanly extensible 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 to add in additional match and rewrite criteria of the layer 2
header, such as matching on the source or destination MAC address, 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 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 payload. Rewrites can also be extended to allow for modification of
other fields within the layer 2 frame header. other fields within the layer 2 frame header.
The "flexible-encapsulation" YANG module has the following structure: The "flexible-encapsulation" YANG module has the following structure:
module: ietf-flexible-encapsulation module: ietf-flexible-encapsulation
augment /if:interfaces/if:interface/if-cmn:encapsulation/ augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type: if-cmn:encaps-type:
+--:(flexible) +--:(flexible)
+--rw flexible +--rw flexible
+--rw match +--rw match
| +--rw (match-type) | +--rw (match-type)
| +--:(default) | +--:(default)
| | +--rw default? empty | | +--rw default? empty
| +--:(untagged) | +--:(untagged)
| | +--rw untagged? empty | | +--rw untagged? empty
| +--:(dot1q-priority-tagged) | +--:(dot1q-priority-tagged)
| | +--rw dot1q-priority-tagged | | +--rw dot1q-priority-tagged
| | +--rw tag-type? dot1q-types:dot1q-tag-type | | +--rw tag-type dot1q-types:dot1q-tag-type
| +--:(dot1q-vlan-tagged) | +--:(dot1q-vlan-tagged)
| +--rw dot1q-vlan-tagged | +--rw dot1q-vlan-tagged
| +--rw outer-tag! | +--rw outer-tag
| | +--rw tag-type dot1q-tag-type | | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id union | | +--rw vlan-id union
| +--rw second-tag! | +--rw second-tag!
| | +--rw tag-type dot1q-tag-type | | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id union | | +--rw vlan-id union
| +--rw match-exact-tags? empty | +--rw match-exact-tags? empty
+--rw rewrite {flexible-rewrites}? +--rw rewrite {flexible-rewrites}?
| +--rw (direction)? | +--rw (direction)?
| +--:(symmetrical) | +--:(symmetrical)
| | +--rw symmetrical | | +--rw symmetrical
| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
| | +--rw pop-tags? uint8 | | +--rw pop-tags? uint8
| | +--rw push-tags | | +--rw push-tags!
| | +--rw outer-tag! | | +--rw outer-tag
| | | +--rw tag-type dot1q-tag-type | | | +--rw tag-type dot1q-tag-type
| | | +--rw vlan-id ieee:vlanid | | | +--rw vlan-id vlanid
| | +--rw second-tag! | | +--rw second-tag!
| | +--rw tag-type dot1q-tag-type | | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id ieee:vlanid | | +--rw vlan-id vlanid
| +--:(asymmetrical) {asymmetric-rewrites}? | +--:(asymmetrical) {asymmetric-rewrites}?
| +--rw ingress | +--rw ingress
| | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? | | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
| | +--rw pop-tags? uint8 | | +--rw pop-tags? uint8
| | +--rw push-tags | | +--rw push-tags!
| | +--rw outer-tag! | | +--rw outer-tag
| | | +--rw tag-type dot1q-tag-type | | | +--rw tag-type dot1q-tag-type
| | | +--rw vlan-id ieee:vlanid | | | +--rw vlan-id vlanid
| | +--rw second-tag! | | +--rw second-tag!
| | +--rw tag-type dot1q-tag-type | | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id ieee:vlanid | | +--rw vlan-id vlanid
| +--rw egress | +--rw egress
| +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}? | +--rw dot1q-tag-rewrite {dot1q-tag-rewrites}?
| +--rw pop-tags? uint8 | +--rw pop-tags? uint8
| +--rw push-tags | +--rw push-tags!
| +--rw outer-tag! | +--rw outer-tag
| | +--rw tag-type dot1q-tag-type | | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id ieee:vlanid | | +--rw vlan-id vlanid
| +--rw second-tag! | +--rw second-tag!
| +--rw tag-type dot1q-tag-type | +--rw tag-type dot1q-tag-type
| +--rw vlan-id ieee:vlanid | +--rw vlan-id vlanid
+--rw local-traffic-default-encaps! +--rw local-traffic-default-encaps!
+--rw outer-tag! +--rw outer-tag
| +--rw tag-type dot1q-tag-type | +--rw tag-type dot1q-tag-type
| +--rw vlan-id ieee:vlanid | +--rw vlan-id vlanid
+--rw second-tag! +--rw second-tag!
+--rw tag-type dot1q-tag-type +--rw tag-type dot1q-tag-type
+--rw vlan-id ieee:vlanid +--rw vlan-id vlanid
5. L3 Interface VLAN YANG Module 5. L3 Interface VLAN YANG Module
This YANG module augments the encapsultion container defined in This YANG module augments the encapsultion container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
<CODE BEGINS> file "ietf-if-l3-vlan@2017-10-30.yang" <CODE BEGINS> file "ietf-if-l3-vlan@2019-03-05.yang"
module ietf-if-l3-vlan { module ietf-if-l3-vlan {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan";
prefix if-l3-vlan; prefix if-l3-vlan;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
skipping to change at page 8, line 36 skipping to change at page 7, line 48
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger WG Chair: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
WG Chair: Joel Jaeggli
<mailto:joelja@gmail.com>
WG Chair: Kent Watsen WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Editor: Robert Wilton Editor: Robert Wilton
<mailto:rwilton@cisco.com>"; <mailto:rwilton@cisco.com>";
description description
"This YANG module models L3 VLAN sub-interfaces"; "This YANG module models L3 VLAN sub-interfaces";
revision 2017-10-30 { revision 2019-03-05 {
description "Latest draft revision"; description "Latest draft revision";
reference reference
"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03"; "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05";
} }
/* /*
* Add support for the 802.1Q VLAN encapsulation syntax on layer 3 * Add support for the 802.1Q VLAN encapsulation syntax on layer 3
* terminated VLAN sub-interfaces. * terminated VLAN sub-interfaces.
*/ */
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" + augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" { "if-cmn:encaps-type" {
when when
"derived-from-or-self(../if:type, "derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or 'ianaift:ethernetCsmacd') or
derived-from-or-self(../if:type, derived-from-or-self(../if:type,
skipping to change at page 9, line 27 skipping to change at page 8, line 44
description description
"Applies only to Ethernet-like interfaces and "Applies only to Ethernet-like interfaces and
sub-interfaces"; sub-interfaces";
} }
description description
"Augment the generic interface encapsulation with an "Augment the generic interface encapsulation with an
basic 802.1Q VLAN encapsulation for sub-interfaces."; basic 802.1Q VLAN encapsulation for sub-interfaces.";
/* /*
* Matches a single VLAN Id, or pair of VLAN Ids to classify * Matches a single VLAN Id, or a pair of VLAN Ids to classify
* traffic into an L3 service. * traffic into an L3 service.
*/ */
case dot1q-vlan { case dot1q-vlan {
container dot1q-vlan { container dot1q-vlan {
must must
'count(../../if-cmn:forwarding-mode) = 0 or ' + 'count(../../if-cmn:forwarding-mode) = 0 or ' +
'derived-from-or-self(../../if-cmn:forwarding-mode,' + 'derived-from-or-self(../../if-cmn:forwarding-mode,' +
'"if-cmn:layer-3-forwarding")' { '"if-cmn:layer-3-forwarding")' {
error-message error-message
"If the interface forwarding-mode leaf is set then it "If the interface forwarding-mode leaf is set then it
must be set to an identity that derives from must be set to an identity that derives from
layer-3-forwarding"; layer-3-forwarding";
description description
"The forwarding-mode leaf on an interface can "The forwarding-mode leaf on an interface can
optionally be used to enforce consistency of optionally be used to enforce consistency of
configuration"; configuration";
} }
skipping to change at page 9, line 50 skipping to change at page 9, line 19
description description
"The forwarding-mode leaf on an interface can "The forwarding-mode leaf on an interface can
optionally be used to enforce consistency of optionally be used to enforce consistency of
configuration"; configuration";
} }
description description
"Match VLAN tagged frames with specific VLAN Ids"; "Match VLAN tagged frames with specific VLAN Ids";
container outer-tag { container outer-tag {
presence "The outermost VLAN tag exists"; must
'tag-type = "dot1q-types:s-vlan" or ' +
'tag-type = "dot1q-types:c-vlan"' {
error-message
"Only C-VLAN and S-VLAN tags can be matched";
description
"For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched";
}
description description
"Classifies traffic using the outermost VLAN tag on the "Classifies traffic using the outermost VLAN tag on the
frame."; frame.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
container second-tag { container second-tag {
must must
'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
skipping to change at page 10, line 28 skipping to change at page 10, line 7
specified and of S-VLAN type and the second outermost specified and of S-VLAN type and the second outermost
tag must be of C-VLAN tag type"; tag must be of C-VLAN tag type";
description description
"For IEEE 802.1Q interoperability, when matching two "For IEEE 802.1Q interoperability, when matching two
tags, it is required that the outermost tag exists and tags, it is required that the outermost tag exists and
is an S-VLAN, and the second outermost tag is a is an S-VLAN, and the second outermost tag is a
C-VLAN"; C-VLAN";
} }
presence "The second outermost VLAN tag exists"; presence "Also classify on the second outermost VLAN tag";
description description
"Classifies traffic using the second outermost VLAN tag "Classifies traffic using the second outermost VLAN tag
on the frame."; on the frame.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
} }
} }
} }
skipping to change at page 11, line 5 skipping to change at page 10, line 29
<CODE ENDS> <CODE ENDS>
6. Flexible Encapsulation YANG Module 6. Flexible Encapsulation YANG Module
This YANG module augments the encapsultion container defined in This YANG module augments the encapsultion container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
This YANG module also augments the interface container defined in This YANG module also augments the interface container defined in
[RFC8343]. [RFC8343].
<CODE BEGINS> file "ietf-flexible-encapsulation@2017-10-30.yang" <CODE BEGINS> file "ietf-flexible-encapsulation@2019-03-05.yang"
module ietf-flexible-encapsulation { module ietf-flexible-encapsulation {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"; "urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation";
prefix flex; prefix flex;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
skipping to change at page 11, line 39 skipping to change at page 11, line 17
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger WG Chair: Lou Berger
<mailto:lberger@labn.net> <mailto:lberger@labn.net>
WG Chair: Joel Jaeggli
<mailto:joelja@gmail.com>
WG Chair: Kent Watsen WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Editor: Robert Wilton Editor: Robert Wilton
<mailto:rwilton@cisco.com>"; <mailto:rwilton@cisco.com>";
description description
"This YANG module describes interface configuration for flexible "This YANG module describes interface configuration for flexible
VLAN matches and rewrites."; VLAN matches and rewrites.";
revision 2017-10-30 { revision 2019-03-05 {
description "Latest draft revision"; description "Latest draft revision";
reference reference
"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-03"; "Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-05";
} }
feature flexible-rewrites { feature flexible-rewrites {
description description
"This feature indicates whether the network element supports "This feature indicates whether the network element supports
specifying flexible rewrite operations"; specifying flexible rewrite operations";
} }
feature asymmetric-rewrites { feature asymmetric-rewrites {
description description
skipping to change at page 13, line 28 skipping to change at page 13, line 10
} // case untagged } // case untagged
case dot1q-priority-tagged { case dot1q-priority-tagged {
description description
"Match 802.1Q priority tagged Ethernet frames only"; "Match 802.1Q priority tagged Ethernet frames only";
container dot1q-priority-tagged { container dot1q-priority-tagged {
description "802.1Q priority tag match"; description "802.1Q priority tag match";
leaf tag-type { leaf tag-type {
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
mandatory true;
description "The 802.1Q tag type of matched priority description "The 802.1Q tag type of matched priority
tagged packets"; tagged packets";
} }
} }
} }
case dot1q-vlan-tagged { case dot1q-vlan-tagged {
container dot1q-vlan-tagged { container dot1q-vlan-tagged {
description "Matches VLAN tagged frames"; description "Matches VLAN tagged frames";
container outer-tag { container outer-tag {
presence "The outermost VLAN tag exists"; must
'tag-type = "dot1q-types:s-vlan" or ' +
'tag-type = "dot1q-types:c-vlan"' {
error-message
"Only C-VLAN and S-VLAN tags can be matched";
description
"For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched";
}
description description
"Classifies traffic using the outermost VLAN tag on the "Classifies traffic using the outermost VLAN tag on the
frame."; frame.";
uses uses
'dot1q-types:'+ 'dot1q-types:'+
'dot1q-tag-ranges-or-any-classifier-grouping'; 'dot1q-tag-ranges-or-any-classifier-grouping';
} }
skipping to change at page 14, line 19 skipping to change at page 14, line 12
specified and of S-VLAN type and the second specified and of S-VLAN type and the second
outermost tag must be of C-VLAN tag type"; outermost tag must be of C-VLAN tag type";
description description
"For IEEE 802.1Q interoperability, when matching two "For IEEE 802.1Q interoperability, when matching two
tags, it is required that the outermost tag exists tags, it is required that the outermost tag exists
and is an S-VLAN, and the second outermost tag is a and is an S-VLAN, and the second outermost tag is a
C-VLAN"; C-VLAN";
} }
presence "The second outermost VLAN tag exists"; presence "Also classify on the second VLAN tag";
description description
"Classifies traffic using the second outermost VLAN tag "Classifies traffic using the second outermost VLAN tag
on the frame."; on the frame.";
uses uses
'dot1q-types:'+ 'dot1q-types:'+
'dot1q-tag-ranges-or-any-classifier-grouping'; 'dot1q-tag-ranges-or-any-classifier-grouping';
} }
skipping to change at page 15, line 12 skipping to change at page 15, line 4
description "Flexible rewrite"; description "Flexible rewrite";
leaf pop-tags { leaf pop-tags {
type uint8 { type uint8 {
range 1..2; range 1..2;
} }
description "The number of tags to pop (or translate if used in description "The number of tags to pop (or translate if used in
conjunction with push-tags)"; conjunction with push-tags)";
} }
container push-tags { container push-tags {
presence
"802.1Q tags are pushed or translated";
description "The 802.1Q tags to push (or translate if used in description "The 802.1Q tags to push (or translate if used in
conjunction with pop-tags)"; conjunction with pop-tags)";
container outer-tag { container outer-tag {
presence must
"Indicates existence of the outermost VLAN tag to 'tag-type = "dot1q-types:s-vlan" or ' +
push/rewrite"; 'tag-type = "dot1q-types:c-vlan"' {
error-message
"Only C-VLAN and S-VLAN tags can be pushed";
description
"For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN
tags can be pushed";
}
description description
"The outermost VLAN tag to push onto the frame."; "The outermost VLAN tag to push onto the frame.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
container second-tag { container second-tag {
must must
'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
'tag-type = "dot1q-types:c-vlan"' { 'tag-type = "dot1q-types:c-vlan"' {
error-message error-message
"When pushing/rewriting two tags, the outermost tag must be "When pushing/rewriting two tags, the outermost tag must
specified and of S-VLAN type and the second outermost tag be specified and of S-VLAN type and the second outermost
must be of C-VLAN tag type"; tag must be of C-VLAN tag type";
description description
"For IEEE 802.1Q interoperability, when pushing two tags, "For IEEE 802.1Q interoperability, when pushing two tags,
it is required that the outermost tag exists and is an it is required that the outermost tag exists and is an
S-VLAN, and the second outermost tag is a C-VLAN"; S-VLAN, and the second outermost tag is a C-VLAN";
} }
presence presence
"Indicates existence of a second outermost VLAN tag to "In addition to the first tag, also push/rewrite a second
push/rewrite."; VLAN tag.";
description description
"The second outermost VLAN tag to push onto the frame."; "The second outermost VLAN tag to push onto the frame.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
}
}
} }
/* /*
* Grouping for all flexible rewrites of fields in the L2 header. * Grouping for all flexible rewrites of fields in the L2 header.
* *
* This currently only includes flexible tag rewrites, but is * This currently only includes flexible tag rewrites, but is
* designed to be extensible to cover rewrites of other fields in * designed to be extensible to cover rewrites of other fields in
* the L2 header if required. * the L2 header if required.
*/ */
grouping flexible-rewrite { grouping flexible-rewrite {
skipping to change at page 18, line 31 skipping to change at page 18, line 32
*/ */
container local-traffic-default-encaps { container local-traffic-default-encaps {
presence presence
"A local traffic default encapsulation has been "A local traffic default encapsulation has been
specified"; specified";
description description
"The 802.1Q VLAN tags to use by default for locally "The 802.1Q VLAN tags to use by default for locally
sourced traffic"; sourced traffic";
container outer-tag { container outer-tag {
presence must
"Indicates existence of the outermost VLAN tag"; 'tag-type = "dot1q-types:s-vlan" or ' +
'tag-type = "dot1q-types:c-vlan"' {
error-message
"Only C-VLAN and S-VLAN tags can be matched";
description
"For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched";
}
description description
"The outermost VLAN tag for locally sourced traffic"; "The outermost VLAN tag for locally sourced traffic";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
container second-tag { container second-tag {
must must
'../outer-tag/tag-type = "dot1q-types:s-vlan" and ' + '../outer-tag/tag-type = "dot1q-types:s-vlan" and ' +
skipping to change at page 23, line 43 skipping to change at page 24, line 7
Parsons, and Dan Romascanu for their help progressing this draft. Parsons, and Dan Romascanu for their help progressing this draft.
The authors would also like to thank Alex Campbell, Eric Gray, Giles The authors would also like to thank Alex Campbell, Eric Gray, Giles
Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton,
John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir
Vassilev, and members of the IEEE 802.1 WG for their helpful reviews Vassilev, and members of the IEEE 802.1 WG for their helpful reviews
and feedback on this draft. and feedback on this draft.
9. ChangeLog 9. ChangeLog
9.1. WG version -04 XXX, RFC Editor, please delete this change log before publication.
9.1. WG version -05
o Incorporate feedback from IEEE 802.1 WG, John Messenger in
particular.
o Adding must contraints to ensure outer tags are always matched to
C-VLAN and S-VLAN tags.
o Fixed bug where second tag could be matched without outer tag, and
where tags must not be specified.
9.2. WG version -04
o Added examples o Added examples
9.2. WG version -03 9.3. WG version -03
o Fix namespace bug in XPath identity references, removed extraneous o Fix namespace bug in XPath identity references, removed extraneous
'dot1q-tag' containers. 'dot1q-tag' containers.
9.3. WG version -02 9.4. WG version -02
o Use explicit containers for outer and inner tags rather than o Use explicit containers for outer and inner tags rather than
lists. lists.
9.4. WG version -01 9.5. WG version -01
o Tweaked the abstract. o Tweaked the abstract.
o Removed unnecessary feature for the L3 sub-interface module. o Removed unnecessary feature for the L3 sub-interface module.
o Update the 802.1Qcp type references. o Update the 802.1Qcp type references.
o Remove extra tag container for L3 sub-interfaces YANG. o Remove extra tag container for L3 sub-interfaces YANG.
9.5. Version -04 9.6. Version -04
o IEEE 802.1 specific types have been removed from the draft. These o IEEE 802.1 specific types have been removed from the draft. These
are now referenced from the 802.1Qcp draft YANG modules. are now referenced from the 802.1Qcp draft YANG modules.
o Fixed errors in the xpath expressions. o Fixed errors in the xpath expressions.
9.6. Version -03 9.7. Version -03
o Incorporates feedback received from presenting to the IEEE 802.1 o Incorporates feedback received from presenting to the IEEE 802.1
WG. WG.
o Updates the modules for double tag matches/rewrites to restrict o Updates the modules for double tag matches/rewrites to restrict
the outer tag type to S-VLAN and inner tag type to C-VLAN. the outer tag type to S-VLAN and inner tag type to C-VLAN.
o Updates the introduction to indicate primary use case is for IETF o Updates the introduction to indicate primary use case is for IETF
forwarding protocols. forwarding protocols.
o Updates the objectives to make IEEE 802.1Q bridge interoperability o Updates the objectives to make IEEE 802.1Q bridge interoperability
a key objective. a key objective.
10. IANA Considerations 10. IANA Considerations
This document defines several new YANG module and the authors This document defines two new YANG module and the authors politely
politely request that IANA assigns unique names to the YANG module request that IANA assigns unique names to the YANG module files
files contained within this draft, and also appropriate URIs in the contained within this draft, and also appropriate URIs in the "IETF
"IETF XML Registry". XML Registry".
11. Security Considerations 11. Security Considerations
The YANG module defined in this memo is designed to be accessed via The YANG module defined in this memo is designed to be accessed via
the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is the NETCONF protocol RFC 6241 [RFC6241]. The lowest NETCONF layer is
the secure transport layer and the mandatory to implement secure the secure transport layer and the mandatory to implement secure
transport is SSH RFC 6242 [RFC6242]. The NETCONF access control transport is SSH RFC 6242 [RFC6242]. The NETCONF access control
model RFC 6536 [RFC6536] provides the means to restrict access for model RFC 6536 [RFC6536] provides the means to restrict access for
particular NETCONF users to a pre-configured subset of all available particular NETCONF users to a pre-configured subset of all available
NETCONF protocol operations and content. NETCONF protocol operations and content.
skipping to change at page 27, line 38 skipping to change at page 28, line 12
o second-tag/vlan-id o second-tag/vlan-id
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-netmod-intf-ext-yang] [I-D.ietf-netmod-intf-ext-yang]
Wilton, R., Ball, D., tsingh@juniper.net, t., and S. Wilton, R., Ball, D., tsingh@juniper.net, t., and S.
Sivaraj, "Common Interface Extension YANG Data Models", Sivaraj, "Common Interface Extension YANG Data Models",
draft-ietf-netmod-intf-ext-yang-05 (work in progress), draft-ietf-netmod-intf-ext-yang-07 (work in progress),
July 2017. March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014, RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
skipping to change at page 28, line 15 skipping to change at page 28, line 38
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
12.2. Informative References 12.2. Informative References
[dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks - [dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged
Amendment: YANG Data Model", 2018. Networks - Amendment: YANG Data Model", 2018.
[I-D.ietf-bess-l2vpn-yang] [I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress),
February 2018. October 2018.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>. <https://www.rfc-editor.org/info/rfc4448>.
skipping to change at page 29, line 10 skipping to change at page 29, line 34
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536,
DOI 10.17487/RFC6536, March 2012, DOI 10.17487/RFC6536, March 2012,
<https://www.rfc-editor.org/info/rfc6536>. <https://www.rfc-editor.org/info/rfc6536>.
[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>.
Appendix A. Comparison with the IEEE 802.1Q Configuration Model Appendix A. Comparison with the IEEE 802.1Q Configuration Model
In addition to the sub-interface based YANG model proposed here, the In addition to the sub-interface based YANG model proposed here, the
IEEE 802.1Q working group is also developing a YANG model for the IEEE 802.1Q working group has developed a YANG model for the
configuration of 802.1Q VLANs. This raises the valid question as to configuration of 802.1Q VLANs. This raises the valid question as to
whether the models overlap and whether it is necessary or beneficial whether the models overlap and whether it is necessary or beneficial
to have two different models for superficially similar constructs. to have two different models for superficially similar constructs.
This section aims to answer that question by summarizing and This section aims to answer that question by summarizing and
comparing the two models. comparing the two models.
A.1. Sub-interface based configuration model overview A.1. Sub-interface based configuration model overview
The key features of the sub-interface based configuration model can The key features of the sub-interface based configuration model can
be summarized as: be summarized as:
 End of changes. 69 change blocks. 
125 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/