draft-ietf-netmod-sub-intf-vlan-model-03.txt   draft-ietf-netmod-sub-intf-vlan-model-04.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: Informational T. Singh
Expires: May 3, 2018 Cisco Systems Expires: January 3, 2019 Cisco Systems
S. Sivaraj S. Sivaraj
Juniper Networks Juniper Networks
October 30, 2017 July 2, 2018
Sub-interface VLAN YANG Data Models Sub-interface VLAN YANG Data Models
draft-ietf-netmod-sub-intf-vlan-model-03 draft-ietf-netmod-sub-intf-vlan-model-04
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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 3, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4
3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5 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. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Layer 3 sub-interfaces with IPv6 . . . . . . . . . . . . 19
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Layer 2 sub-interfaces with L2VPN . . . . . . . . . . . . 21
9.1. WG version -03 . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9.2. WG version -02 . . . . . . . . . . . . . . . . . . . . . 20 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.3. WG version -01 . . . . . . . . . . . . . . . . . . . . . 20 9.1. WG version -04 . . . . . . . . . . . . . . . . . . . . . 23
9.4. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. WG version -03 . . . . . . . . . . . . . . . . . . . . . 24
9.5. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 20 9.3. WG version -02 . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9.4. WG version -01 . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 21 9.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 24
11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 24 11.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 25
Appendix A. Comparison with the IEEE 802.1Q Configuration Model 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1. Sub-interface based configuration model overview . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 28
A.3. Possible Overlap Between the Two Models . . . . . . . . . 26 Appendix A. Comparison with the IEEE 802.1Q Configuration Model 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. Sub-interface based configuration model overview . . . . 29
A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 30
A.3. Possible Overlap Between the Two Models . . . . . . . . . 30
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 [RFC7223]. 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, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448]
and VPLS [RFC4761] [RFC4762] to be configurable via YANG when and VPLS [RFC4761] [RFC4762] to be configurable via YANG when
interoperating with VLAN tagged traffic received from an IEEE 802.1Q interoperating with VLAN tagged traffic received from an IEEE 802.1Q
compliant bridge. compliant bridge.
skipping to change at page 3, line 40 skipping to change at page 3, line 42
if-l3-vlan.yang - Defines the model for basic classification of if-l3-vlan.yang - Defines the model for basic classification of
VLAN tagged traffic to L3 transport services VLAN tagged traffic to L3 transport services
flexible-encapsulation.yang - Defines the model for flexible flexible-encapsulation.yang - Defines the model for flexible
classification of Ethernet/VLAN traffic to L2 transport services classification of Ethernet/VLAN traffic to L2 transport 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
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
skipping to change at page 10, line 47 skipping to change at page 10, line 48
} }
} }
<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
[RFC7223]. [RFC8343].
<CODE BEGINS> file "ietf-flexible-encapsulation@2017-10-30.yang" <CODE BEGINS> file "ietf-flexible-encapsulation@2017-10-30.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 {
skipping to change at page 19, line 23 skipping to change at page 19, line 25
uses dot1q-types:dot1q-tag-classifier-grouping; uses dot1q-types:dot1q-tag-classifier-grouping;
} }
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7. Open Issues 7. Examples
Open issues: The following sections give examples of configuring a sub-interface
supporting L3 forwarding, and also a sub-interface being used in
conjunction with the IETF L2VPN YANG model
[I-D.ietf-bess-l2vpn-yang].
1. Consider whether to use interface property identities (as per 7.1. Layer 3 sub-interfaces with IPv6
draft-wilton-netmod-interface-properties).
2. Provide configuration examples? This example illustrates a layer 3 sub-interface configured to match
traffic with a S-VLAN tag of 10, and C-VLAN tag of 20.
3. Remove extra 'dot1q-tag' container (required update to IEEE YANG <?xml version="1.0" encoding="utf-8"?>
file. <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<interface>
<name>eth0.1</name>
<type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface>
<if-cmn:encapsulation>
<dot1q-vlan
xmlns="urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan">
<outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>10</vlan-id>
</outer-tag>
<second-tag>
<tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>20</vlan-id>
</second-tag>
</dot1q-vlan>
</if-cmn:encapsulation>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<forwarding>true</forwarding>
<address>
<ip>2001:db8::10</ip>
<prefix-length>32</prefix-length>
</address>
</ipv6>
</interface>
<interface>
<name>eth0.2</name>
<type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface>
<if-cmn:encapsulation>
<dot1q-vlan
xmlns="urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan">
<outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>11</vlan-id>
</outer-tag>
</dot1q-vlan>
</if-cmn:encapsulation>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
<forwarding>true</forwarding>
<address>
<ip>2001:db8::11</ip>
<prefix-length>32</prefix-length>
</address>
</ipv6>
</interface>
</interfaces>
</config>
7.2. Layer 2 sub-interfaces with L2VPN
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
both tags removed before the traffic is passed off to the L2VPN
service.
It also illustrates another sub-interface 'eth1.0' under a separate
physical interface configured to match traffic with a C-VLAN of 50,
and the tag removed before traffic is given to any service. Sub-
interface 'eth1.0' is not currently bound to any service and hence
traffic classifed to that sub-interface is dropped.
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interfaces
xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"
xmlns:dot1q-types="urn:ieee:std:802.1Q:yang:ieee802-dot1q-types"
xmlns:if-cmn="urn:ietf:params:xml:ns:yang:ietf-interfaces-common">
<interface>
<name>eth0</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<interface>
<name>eth0.3</name>
<type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface>
<if-cmn:encapsulation>
<flexible
xmlns="urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation">
<match>
<dot1q-vlan-tagged>
<outer-tag>
<tag-type>dot1q-types:s-vlan</tag-type>
<vlan-id>10</vlan-id>
</outer-tag>
<second-tag>
<tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>21</vlan-id>
</second-tag>
</dot1q-vlan-tagged>
</match>
<rewrite>
<symmetrical>
<dot1q-tag-rewrite>
<pop-tags>2</pop-tags>
</dot1q-tag-rewrite>
</symmetrical>
</rewrite>
</flexible>
</if-cmn:encapsulation>
</interface>
<interface>
<name>eth1</name>
<type>ianaift:ethernetCsmacd</type>
</interface>
<interface>
<name>eth1.0</name>
<type>ianaift:l2vlan</type>
<if-cmn:parent-interface>eth0</if-cmn:parent-interface>
<if-cmn:encapsulation>
<flexible
xmlns="urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation">
<match>
<dot1q-vlan-tagged>
<outer-tag>
<tag-type>dot1q-types:c-vlan</tag-type>
<vlan-id>50</vlan-id>
</outer-tag>
</dot1q-vlan-tagged>
</match>
<rewrite>
<symmetrical>
<dot1q-tag-rewrite>
<pop-tags>1</pop-tags>
</dot1q-tag-rewrite>
</symmetrical>
</rewrite>
</flexible>
</if-cmn:encapsulation>
</interface>
</interfaces>
<network-instances
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance">
<network-instance
xmlns:l2vpn="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
<name>p2p-l2-1</name>
<description>Point to point L2 service</description>
<l2vpn:type>l2vpn:vpws-instance-type</l2vpn:type>
<l2vpn:signaling-type>
l2vpn:ldp-signaling
</l2vpn:signaling-type>
<endpoint xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
<name>local</name>
<ac>
<name>eth0.3</name>
</ac>
</endpoint>
<endpoint xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn">
<name>remote</name>
<pw>
<name>pw1</name>
</pw>
</endpoint>
<vsi-root>
</vsi-root>
</network-instance>
</network-instances>
<pseudowires
xmlns="urn:ietf:params:xml:ns:yang:ietf-pseudowires">
<pseudowire>
<name>pw1</name>
<configured-pw>
<peer-ip>2001:db8::50></peer-ip>
<pw-id>100</pw-id>
</configured-pw>
</pseudowire>
</pseudowires>
</config>
8. Acknowledgements 8. Acknowledgements
The authors would particularly like to thank John Messenger, Glenn The authors would particularly like to thank John Messenger, Glenn
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 -03
9.1. WG version -04
o Added examples
9.2. 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.2. WG version -02 9.3. 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.3. WG version -01 9.4. 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.4. Version -04 9.5. 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.5. Version -03 9.6. 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.
skipping to change at page 23, line 46 skipping to change at page 27, line 46
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-05 (work in progress),
July 2017. July 2017.
[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>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
12.2. Informative References 12.2. Informative References
[dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks - [dot1Qcp] Holness, M., "802.1Qcp Bridges and Bridged Networks -
Amendment: YANG Data Model", 2016. Amendment: YANG Data Model", 2018.
[I-D.ietf-bess-l2vpn-yang]
Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B.,
and K. Tiruveedhula, "YANG Data Model for MPLS-based
L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress),
February 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>.
 End of changes. 22 change blocks. 
46 lines changed or deleted 248 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/