ISO/IEC/IEEE 8802-1Q:2020/Amd 2:2021
(Amendment)Telecommunications and exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1Q: Bridges and bridged networks — Amendment 2: YANG data model
Telecommunications and exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1Q: Bridges and bridged networks — Amendment 2: YANG data model
Télécommunications et échange entre systèmes informatiques — Exigences pour les réseaux locaux et métropolitains — Partie 1Q: Ponts et réseaux pontés — Amendement 2
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC/
STANDARD IEEE
8802-1Q
Second edition
2020-08
AMENDMENT 2
2021-09
Telecommunications and exchange
between information technology
systems — Requirements for local and
metropolitan area networks —
Part 1Q:
Bridges and bridged networks
AMENDMENT 2: YANG data model
Télécommunications et échange entre systèmes informatiques —
Exigences pour les réseaux locaux et métropolitains —
Partie 1Q: Ponts et réseaux pontés
AMENDEMENT 2
Reference number
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
©
IEEE 2018
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
© IEEE 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
ii © IEEE 2018 – All rights reserved
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO/IEC documents should be noted.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its
standards through a consensus development process, approved by the American National Standards
Institute, which brings together volunteers representing varied viewpoints and interests to achieve the
final product. Volunteers are not necessarily members of the Institute and serve without compensation.
While the IEEE administers the process and establishes rules to promote fairness in the consensus
development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the
information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
ISO/IEC/IEEE 8802-1Q:2020/Amd 2 was prepared by the LAN/MAN of the IEEE Computer Society (as
IEEE Std 802.1Qcp-2018) and drafted in accordance with its editorial rules. It was adopted, under the
“fast-track procedure” defined in the Partner Standards Development Organization cooperation
agreement between ISO and IEEE, by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 6, Telecommunications and information exchange between systems.
A list of all parts in the ISO/IEC/IEEE 8802 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committees.
© IEEE 2018 – All rights reserved iii
IEEE Std 802.1Qcp™-2018
(Amendment to
IEEE Std 802.1Q™-2018)
IEEE Standard for
Local and metropolitan area networks—
Bridges and Bridged Networks—
Amendment 30: YANG Data Model
Sponsor
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 14 June 2018
IEEE-SA Standards Board
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Abstract: A YANG data model in support of configuration and operational status information for a
subset of Bridging capabilities is provided in this amendment to IEEE Std 802.1Q™-2018. ®
Keywords: Bridged Local Area Networks, IEEE 802 , IEEE 802.1Q™, IEEE 802.1Qcp™, local
area networks (LANs), MAC Bridges, metropolitan area networks, Virtual Bridged Local Area
Networks (virtual LANs), YANG
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 14 September 2018. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of
Electrical and Electronics Engineers, Incorporated.
PDF: ISBN 978-1-5044-4927-4 STD23138
Print: ISBN 978-1-5044-4928-1 STDPD23138
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices
and disclaimers, or a reference to this page, appear in all standards and may be found under the heading
“Important Notices and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on
request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards
Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a
consensus development process, approved by the American National Standards Institute (“ANSI”), which
brings together volunteers representing varied viewpoints and interests to achieve the final product. IEEE
Standards are documents developed through scientific, academic, and industry-based technical working
groups. Volunteers in IEEE working groups are not necessarily members of the Institute and participate
without compensation from IEEE. While IEEE administers the process and establishes rules to promote
fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the
accuracy of any of the information or the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure
against interference with or from other devices or networks. Implementers and users of IEEE Standards
documents are responsible for determining and complying with all appropriate safety, security,
environmental, health, and interference protection practices and all applicable laws and regulations.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of
material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort.
IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments
received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his
or her own independent judgment in the exercise of reasonable care in any given circumstances or, as
appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE
standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO:
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON
ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Translations
The IEEE consensus development process involves the review of documents in English only. In the event
that an IEEE standard is translated, only the English version published by IEEE should be considered the
approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board
Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its
committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures,
symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall
make it clear that his or her views should be considered the personal views of that individual rather than the
formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and
Standards Coordinating Committees are not able to provide an instant response to comments or questions
except in those cases where the matter has previously been addressed. For the same reason, IEEE does not
respond to interpretation requests. Any person who would like to participate in revisions to an IEEE
standard is welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the
provisions of any IEEE Standards document does not imply compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not
in compliance with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization,
and the promotion of engineering practices and methods. By making these documents available for use and
adoption by public authorities and private users, IEEE does not waive any rights in copyright to the
documents.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual, non-
commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to
photocopy portions of any individual standard for educational classroom use can also be obtained through
the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. A current IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years
old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that
they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://
ieeexplore.ieee.org/ or contact IEEE at the address listed previously. For more information about the IEEE-
SA or IEEE’s standards development process, visit the IEEE-SA Website at http://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http://
standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-
SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate
whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or
under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting
inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or
conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their
.
own responsibility. Further information may be obtained from the IEEE Standards Association
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Participants
At the time of approval of this standard, the IEEE 802.1 Working Group had the following membership:
Glenn Parsons, Chair
John Messenger, Vice Chair
János Farkas, Chair, Time-Sensitive Networking Task Group
Marc Holness, Editor
Ralf Assmann Marina Gutierrez Maximilian Riegel
Shenghua Bao Stephen Haddock Jessy V. Rouyer
Jens Bierschenk Mark Hantel Atsushi Sato
Steinar Bjornstad Lokesh Kabra Frank Schewe
Christian Boiger Michael Karl Michael Seaman
Paul Bottorff Stephan Kehrer Johannes Specht
Radhakrishna Canchi Hajime Koto Patricia Thaler
David Chen Christophe Mangin Paul Unbehagen
Feng Chen Scott Mansfield Xinyuan Wang
Weiying Cheng James McIntosh Tongtong Wang
Paul Congdon Tero Mustala Hao Wang
Rodney Cummings Tomoki Ohsawa Karl Weber
Hesham Elbakoury Donald R. Pannell Brian Weis
Norman Finn Walter Pienciak Jordon Woods
Geoffrey Garner Michael Potts Takahiro Yamaura
Eric W. Gray Wei Qiu Xiang Yu
Craig Gunther Karen Randall Nader Zein
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Randall Groves
Thomas Alexander Charles Moorwood
Stephen Haddock Nick S. A. Nikjoo
Richard Alfvin
Paul Nikolich
Butch Anton Mark Hantel
Satoshi Obara
Stefan Aust Marco Hernandez
Bansi Patel
Gordon Bechtel Werner Hoelzl
Alon Regev
David Black Noriyuki Ikeuchi
Maximilian Riegel
Christian Boiger Atsushi Ito
Robert Robinson
Nancy Bravin Raj Jain
Benjamin Rolfe
Dietmar Bruckner SangKwon Jeong
Jessy V. Rouyer
Demetrio Bucaneg, Jr. Peter Jones
Michael Seaman
Stephen Bush Piotr Karocki
Daniel Smith
William Byrd Stephan Kehrer
Thomas Starai
Juan Carreon Stuart Kerry
Walter Struppler
Keith Chow Yongbum Kim
Mark-Rene Uchida
Charles Cook Hyeong Ho Lee
Dmitri Varsanofiev
Rodney Cummings James Lepp
George Vlantis
Sourav Dutta Jon Lewis
Khurram Waheed
János Farkas Michael Lynch
Andreas Wolf
Norman Finn Elvis Maculuba
Chun Yu Charles Wong
Avraham Freedman Arthur Marris
Oren Yuen
Eric W. Gray Richard Mellitz
Zhen Zhou
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
When the IEEE-SA Standards Board approved this standard on 14 June 2018, it had the following
membership:
Jean-Philippe Faure, Chair
Gary Hoffman, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Chuck Adams Thomas Koshy Robby Robson
Masayuki Ariyoshi Joseph L. Koepfinger* Dorothy Stanley
Ted Burse Kevin Lu Adrian Stephens
Stephen Dukes Daleep Mohla Mehmet Ulema
Phil Wennblom
Damir Novosel
Doug Edwards
Howard Wolfman
Ronald C. Petersen
J. Travis Griffith
Yu Yuan
Annette D. Reilly
Michael Janezic
*Member Emeritus
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Introduction
This introduction is not part of IEEE Std 802.1Qcp-2018, IEEE Standard for Local and metropolitan area networks—
Bridges and Bridged Networks—Amendment 30: YANG Data Model.
This amendment to IEEE Std 802.1Q-2018 specifies a YANG data model that provides configuration and
operational status reporting for IEEE 802.1Q Two-Port MAC Relay, Customer VLAN Bridges, and Provider
Bridges.
This standard contains state-of-the-art material. The area covered by this standard is undergoing evolution.
Revisions are anticipated within the next few years to clarify existing material, to correct possible errors, and ®
to incorporate new related material. Information on the current revision state of this and other IEEE 802
standards may be obtained from
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
Contents
1. Overview . 12
1.3 Introduction. 12
2. Normative references. 13
4. Abbreviations . 14
5. Conformance . 15
5.4 VLAN Bridge component requirements. 15
5.13 MAC Bridge component requirements. 15
5.16 TPMR conformance. 15
8. Principles of Bridge operation . 16
8.12 Bridge Management Entity. 16
8.13 Addressing . 16
12. Bridge management . 17
12.10 Bridge VLAN managed objects. 17
48. YANG Data Model . 18
48.1 YANG Framework. 18
48.2 Security considerations . 19
48.3 IEEE 802.1Q YANG model . 21
48.4 Structure of the YANG model . 31
48.5 Relationship to IEEE 802.1Q managed objects. 33
48.6 Definition of IEEE 802.1Q YANG modules . 39
Annex A (normative) PICS proforma—Bridge implementations . 90
A.5 Major capabilities. 90
A.48 YANG. 90
Annex U (informative) Bibliography . 91
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
List of figures
Figure 48-1—General YANG hierarchy . 18
Figure 48-2—YANG root hierarchy with IEEE 802.1Q YANG modules. 19
Figure 48-3—UML YANG interface management model. 22
Figure 48-4—Generic IEEE 802.1Q bridge mode . 23
Figure 48-5—Bridge port model . 24
Figure 48-6—TPMR model. 25
Figure 48-7—TPMR port model . 26
Figure 48-8—Provider Bridge model . 28
Figure 48-9—Provider Edge Bridge C-VLAN Interface mode. 29
Figure 48-10—Provider Edge Bridge S-VLAN interface model . 30
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
List of tables
Table 48-1—Structure of the YANG modules . 31
Table 48-2—Structure of the ieee802-dot1q-bridge module. 31
Table 48-3—Structure of the ieee802-dot1q-tpmr module . 32
Table 48-4—Structure of the ieee802-dot1q-vlan-bridge module. 32
Table 48-5—Structure of the ieee802-dot1q-pb module. 32
Table 48-6—Bridge cross-reference table. 33
Table 48-7—Bridge component cross-reference table . 34
Table 48-8—Bridge component filtering database cross-reference table. 35
Table 48-9—Bridge component permanent database cross-reference table. 36
Table 48-10—Bridge component Bridge VLAN cross-reference table . 36
Table 48-11—Bridge component Bridge MST cross-reference table . 37
Table 48-12—Bridge port cross-reference table. 38
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
IEEE Standard for
Local and metropolitan area networks—
Bridges and Bridged Networks—
Amendment 30: YANG Data Model
(This amendment is based on IEEE Std 802.1Q™-2018)
NOTE—The editing instructions contained in this amendment define how to merge the material contained here into the
base document and its other amendments to form the new comprehensive standard.
Editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace.
Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change
and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new
material). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions
may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make
changes in figures or equations by removing the existing figure or equation and replacing it with a new one. Editing
instructions, change markings, and this NOTE will not be carried over into future editions because the changes will be
incorporated into the base standard.
1. Overview
1.3 Introduction
Insert the following item after j) Defines SMIv2 (IETF STD 58) Management Information Based (MIB)
modules for the management of VLAN Bridge capabilities including spanning tree protocols and
Provider Bridges, renumbering as necessary:
k) Define YANG configuration and operational state models (Clause 48) in support of Two-Port MAC
Relays, Customer VLAN Bridges, and Provider Bridges.
Notes in text, tables, and figures are given for information only, and do not contain requirements needed to implement the standard.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
2. Normative references
Insert the following references in alphanumeric order:
IEEE Std 802d™-2017, IEEE Standard for Local and Metropolitan Area Networks: Overview and ®
Architecture—Amendment 1: Allocation of Uniform Resource Name (URN) Values in IEEE 802
Standards.
IETF RFC 8343 (proposed standard), A YANG Data Model for Interface Management, March 2018.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
4. Abbreviations
Insert the following abbreviations in alphanumeric order in Clause 4:
NETCONF Network Configuration Protocol
YANG Yet Another Next Generation
YANG is best viewed as a name, not an acronym.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
5. Conformance
5.4 VLAN Bridge component requirements
5.4.1 VLAN Bridge component options
Insert the following item w) after v) Support SMIv2 MIB modules for the management of VLAN Bridge
capabilities (Clause 17), renumbering as necessary:
w) Support YANG modules for the management of VLAN Bridge capabilities (Clause 48);
5.13 MAC Bridge component requirements
5.13.1 MAC Bridge component options
Insert the following item h) after g) Support SMIv2 MIB modules for the management of MAC Bridge
capabilities (Clause 17), renumbering as necessary:
h) Support YANG modules for the management of MAC Bridge capabilities (Clause 48);
5.16 TPMR conformance
5.16.1 TPMR options
Insert the following item d) after c) Support remote management using the TPMR MIB module defined in
17.7.11, renumbering as necessary:
d) Support remote management using the TPMR YANG module defined in 48.4.2.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
8. Principles of Bridge operation
Change the text of 8.12 as follows:
8.12 Bridge Management Entity
In order to facilitate interoperable management of Bridges by remote means (as opposed to management via
some kind of management console attached directly to the Bridge), it is recommended that SNMP should be
the protocol that is used, in conjunction ith the SMIv2 MIB modules specified in Clause 17.
Remote management capabilities (as opposed to management via a console or other device attached directly
to a Bridge) are modeled as performed by a Bridge Management Entity supported by a protocol stack as
described in 8.13.7. To facilitate interoperable remote management, the Bridge Management Entity should
use either the SMIv2 MIB modules specified in Clause 17 with SNMP or the YANG modules specified in
Clause 48 with a network configuration protocol, e.g., NETCONF, RESTCONF.
8.13 Addressing
Change the text of 8.13.7 as follows:
8.13.7 Bridge Management Entities
The recommended protocol for remote Bridge management is SNMP, which typically uses IP as a network
layer protocol; however, Network configuration and management protocols typically use IP as a network
layer protocol. SNMP can also be supported directly over an IEEE 802 LAN, as specified in IETF RFC
4789. If implemented, the The management protocol stack and address used shall be supported by a single
LLC Entity attached to a Bridge Port. The Port should be a Management Port for the Bridge, as described in
8.3 and Figure 8-8, but may be a Port attached to a LAN, as described in 8.13.9, Figure 8-21, and
Figure 8-22.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
12. Bridge management
12.10 Bridge VLAN managed objects
Change the first paragraph of 12.10.1 as follows:
12.10.1 Bridge VLAN Configuration managed object
The Bridge VLAN Configuration managed object models operations that modify, or inquire about, the
overall configuration of the Bridge’s VLAN resources. There is a single Bridge VLAN Configuration
managed object per Bridge Component.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
Insert a new Clause 48 after Clause 47 as follows:
48. YANG Data Model
This clause specifies YANG data models that provide control and status monitoring of IEEE 802.1Q
Bridges. Specifically,
a) Two-Port MAC Relays,
b) Customer VLAN bridges, and
c) Provider bridges.
The YANG bridge data management models are derived from UML models specified in 48.3. The UML
models are based on Clause 12.
NOTE 1—OMG UML 2.5 [B78] conventions together with C++ language constructs are used in this clause as a
representation to convey model structure and relationships.
NOTE 2—The MIB modules specified in Clause 17 were also derived from Clause 12. Consequently, the capabilities
and structure of the YANG data models should closely aligned with that represented by the MIBs. However the YANG
data model has not been derived from the MIB, and there has been no attempt to include data or modeling constructs that
might appear in the MIB but not in the information model.
48.1 YANG Framework
This clause has been developed according to the YANG guidelines published in IETF RFC 6087 [B68] as
applicable to IEEE standards.
The YANG framework applies hierarchy in the following areas:
1) The uniform resource name (URN), as specified in IEEE Std 802d. The structure of the URN is
such that ieee is the root (i.e., name-space identifier), followed by the standard, then the
working group developing the standard.
2) The YANG objects form a hierarchy of configuration and operational data structures that define
the YANG model. These hierarchical relationships are described in 48.3.
The general YANG framework hierarchy is illustrated in Figure 48-1.
IETF System IETF Interface
IETF Routing .
Management Management
... IP IS-IS ...
OSPF
...
...
Figure 48-1—General YANG hierarchy
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
Network interfaces are central to the management of protocols supported over said interface. Thus, it is
important to establish a common data model for how interfaces are identified, configured, and monitored.
The IETF Interface Management model (IETF RFC 8343) defines a generic YANG data model for the
management of network interfaces. Consequently, IEEE 802.1Q Bridge Ports augment the generic interfaces
data model defined by the IETF Interface Management model (IETF RFC 8343).
In addition, a high level YANG object is defined to support IEEE 802.1Q Bridge YANG models. An
“IEEE 802.1Q Bridge” YANG model is introduced, which can be augmented by the various IEEE 802.1Q
Bridge models.
The YANG hierarchical structure that incorporates the IEEE 802.1Q YANG models supported by this
standard is represented in Figure 48-2.
IETF System IETF Interface
IETF Routing 802.1Q Bridge .
Management Management
PAE
IS-IS
PAE
TPMR
System
IP OSPF
Customer
...
VLAN Bridge
Bridge
...
Port
Provider
Bridge
...
Figure 48-2—YANG root hierarchy with IEEE 802.1Q YANG modules
48.2 Security considerations
The YANG modules defined in this clause are designed to be accessed via a network configuration protocol,
e.g., NETCONF protocol (IETF RFC 6536 [B71]). In the case of NETCONF, the lowest NETCONF layer is
the secure transport layer and the mandatory to implement secure transport is SSH (IETF RFC 6242 [B70]).
The NETCONF access control model provides the means to restrict access for particular NETCONF users to
a preconfigured subset of all available NETCONF protocol operations and content.
It is the responsibility of a system’s implementor and administrator to ensure that the protocol entities in the
system that support NETCONF, and any other remote configuration protocols that make use of these YANG
modules, are properly configured to allow access only to those principals (users) that have legitimate rights
to read or write data nodes. This standard does not specify how the credentials of those users are to be stored
or validated.
48.2.1 Security considerations of the ieee802-dot1q-bridge and ieee802-dot1q-vlan-bridge
YANG modules
There are a number of management objects defined in the ieee802-dot1q-bridge and ieee802-dot1q-vlan-
bridge YANG modules that are configurable (i.e., read-write) and/or operational (i.e., read-only). Such
objects may be considered sensitive or vulnerable in some network environments. A network configuration
protocol, such as NETCONF (IETF RFC 6241 [B69]), can support protocol operations that can edit or delete
YANG module configuration data (e.g., edit-config, delete-config, copy-config). If this is done in a
non-secure environment without proper protection, then negative effects on the network operation is
possible.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
The following objects in the ieee802-dot1q-bridge and ieee802-dot1q-vlan-bridge YANG modules can be
manipulated to interfere with the operation of VLANs and priority classes. This could, for example, be used
to force a reinitialization of state machines, thus causing network instability, or to change the forwarding and
filtering policies. Another possibility would be for an attacker to override established policy on Port
priorities, thus giving a user (or an attacker) unauthorized preferential treatment.
interfaces/interface/bridge-port
interfaces/interface/bridge-port/priority-regeneration
bridges/bridge/component/traffic-class-enabled
bridges/bridge/component/bridge-vlan/protocol-group-database
interfaces/interface/bridge-port/traffic-class
interfaces/interface/bridge-port/protocol-group-vid-set
a) The configurable object bridges/bridge/component/filtering-database/aging-time controls how fast
dynamically learned forwarding information is aged out. Setting this object to a large value may
simplify FDB overflow attacks. Setting this object to too small a value may compromise the
throughput of the network by causing excessive flooding.
b) The configurable object bridges/bridge/component/filtering-database/filtering-entries/entry-type
provides a filtering mechanism controlling which Ports frames originating from a specific source
may be forwarded to. Write access to this table can be used to turn provisioned filtering off or to add
filters to prevent rightful use of the network.
Some of the readable data in this YANG module may be considered sensitive or vulnerable in some network
environments. It is thus important to control all types of access (e.g., including NETCONF get, get-config
operations) to these objects and possibly to even encrypt the values of these objects when sending them over
the network. These tables and objects and their sensitivity/vulnerability are described as follows:
— The object bridges/bridge/component/capabilities could be used by an attacker to determine which
attacks might be useful to attempt against a given device.
— The readable objects defined in the ieee802-dot1q-bridge and ieee802-dot1q-vlan-bridge modules
provide information about the topology of a bridged network and the attached active stations. The
addresses listed in the bridges/bridge/component/filtering-database/filtering-entries usually reveal
information about the manufacturer of the MAC hardware, which can be useful information for
mounting other specific attacks.
— The readable objects defined in the ieee802-dot1q-bridge and ieee802-dot1q-vlan-bridge modules
provide information about the topology of a bridged network and the attached active stations. In
some networks, information about attached active stations can be considered personal identifying
information about the user of the station. Unauthorized use of this object can be considered a privacy
threat.
48.2.2 Security considerations of the ieee802-dot1q-tpmr YANG module
There are a number of management objects defined in the ieee802-dot1q-tpmr YANG module that are
configurable (i.e., read-write) and/or operational (i.e., read-only). Such objects may be considered sensitive
or vulnerable in some network environments. A network configuration protocol, such as NETCONF (IETF
RFC 6241 [B69]), can support protocol operations that can edit or delete YANG module configuration data
(e.g., edit-config, delete-config, copy-config). If this is done in a non-secure environment without proper
protection, then negative effects on the network operation is possible.
ISO/IEC/IEEE 8802-1Q:2020/Amd.2:2021(E)
IEEE Std 802.1Qcp-2018
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks—
Amendment 30: YANG Data Model
The following objects in the ieee802-dot1q-tpmr YANG module could be manipulated to interfere with the
operation of MAC status propagation on a TPMR port and, for example, be used to cause network
instability:
interfaces/interface/bridge-port/mac-status-propagation/link-notify
interfaces/interface/bridge-port/mac-status-propagation/link-notify-wait
interfaces/interface/bridge-port/mac-status-propagation/link-notify-retry
interfaces/interface/bridge-port/mac-status-propagation/mac-notify
interfaces/interface/bridge-port/mac-status-propagation/mac-notify-time
interfaces/interface/bridge-port/mac-status-propagation/mac-recover-time
48.2
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...