draft-ietf-netmod-sub-intf-vlan-model-06.txt   draft-ietf-netmod-sub-intf-vlan-model-07.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: Standards Track T. Singh Intended status: Standards Track T. Singh
Expires: May 7, 2020 Cisco Systems Expires: January 14, 2021 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
November 4, 2019 July 13, 2020
Sub-interface VLAN YANG Data Models Sub-interface VLAN YANG Data Models
draft-ietf-netmod-sub-intf-vlan-model-06 draft-ietf-netmod-sub-intf-vlan-model-07
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. L2VPN 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. from an IEEE 802.1Q compliant bridge.
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 The YANG data models in this document conforms to the Network
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 May 7, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 4 3. Interface VLAN Encapsulation Model . . . . . . . . . . . . . 4
4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5 4. Interface Flexible Encapsulation Model . . . . . . . . . . . 5
5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7 5. VLAN Encapsulation YANG Module . . . . . . . . . . . . . . . 7
6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10 6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 22
7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. WG version -05 . . . . . . . . . . . . . . . . . . . . . 24 9.1. WG version -07 and -06 . . . . . . . . . . . . . . . . . 26
9.2. WG version -04 . . . . . . . . . . . . . . . . . . . . . 24 9.2. WG version -05 . . . . . . . . . . . . . . . . . . . . . 26
9.3. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24 9.3. WG version -04 . . . . . . . . . . . . . . . . . . . . . 26
9.4. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24 9.4. WG version -03 . . . . . . . . . . . . . . . . . . . . . 27
9.5. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24 9.5. WG version -02 . . . . . . . . . . . . . . . . . . . . . 27
9.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24 9.6. WG version -01 . . . . . . . . . . . . . . . . . . . . . 27
9.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24 9.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25 10.1. YANG Module Registrations . . . . . . . . . . . . . . . 27
11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. ietf-if-vlan-encapsulation.yang . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. ietf-if-flexible-encapsulation.yang . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 31
A.1. Sub-interface based configuration model overview . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 32
A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 33
A.3. Possible Overlap Between the Two Models . . . . . . . . . 31 A.1. Sub-interface based configuration model overview . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 34
A.3. Possible Overlap Between the Two Models . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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
configuration applied to them. configuration applied to them.
The purpose of these models is to allow IETF defined forwarding The purpose of these models is to allow IETF defined forwarding
protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448] protocols, for example, IPv6 [RFC2460], Ethernet Pseudo Wires
and VPLS [RFC4761] [RFC4762] to be configurable via YANG when [RFC4448] and VPLS [RFC4761] [RFC4762], when configured via
interoperating with VLAN tagged traffic received from an IEEE 802.1Q appropriate YANG data models [RFC8344] [I-D.ietf-bess-l2vpn-yang], to
interoperate with VLAN tagged traffic received from an IEEE 802.1Q
compliant bridge. compliant bridge.
In the case of layer 2 Ethernet services, the flexible encapsulation In the case of layer 2 Ethernet services, the flexible encapsulation
module also supports flexible rewriting of the VLAN tags contained module also supports flexible rewriting of the VLAN tags contained in
the in frame header. the frame header.
For reference, a comparison between the sub-interface based YANG For reference, a comparison between the sub-interface based YANG
model documented in this draft and an IEEE 802.1Q bridge model is model documented in this draft and an IEEE 802.1Q bridge model is
described in Appendix A. described in Appendix A.
In summary, the YANG modules defined in this internet draft are: In summary, the YANG modules defined in this internet draft are:
if-l3-vlan.yang - Defines the model for basic classification of ietf-if-vlan-encapsulation.yang - Defines the model for basic
VLAN tagged traffic to L3 transport services classification of VLAN tagged traffic, normally to L3 packet
forwarding services
flexible-encapsulation.yang - Defines the model for flexible ietf-if-flexible-encapsulation.yang - Defines the model for
classification of Ethernet/VLAN traffic to L2 transport services flexible classification of Ethernet/VLAN traffic, normally to L2
frame forwarding services
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
Sub-interface: A sub-interface is a small augmentation of a regular The term 'sub-interface' is defined in section 2.6 of Interface
interface in the standard YANG module for Interface Management that Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
represents a subset of the traffic handled by its parent interface.
As such, it supports both configuration and operational data using
any other YANG models that augment or reference interfaces in the
normal way. It is defined in Interface Extensions YANG
[I-D.ietf-netmod-intf-ext-yang].
1.2. Tree Diagrams 1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[RFC8340]. [RFC8340].
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
skipping to change at page 4, line 30 skipping to change at page 4, line 31
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.
3. L3 Interface VLAN Model 3. Interface VLAN Encapsulation Model
The L3 Interface VLAN model provides appropriate leaves for The Interface VLAN encapsulation model provides appropriate leaves
termination of an 802.1Q VLAN tagged segment to a sub-interface based for termination of an 802.1Q VLAN tagged segment to a sub-interface
L3 service. It allows for termination of traffic with up to two (or interface) based L3 service, such as IP. It allows for
802.1Q VLAN tags. termination of traffic with one or two 802.1Q VLAN tags.
The "if-l3-vlan" YANG module has the following structure: The L3 service must be configured via a separate YANG data model,
e.g., [RFC8344]. A short example of configuring 802.1Q VLAN sub-
interfaces with IP using YANG is provided in Section 7.1.
module: ietf-if-l3-vlan The "ietf-if-vlan-encapsulation" YANG module has the following
structure:
module: ietf-if-vlan-encapsulation
augment /if:interfaces/if:interface/if-ext:encapsulation augment /if:interfaces/if:interface/if-ext:encapsulation
/if-ext:encaps-type: /if-ext: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 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 vlanid +--rw vlan-id vlanid
4. Flexible Encapsulation Model 4. Interface Flexible Encapsulation Model
The Flexible Encapsulation model is designed to allow for the The Interface Flexible Encapsulation model is designed to allow for
flexible provisioning of layer 2 services. It provides the the flexible provisioning of layer 2 services. It provides the
capability to classify Ethernet/VLAN frames received on an Ethernet capability to classify and demultiplex Ethernet/VLAN frames received
trunk interface to sub-interfaces based on the fields available in on an Ethernet trunk interface to sub-interfaces based on the fields
the layer 2 headers. Once classified to sub-interfaces, it provides available in the layer 2 headers. Once classified to sub-interfaces,
the capability to selectively modify fields within the layer 2 it provides the capability to selectively modify fields within the
headers before the frame is handed off to the appropriate forwarding layer 2 frame header before the frame is handed off to the
code for further handling. appropriate forwarding code for further handling. The forwarding
instance, e.g., L2VPN, VPLS, etc., is configured using a separate
YANG configuration model defined elsewhere, e.g.,
[I-D.ietf-bess-l2vpn-yang].
The model supports a common core set of layer 2 header matches based 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 on the 802.1Q tag type and VLAN Ids contained within the header up to
a tag stack depth of two tags. a tag stack depth of two tags.
The model supports flexible rewrites of the layer 2 frame header for 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 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 model also allows a flexible encapsulation and rewrite to be
configured directly on an Ethernet or LAG interface without
configuring seperate child sub-interfaces. Ingress frames that do
not match the encapsulation are dropped. Egress frames MUST conform
to the encapsulation.
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: A short example of configuring 802.1Q VLAN sub-interfaces with L2VPN
using YANG is provided in Section 7.2.
module: ietf-flexible-encapsulation The "ietf-if-flexible-encapsulation" YANG module has the following
structure:
module: ietf-if-flexible-encapsulation
augment /if:interfaces/if:interface/if-ext:encapsulation augment /if:interfaces/if:interface/if-ext:encapsulation
/if-ext:encaps-type: /if-ext: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
skipping to change at page 7, line 9 skipping to change at page 7, line 39
| +--rw tag-type dot1q-tag-type | +--rw tag-type dot1q-tag-type
| +--rw vlan-id 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 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 vlanid +--rw vlan-id vlanid
5. L3 Interface VLAN YANG Module 5. VLAN Encapsulation YANG Module
This YANG module augments the encapsultion container defined in This YANG module augments the 'encapsulation' container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. ietf-if-extensions.yang [I-D.ietf-netmod-intf-ext-yang]. It also
contains references to [RFC8343], [RFC7224], and [IEEE802.1Qcp-2018].
<CODE BEGINS> file "ietf-if-l3-vlan@2019-11-04.yang" <CODE BEGINS> file "ietf-if-vlan-encapsulation@2020-07-13.yang"
module ietf-if-l3-vlan { module ietf-if-vlan-encapsulation {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation";
namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"; prefix if-vlan;
prefix if-l3-vlan;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference
"RFC 8343: A YANG Data Model For Interface Management";
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
reference
"RFC 7224: IANA Interface Type YANG Module";
} }
import ieee802-dot1q-types { import ieee802-dot1q-types {
prefix dot1q-types; prefix dot1q-types;
reference
"IEEE Std 802.1Qcp-2018: IEEE Standard for Local and
metropolitan area networks -- Bridges and Bridged Networks --
Amendment 30: YANG Data Model";
} }
import ietf-if-extensions { import ietf-if-extensions {
prefix if-ext; prefix if-ext;
reference
"RFC XXXX: Common Interface Extension YANG Data Models";
} }
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>
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 configuration to classify IEEE 802.1Q
Copyright (c) 2019 IETF Trust and the persons identified as VLAN tagged Ethernet traffic by exactly matching the tag type
and VLAN identifier of one or two 802.1Q VLAN tags in the frame.
Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.
revision 2019-11-04 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
description "Latest draft revision"; NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-07-13 {
description
"Latest draft revision";
reference reference
"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-06"; "RFC XXXX: Sub-interface VLAN YANG Data Models";
} }
/* augment "/if:interfaces/if:interface/if-ext:encapsulation/"
* Add support for the 802.1Q VLAN encapsulation syntax on layer 3 + "if-ext:encaps-type" {
* terminated VLAN sub-interfaces. when "derived-from-or-self(../if:type,
*/ 'ianaift:ethernetCsmacd') or
augment "/if:interfaces/if:interface/if-ext:encapsulation/" + derived-from-or-self(../if:type,
"if-ext:encaps-type" { 'ianaift:ieee8023adLag') or
when derived-from-or-self(../if:type, 'ianaift:l2vlan') or
"derived-from-or-self(../if:type, derived-from-or-self(../if:type,
'ianaift:ethernetCsmacd') or 'if-ext:ethSubInterface')" {
derived-from-or-self(../if:type, description
'ianaift:ieee8023adLag') or "Applies only to Ethernet-like interfaces and
derived-from-or-self(../if:type, sub-interfaces.";
'if-ext:ethSubInterface')" {
description
"Applies only to Ethernet-like interfaces and
sub-interfaces";
} }
description description
"Augment the generic interface encapsulation with an "Augment the generic interface encapsulation with basic 802.1Q
basic 802.1Q VLAN encapsulation for sub-interfaces."; VLAN tag classifications";
/*
* Matches a single VLAN Id, or a pair of VLAN Ids to classify
* traffic into an L3 service.
*/
case dot1q-vlan { case dot1q-vlan {
container dot1q-vlan { container dot1q-vlan {
must
'count(../../if-ext:forwarding-mode) = 0 or ' +
'derived-from-or-self(../../if-ext:forwarding-mode,' +
'"if-ext:layer-3-forwarding")' {
error-message
"If the interface forwarding-mode leaf is set then it
must be set to an identity that derives from
layer-3-forwarding";
description
"The forwarding-mode leaf on an interface can
optionally be used to enforce consistency of
configuration";
}
description description
"Match VLAN tagged frames with specific VLAN Ids"; "Classifies 802.1Q VLAN tagged Ethernet frames to a
sub-interface (or interface) by exactly matching the
number of tags, tag type(s) and VLAN identifier(s).
Only frames matching the classification configured on a
sub-interface/interface are processed on that
sub-interface/interface.
Frames that do not match any sub-interface are processed
directly on the parent interface, if it is associated with
a forwarding instance, otherwise they are dropped.";
container outer-tag { container outer-tag {
must must 'tag-type = "dot1q-types:s-vlan" or '
'tag-type = "dot1q-types:s-vlan" or ' + + 'tag-type = "dot1q-types:c-vlan"' {
'tag-type = "dot1q-types:c-vlan"' {
error-message error-message
"Only C-VLAN and S-VLAN tags can be matched"; "Only C-VLAN and S-VLAN tags can be matched.";
description description
"For IEEE 802.1Q interoperability, only C-VLAN and "For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched"; S-VLAN tags are matched.";
} }
description description
"Classifies traffic using the outermost VLAN tag on the "Specifies the VLAN tag values to match against the
frame."; outermost (first) 802.1Q VLAN tag in 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 matching two tags, the outermost tag must be "When matching two 802.1Q VLAN tags, the outermost
specified and of S-VLAN type and the second outermost (first) tag in the frame MUST be specified and be of
tag must be of C-VLAN tag type"; S-VLAN type and the second tag in the frame 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 802.1Q VLAN tags, it is REQUIRED that the outermost
is an S-VLAN, and the second outermost tag is a tag exists and is an S-VLAN, and the second tag is a
C-VLAN"; C-VLAN.";
} }
presence "Also classify on the second outermost VLAN tag"; presence "Classify frames that have two 802.1Q VLAN tags.";
description description
"Classifies traffic using the second outermost VLAN tag "Specifies the VLAN tag values to match against the
on the frame."; second outermost 802.1Q VLAN tag in the frame.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
} }
} }
} }
} }
<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 'encapsulation' container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang]. ietf-if-extensions.yang [I-D.ietf-netmod-intf-ext-yang]. This YANG
module also augments the 'interface' list entry defined in [RFC8343].
This YANG module also augments the interface container defined in It also contains references to [RFC7224], and [IEEE802.1Qcp-2018].
[RFC8343].
<CODE BEGINS> file "ietf-flexible-encapsulation@2019-11-04.yang" <CODE BEGINS> file "ietf-if-flexible-encapsulation@2020-07-13.yang"
module ietf-flexible-encapsulation { module ietf-if-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-if-flexible-encapsulation";
prefix if-flex;
prefix flex;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference
"RFC 8343: A YANG Data Model For Interface Management";
} }
import iana-if-type { import iana-if-type {
prefix ianaift; prefix ianaift;
reference
"RFC 7224: IANA Interface Type YANG Module";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE Std 802.1Qcp-2018: IEEE Standard for Local and
metropolitan area networks -- Bridges and Bridged Networks --
Amendment 30: YANG Data Model";
} }
import ietf-if-extensions { import ietf-if-extensions {
prefix if-ext; prefix if-ext;
} reference
"RFC XXXX: Common Interface Extension YANG Data Models";
import ieee802-dot1q-types {
prefix dot1q-types;
} }
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>
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. classification and rewrites of IEEE 802.1Q VLAN tagged Ethernet
traffic.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices."; for full legal notices.
revision 2019-11-04 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
description "Latest draft revision"; NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-07-13 {
description
"Latest draft revision";
reference reference
"Internet-Draft draft-ietf-netmod-sub-intf-vlan-model-06"; "RFC XXXX: Sub-interface VLAN YANG Data Models";
} }
feature flexible-rewrites { feature flexible-rewrites {
description description
"This feature indicates whether the network element supports "This feature indicates that the network element supports
specifying flexible rewrite operations"; specifying flexible rewrite operations.";
} }
feature asymmetric-rewrites { feature asymmetric-rewrites {
description description
"This feature indicates whether the network element supports "This feature indicates that the network element supports
specifying different rewrite operations for the ingress specifying different rewrite operations for the ingress
rewrite operation and egress rewrite operation."; rewrite operation and egress rewrite operation.";
} }
feature dot1q-tag-rewrites { feature dot1q-tag-rewrites {
description description
"This feature indicates whether the network element supports "This feature indicates that the network element supports the
the flexible rewrite functionality specifying flexible 802.1Q flexible rewrite functionality specifying 802.1Q tag
tag rewrites"; 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 { grouping flexible-match {
description "Flexible match"; description
"Represents a flexible frame classification:
The rules for a flexible match are:
1. Match-type: default, untagged, priority tag, or tag
stack.
2. Each tag in the stack of tags matches:
a. tag type (802.1Q or 802.1ad) +
b. tag value:
i. single tag
ii. set of tag ranges/values.
iii. 'any' keyword";
choice match-type { choice match-type {
mandatory true; mandatory true;
description "Provides a choice of how the frames may be
matched"; description
"Provides a choice of how the frames may be
matched";
case default { case default {
description "Default match"; description
"Default match";
leaf default { leaf default {
type empty; type empty;
description description
"Default match. Matches all traffic not matched to any "Default match. Matches all traffic not matched to any
other peer sub-interface by a more specific other peer sub-interface by a more specific
encapsulation."; encapsulation.";
} // leaf default
} // case default }
}
case untagged { case untagged {
description "Match untagged Ethernet frames only"; description
"Match untagged Ethernet frames only";
leaf untagged { leaf untagged {
type empty; type empty;
description description
"Untagged match. Matches all untagged traffic."; "Untagged match. Matches all untagged traffic.";
} // leaf 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; mandatory true;
description "The 802.1Q tag type of matched priority
tagged packets"; description
"The 802.1Q tag type of matched priority
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 {
must must 'tag-type = "dot1q-types:s-vlan" or '
'tag-type = "dot1q-types:s-vlan" or ' + + 'tag-type = "dot1q-types:c-vlan"' {
'tag-type = "dot1q-types:c-vlan"' {
error-message error-message
"Only C-VLAN and S-VLAN tags can be matched"; "Only C-VLAN and S-VLAN tags can be matched.";
description description
"For IEEE 802.1Q interoperability, only C-VLAN and "For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched"; S-VLAN tags can be matched.";
} }
description description
"Classifies traffic using the outermost VLAN tag on the "Classifies traffic using the outermost (first) VLAN
frame."; tag on the frame.";
uses uses "dot1q-types:"
'dot1q-types:'+ + "dot1q-tag-ranges-or-any-classifier-grouping";
'dot1q-tag-ranges-or-any-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 matching two tags, the outermost tag must be "When matching two tags, the outermost (first) tag
specified and of S-VLAN type and the second must be 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 (first) tag
and is an S-VLAN, and the second outermost tag is a exists and is an S-VLAN, and the second outermost
C-VLAN"; tag is a C-VLAN.";
} }
presence "Also classify on the second VLAN tag"; 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';
} }
leaf match-exact-tags { leaf match-exact-tags {
type empty; type empty;
description description
"If set, indicates that all 802.1Q VLAN tags in the "If set, indicates that all 802.1Q VLAN tags in the
Ethernet frame header must be explicitly matched, i.e. Ethernet frame header must be explicitly matched, i.e.
the EtherType following the matched tags must not be a the EtherType following the matched tags must not be a
802.1Q tag EtherType. If unset then extra 802.1Q VLAN 802.1Q tag EtherType. If unset then extra 802.1Q VLAN
tags are allowed."; tags are allowed.";
skipping to change at page 14, line 42 skipping to change at page 16, line 4
leaf match-exact-tags { leaf match-exact-tags {
type empty; type empty;
description description
"If set, indicates that all 802.1Q VLAN tags in the "If set, indicates that all 802.1Q VLAN tags in the
Ethernet frame header must be explicitly matched, i.e. Ethernet frame header must be explicitly matched, i.e.
the EtherType following the matched tags must not be a the EtherType following the matched tags must not be a
802.1Q tag EtherType. If unset then extra 802.1Q VLAN 802.1Q tag EtherType. If unset then extra 802.1Q VLAN
tags are allowed."; 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 dot1q-tag-rewrite { grouping dot1q-tag-rewrite {
description "Flexible rewrite"; description
"Flexible rewrite grouping. Can be either be expressed
symmetrically, or independently in the ingress and/or egress
directions.";
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
conjunction with push-tags)"; description
"The number of 802.1Q VLAN tags to pop, or translate if used
in conjunction with push-tags.
Popped tags are the outermost tags on the frame.";
} }
container push-tags { container push-tags {
presence presence "802.1Q tags are pushed or translated";
"802.1Q tags are pushed or translated";
description "The 802.1Q tags to push (or translate if used in description
conjunction with pop-tags)"; "The 802.1Q tags to push on the front of the frame, or
translate if configured in conjunction with pop-tags.";
container outer-tag { container outer-tag {
must must 'tag-type = "dot1q-types:s-vlan" or '
'tag-type = "dot1q-types:s-vlan" or ' + + 'tag-type = "dot1q-types:c-vlan"' {
'tag-type = "dot1q-types:c-vlan"' {
error-message error-message "Only C-VLAN and S-VLAN tags can be pushed.";
"Only C-VLAN and S-VLAN tags can be pushed";
description description
"For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN "For IEEE 802.1Q interoperability, only C-VLAN and S-VLAN
tags can be pushed"; tags can be pushed.";
} }
description description
"The outermost VLAN tag to push onto the frame."; "The outermost (first) 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 "When pushing/rewriting two tags, the outermost tag must
be specified and of S-VLAN type and the second outermost be 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 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
"In addition to the first tag, also push/rewrite a second "In addition to the first tag, also push/rewrite a second
VLAN tag."; 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;
} }
} }
skipping to change at page 16, line 16 skipping to change at page 17, line 29
VLAN tag."; 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.
*
* 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 { grouping flexible-rewrite {
description "Flexible rewrite"; description
"Grouping for flexible rewrites of fields in the L2 header.
Restricted to flexible 802.1Q VLAN tag rewrites, but could be
extended to cover rewrites of other fields in the L2 header in
future.";
/*
* Tag rewrite.
*
* All tag rewrites are formed using a combination of pop-tags
* and push-tags operations.
*/
container dot1q-tag-rewrite { container dot1q-tag-rewrite {
if-feature dot1q-tag-rewrites; if-feature "dot1q-tag-rewrites";
description "Tag rewrite. Translate operations are expressed
as a combination of tag push and pop operations."; description
"802.1Q VLAN tag rewrite.
Translate operations are expressed as a combination of tag
push and pop operations. E.g., translating the outer tag is
expressed as popping a single tag, and pushing a single tag.
802.1Q tags that are translated SHOULD preserve the PCP and
DEI fields unless if a different QoS behavior has been
specified.";
uses dot1q-tag-rewrite; uses dot1q-tag-rewrite;
} }
} }
augment "/if:interfaces/if:interface/if-ext:encapsulation/" + augment "/if:interfaces/if:interface/if-ext:encapsulation/"
"if-ext:encaps-type" { + "if-ext: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, 'ianaift:ieee8023adLag') or
'ianaift:ieee8023adLag') or derived-from-or-self(../if:type, 'ianaift:l2vlan') or
derived-from-or-self(../if:type, derived-from-or-self(../if:type,
'if-ext:ethSubInterface')" { 'if-ext:ethSubInterface')" {
description
"Applies only to Ethernet-like interfaces and description
sub-interfaces"; "Applies only to Ethernet-like interfaces and
sub-interfaces.";
} }
description description
"Add flexible match and rewrite for VLAN sub-interfaces"; "Augment the generic interface encapsulation with 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 { case flexible {
description "Flexible encapsulation and rewrite"; description
"Flexible encapsulation and rewrite";
container flexible { container flexible {
description "Flexible encapsulation and rewrite"; description
"Flexible encapsulation allows for the matching of ranges
and sets of 802.1Q VLAN Tags and performing rewrite
operations on the VLAN tags.
The structure is also designed to be extended to allow for
matching/rewriting other fields within the L2 frame header
if required.";
container match { container match {
description description
"The match used to classify frames to this interface"; "Flexibly classifies Ethernet frames to a sub-interface
(or interface) based on the L2 header fields.
Only frames matching the classification configured on a
sub-interface/interface are processed on that
sub-interface/interface.
Frames that do not match any sub-interface are processed
directly on the parent interface, if it is associated
with a forwarding instance, otherwise they are dropped.
If a frame could be classified to multiple
sub-interfaces then they get classified to the
sub-interface with the most specific match. E.g.,
matching two VLAN tags in the frame is more specific
than matching the outermost VLAN tag, which is more
specific than the catch all 'default' match.";
uses flexible-match; uses flexible-match;
} }
container rewrite { container rewrite {
if-feature flexible-rewrites; if-feature "flexible-rewrites";
description "L2 frame rewrite operations";
description
"L2 frame rewrite operations.
Rewrites allows for modifications to the L2 frame header
as it transits the interface/sub-interface. Examples
include adding a VLAN tag, removing a VLAN tag, or
rewriting the VLAN Id carried in a VLAN tag.";
choice direction { choice direction {
description description
"Whether the rewrite policy is symmetrical or "Whether the rewrite policy is symmetrical or
asymmetrical"; asymmetrical.";
case symmetrical { case symmetrical {
container symmetrical { container symmetrical {
uses flexible-rewrite; uses flexible-rewrite;
description description
"Symmetrical rewrite. Expressed in the ingress "Symmetrical rewrite. Expressed in the ingress
direction, but the reverse operation is applied to direction, but the reverse operation is applied to
egress traffic"; egress traffic.
E.g., if a tag is pushed on ingress traffic, then
the reverse operation is a 'pop 1', that is
performed on traffic egressing the interface, so
a peer device sees a consistent L2 encapsulation
for both ingress and egress traffic.";
} }
} }
/*
* Allow asymmetrical rewrites to be specified.
*/
case asymmetrical { case asymmetrical {
if-feature asymmetric-rewrites; if-feature "asymmetric-rewrites";
description "Asymmetrical rewrite";
description
"Asymmetrical rewrite.
Rewrite operations may be specified in only a single
direction, or different rewrite operations may be
specified in each direction.";
container ingress { container ingress {
uses flexible-rewrite; uses flexible-rewrite;
description "Ingress rewrite";
description
"A rewrite operation that only applies to ingress
traffic.
Ingress rewrite operations are performed before
the frame is subsequently processed by the
forwarding operation.";
} }
container egress { container egress {
uses flexible-rewrite; uses flexible-rewrite;
description "Egress rewrite";
description
"A rewrite operation that only applies to egress
traffic.";
} }
} }
} }
} }
/*
* For encapsulations that match a range of VLANs (or Any),
* allow configuration to specify the default 802.1Q VLAN tag
* values to use for any traffic that is locally sourced from
* an interface on the device.
*/
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 "Specifies the 802.1Q VLAN tags to use by default for
sourced traffic"; locally sourced traffic from the interface.
Used for encapsulations that match a range of VLANs (or
'any'), where the source VLAN Ids are otherwise
ambiguous.";
container outer-tag { container outer-tag {
must must 'tag-type = "dot1q-types:s-vlan" or '
'tag-type = "dot1q-types:s-vlan" or ' + + 'tag-type = "dot1q-types:c-vlan"' {
'tag-type = "dot1q-types:c-vlan"' {
error-message error-message
"Only C-VLAN and S-VLAN tags can be matched"; "Only C-VLAN and S-VLAN tags can be matched.";
description description
"For IEEE 802.1Q interoperability, only C-VLAN and "For IEEE 802.1Q interoperability, only C-VLAN and
S-VLAN tags can be matched"; S-VLAN tags can be matched.";
} }
description description
"The outermost VLAN tag for locally sourced traffic"; "The outermost (first) 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 '
'tag-type = "dot1q-types:c-vlan"' { + 'tag-type = "dot1q-types:c-vlan"' {
error-message error-message
"When specifying two tags, the outermost tag must be "When specifying two tags, the outermost (first) tag
specified and of S-VLAN type and the second outermost must be specified and of S-VLAN type and the second
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 specifying two "For IEEE 802.1Q interoperability, when specifying
tags, it is required that the outermost tag exists and two tags, it is required that the outermost (first)
is an S-VLAN, and the second outermost tag is a tag exists and is an S-VLAN, and the second
C-VLAN"; outermost tag is a C-VLAN.";
} }
presence presence
"Indicates existence of a second outermost VLAN tag."; "Indicates existence of a second outermost VLAN tag.";
description description
"The second outermost VLAN tag for locally sourced "The second outermost VLAN tag for locally sourced
traffic"; traffic.";
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Examples 7. Examples
The following sections give examples of configuring a sub-interface The following sections give examples of configuring a sub-interface
supporting L3 forwarding, and also a sub-interface being used in supporting L3 forwarding, and a sub-interface being used in
conjunction with the IETF L2VPN YANG model conjunction with the IETF L2VPN YANG model
[I-D.ietf-bess-l2vpn-yang]. [I-D.ietf-bess-l2vpn-yang].
7.1. Layer 3 sub-interfaces with IPv6 7.1. Layer 3 sub-interfaces with IPv6
This example illustrates a layer 3 sub-interface configured to match This example illustrates two layer sub-interfaces, 'eth0.1' and
traffic with a S-VLAN tag of 10, and C-VLAN tag of 20. 'eth0.2', both are child interfaces of the Ethernet interface 'eth0'.
'eth0.1' is configured to match traffic with two VLAN tags: an outer
S-VLAN of 10 and an inner C-VLAN of 20.
'eth0.2' is configured to match traffic with a single S-VLAN tag,
with VLAN Id 11.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types" xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common"> xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
</interface> </interface>
<interface> <interface>
<name>eth0.1</name> <name>eth0.1</name>
<type>ianaift:l2vlan</type> <type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface> <if-ext:parent-interface>eth0</if-ext:parent-interface>
<if-cmn:encapsulation> <if-ext:encapsulation>
<dot1q-vlan <dot1q-vlan
xmlns="urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"> xmlns=
"urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation">
<outer-tag> <outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type> <tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>10</vlan-id> <vlan-id>10</vlan-id>
</outer-tag> </outer-tag>
<second-tag> <second-tag>
<tag-type>dot1q-types:c-vlan</tag-type> <tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>20</vlan-id> <vlan-id>20</vlan-id>
</second-tag> </second-tag>
</dot1q-vlan> </dot1q-vlan>
</if-cmn:encapsulation> </if-ext:encapsulation>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<forwarding>true</forwarding> <forwarding>true</forwarding>
<address> <address>
<ip>2001:db8::10</ip> <ip>2001:db8:10::1</ip>
<prefix-length>32</prefix-length> <prefix-length>48</prefix-length>
</address> </address>
</ipv6> </ipv6>
</interface> </interface>
<interface> <interface>
<name>eth0.2</name> <name>eth0.2</name>
<type>ianaift:l2vlan</type> <type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface> <if-ext:parent-interface>eth0</if-ext:parent-interface>
<if-cmn:encapsulation> <if-ext:encapsulation>
<dot1q-vlan <dot1q-vlan
xmlns="urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan"> xmlns=
"urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation">
<outer-tag> <outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type> <tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>11</vlan-id> <vlan-id>11</vlan-id>
</outer-tag> </outer-tag>
</dot1q-vlan> </dot1q-vlan>
</if-cmn:encapsulation> </if-ext:encapsulation>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip"> <ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<forwarding>true</forwarding> <forwarding>true</forwarding>
<address> <address>
<ip>2001:db8::11</ip> <ip>2001:db8:11::1</ip>
<prefix-length>32</prefix-length> <prefix-length>48</prefix-length>
</address> </address>
</ipv6> </ipv6>
</interface> </interface>
</interfaces> </interfaces>
</config> </config>
7.2. Layer 2 sub-interfaces with L2VPN 7.2. Layer 2 sub-interfaces with L2VPN
This example illustrates a layer 2 sub-interface 'eth0.3' configured This example illustrates a layer 2 sub-interface 'eth0.3' configured
to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and to match traffic with a S-VLAN tag of 10, and C-VLAN tag of 21; and
both tags removed before the traffic is passed off to the L2VPN remov the outer tag (S-VLAN 10) before the traffic is passed off to
service. the L2VPN service.
It also illustrates another sub-interface 'eth1.0' under a separate It also illustrates another sub-interface 'eth1.0' under a separate
physical interface configured to match traffic with a C-VLAN of 50, physical interface configured to match traffic with a C-VLAN of 50,
and the tag removed before traffic is given to any service. Sub- with the tag removed before traffic is given to any service. Sub-
interface 'eth1.0' is not currently bound to any service and hence interface 'eth1.0' is not currently bound to any service and hence
traffic classifed to that sub-interface is dropped. traffic classifed to that sub-interface is dropped.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces <interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types" xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common"> xmlns:if-ext="urn:ietf:params:xml:ns:yang:ietf-if-extensions">
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
</interface> </interface>
<interface> <interface>
<name>eth0.3</name> <name>eth0.3</name>
<type>ianaift:l2vlan</type> <type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface> <if-ext:parent-interface>eth0</if-ext:parent-interface>
<if-cmn:encapsulation> <if-ext:encapsulation>
<flexible <flexible xmlns=
xmlns="urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"> "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation">
<match> <match>
<dot1q-vlan-tagged> <dot1q-vlan-tagged>
<outer-tag> <outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type> <tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>10</vlan-id> <vlan-id>10</vlan-id>
</outer-tag> </outer-tag>
<second-tag> <second-tag>
<tag-type>dot1q-types:c-vlan</tag-type> <tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>21</vlan-id> <vlan-id>21</vlan-id>
</second-tag> </second-tag>
</dot1q-vlan-tagged> </dot1q-vlan-tagged>
</match> </match>
<rewrite> <rewrite>
<symmetrical> <symmetrical>
<dot1q-tag-rewrite> <dot1q-tag-rewrite>
<pop-tags>2</pop-tags> <pop-tags>1</pop-tags>
</dot1q-tag-rewrite> </dot1q-tag-rewrite>
</symmetrical> </symmetrical>
</rewrite> </rewrite>
</flexible> </flexible>
</if-cmn:encapsulation> </if-ext:encapsulation>
</interface> </interface>
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<type>ianaift:ethernetCsmacd</type> <type>ianaift:ethernetCsmacd</type>
</interface> </interface>
<interface> <interface>
<name>eth1.0</name> <name>eth1.0</name>
<type>ianaift:l2vlan</type> <type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface> <if-ext:parent-interface>eth0</if-ext:parent-interface>
<if-cmn:encapsulation> <if-ext:encapsulation>
<flexible <flexible xmlns=
xmlns="urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation"> "urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation">
<match> <match>
<dot1q-vlan-tagged> <dot1q-vlan-tagged>
<outer-tag> <outer-tag>
<tag-type>dot1q-types:c-vlan</tag-type> <tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>50</vlan-id> <vlan-id>50</vlan-id>
</outer-tag> </outer-tag>
</dot1q-vlan-tagged> </dot1q-vlan-tagged>
</match> </match>
<rewrite> <rewrite>
<symmetrical> <symmetrical>
<dot1q-tag-rewrite> <dot1q-tag-rewrite>
<pop-tags>1</pop-tags> <pop-tags>1</pop-tags>
</dot1q-tag-rewrite> </dot1q-tag-rewrite>
</symmetrical> </symmetrical>
</rewrite> </rewrite>
</flexible> </flexible>
</if-cmn:encapsulation> </if-ext:encapsulation>
</interface> </interface>
</interfaces> </interfaces>
<network-instances <network-instances
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance"> xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance">
<network-instance <network-instance
xmlns:l2vpn="urn:ietf:params:xml:ns:yang:ietf-l2vpn"> xmlns:l2vpn="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
<name>p2p-l2-1</name> <name>p2p-l2-1</name>
<description>Point to point L2 service</description> <description>Point to point L2 service</description>
<l2vpn:type>l2vpn:vpws-instance-type</l2vpn:type> <l2vpn:type>l2vpn:vpws-instance-type</l2vpn:type>
<l2vpn:signaling-type> <l2vpn:signaling-type>
skipping to change at page 23, line 36 skipping to change at page 26, line 14
<configured-pw> <configured-pw>
<peer-ip>2001:db8::50></peer-ip> <peer-ip>2001:db8::50></peer-ip>
<pw-id>100</pw-id> <pw-id>100</pw-id>
</configured-pw> </configured-pw>
</pseudowire> </pseudowire>
</pseudowires> </pseudowires>
</config> </config>
8. Acknowledgements 8. Acknowledgements
The authors would particularly like to thank John Messenger, Glenn The authors would particularly like to thank Benoit Claise, John
Parsons, and Dan Romascanu for their help progressing this draft. Messenger, Glenn 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 Martin Bjorklund, Alex Campbell,
Heron, Marc Holness, Iftekhar Hussain, Neil Ketley, William Lupton, Don Fedyk, Eric Gray, Giles Heron, Marc Holness, Iftekhar Hussain,
John Messenger, Glenn Parsons, Ludwig Pauwels, Joseph White, Vladimir Neil Ketley, William Lupton, John Messenger, Glenn Parsons, Ludwig
Vassilev, and members of the IEEE 802.1 WG for their helpful reviews Pauwels, Joseph White, Vladimir Vassilev, and members of the IEEE
and feedback on this draft. 802.1 WG for their helpful reviews and feedback on this draft.
9. ChangeLog 9. ChangeLog
XXX, RFC Editor, please delete this change log before publication. XXX, RFC Editor, please delete this change log before publication.
9.1. WG version -05 9.1. WG version -07 and -06
o Apply markups from WG last call.
9.2. WG version -05
o Incorporate feedback from IEEE 802.1 WG, John Messenger in o Incorporate feedback from IEEE 802.1 WG, John Messenger in
particular. particular.
o Adding must contraints to ensure outer tags are always matched to o Adding must contraints to ensure outer tags are always matched to
C-VLAN and S-VLAN tags. C-VLAN and S-VLAN tags.
o Fixed bug where second tag could be matched without outer tag, and o Fixed bug where second tag could be matched without outer tag, and
where tags must not be specified. where tags must not be specified.
9.2. WG version -04 9.3. WG version -04
o Added examples o Added examples
9.3. WG version -03 9.4. 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.4. WG version -02 9.5. 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.5. WG version -01 9.6. 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.6. Version -04 9.7. 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.7. Version -03 9.8. 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 two new YANG module and the authors politely 10.1. YANG Module Registrations
request that IANA assigns unique names to the YANG module files
contained within this draft, and also appropriate URIs in the "IETF The following YANG modules are requested to be registred in the IANA
XML Registry". "YANG Module Names" [RFC6020] registry:
The ietf-if-vlan-encapsulation module:
Name: ietf-if-vlan-encapsulation
XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-vlan-
encapsulation
Prefix: if-vlan
Reference: [RFCXXXX]
The ietf-if-flexible-encapsulation module:
Name: ietf-if-flexible-encapsulation
XML Namespace: urn:ietf:params:xml:ns:yang:ietf-if-flexible-
encapsulation
Prefix: if-flex
Reference: [RFCXXXX]
This document registers two URIs in the "IETF XML Registry"
[RFC3688]. Following the format in RFC 3688, the following
registrations have been made.
URI: urn:ietf:params:xml:ns:yang:ietf-if-vlan-encapsulation
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-if-flexible-encapsulation
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
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.
There are a number of data nodes defined in this YANG module which There are a number of data nodes defined in this YANG module which
are writable/creatable/deletable (i.e. config true, which is the are writable/creatable/deletable (i.e. config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g. edit-config) to in some network environments. Write operations (e.g. edit-config) to
these data nodes without proper protection can have a negative effect these data nodes without proper protection can have a negative effect
on network operations. These are the subtrees and data nodes and on network operations. These are the subtrees and data nodes and
their sensitivity/vulnerability: their sensitivity/vulnerability:
11.1. if-l3-vlan.yang 11.1. ietf-if-vlan-encapsulation.yang
The nodes in the if-l3-vlan YANG module are concerned with matching The nodes in the vlan encapsulation YANG module are concerned with
particular frames received on the network device to connect them to a matching particular frames received on the network device to connect
layer 3 forwarding instance, and as such adding/modifying/deleting them to a layer 3 forwarding instance, and as such adding/modifying/
these nodes has a high risk of causing traffic to be lost because it deleting these nodes has a high risk of causing traffic to be lost
is not being classified correctly, or is being classified to a because it is not being classified correctly, or is being classified
separate sub-interface. The nodes, all under the subtree to a separate sub-interface. The nodes, all under the subtree
/interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to /interfaces/interface/encapsulation/dot1q-vlan, that are sensitive to
this are: this are:
o outer-tag/tag-type o outer-tag/tag-type
o outer-tag/vlan-id o outer-tag/vlan-id
o second-tag/tag-type o second-tag/tag-type
o second-tag/vlan-id o second-tag/vlan-id
11.2. flexible-encapsulation.yang 11.2. ietf-if-flexible-encapsulation.yang
There are many nodes in the flexible-encapsulation YANG module that There are many nodes in the flexible encapsulation YANG module that
are concerned with matching particular frames received on the network are concerned with matching particular frames received on the network
device, and as such adding/modifying/deleting these nodes has a high 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 risk of causing traffic to be lost because it is not being classified
correctly, or is being classified to a separate sub-interface. The correctly, or is being classified to a separate sub-interface. The
nodes, all under the subtree nodes, all under the subtree
/interfaces/interface/encapsulation/flexible/match, that are /interfaces/interface/encapsulation/flexible/match, that are
sensitive to this are: sensitive to this are:
o default o default
skipping to change at page 26, line 28 skipping to change at page 30, line 4
o default o default
o untagged o untagged
o dot1q-priority-tagged o dot1q-priority-tagged
o dot1q-priority-tagged/tag-type o dot1q-priority-tagged/tag-type
o dot1q-vlan-tagged/outer-tag/vlan-type o dot1q-vlan-tagged/outer-tag/vlan-type
o dot1q-vlan-tagged/outer-tag/vlan-id o dot1q-vlan-tagged/outer-tag/vlan-id
o dot1q-vlan-tagged/second-tag/vlan-type o dot1q-vlan-tagged/second-tag/vlan-type
o dot1q-vlan-tagged/second-tag/vlan-id o dot1q-vlan-tagged/second-tag/vlan-id
There are also many modes in the flexible-encapsulation YANG module There are also many modes in the flexible encapsulation YANG module
that are concerned with rewriting the fields in the L2 header for that are concerned with rewriting the fields in the L2 header for
particular frames received on the network device, and as such particular frames received on the network device, and as such
adding/modifying/deleting these nodes has a high risk of causing adding/modifying/deleting these nodes has a high risk of causing
traffic to be dropped or incorrectly processed on peer network traffic to be dropped or incorrectly processed on peer network
devices, or it could cause layer 2 tunnels to go down due to a devices, or it could cause layer 2 tunnels to go down due to a
mismatch in negotiated MTU. The nodes, all under the subtree mismatch in negotiated MTU. The nodes, all under the subtree
/interfaces/interface/encapsulation/flexible/rewrite, that are /interfaces/interface/encapsulation/flexible/rewrite, that are
sensitive to this are: sensitive to this are:
o symmetrical/dot1q-tag-rewrite/pop-tags o symmetrical/dot1q-tag-rewrite/pop-tags
skipping to change at page 28, line 6 skipping to change at page 31, line 27
o second-tag/vlan-type o second-tag/vlan-type
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., tapsingh@cisco.com, t., and S.
Sivaraj, "Common Interface Extension YANG Data Models", Sivaraj, "Common Interface Extension YANG Data Models",
draft-ietf-netmod-intf-ext-yang-07 (work in progress), draft-ietf-netmod-intf-ext-yang-08 (work in progress),
March 2019. November 2019.
[IEEE802.1Qcp-2018]
Holness, M., "IEEE Std 802.1Qcp-2018: IEEE Standard for
Local and metropolitan area networks -- Bridges and
Bridged Networks -- Amendment 30: YANG Data Model", 2018.
[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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[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>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[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 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged 12.2. Informative References
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-10 (work in progress), L2VPN", draft-ietf-bess-l2vpn-yang-10 (work in progress),
July 2019. July 2019.
[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>.
 End of changes. 176 change blocks. 
387 lines changed or deleted 560 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/