ISO/IEC/IEEE 8802-1Q:2024/Amd 40:2026

• Status: Published
• Publication Date: 23-Aug-2026
• ICS: 35.110 - Networking
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Current Stage: 6060 - International Standard published
• Start Date: 24-Aug-2026
• Due Date: 26-Jun-2028
• Completion Date: 24-Aug-2026

• Amends: ISO/IEC/IEEE 8802-1Q:2024 - Telecommunications and exchange between information technology systems — Requirements for local and metropolitan area networks — Part 1Q: Bridges and bridged networks
• Effective Date: 28-Jun-2025

Overview

ISO/IEC/IEEE 8802-1Q:2024/Amd 40:2026 is an international standard developed through the collaborative efforts of ISO, IEC, and IEEE. This amendment, also known as IEEE Std 802.1Qdy™-2025, specifies the use of YANG data models for the Multiple Spanning Tree Protocol (MSTP) in local and metropolitan area networks (LAN/MAN). MSTP enables the efficient management of network bridges and VLANs, supporting reliable and resilient Ethernet networks essential for mission-critical applications such as industrial automation.

The amendment enhances the IEEE 802.1Q family of standards by providing models for the configuration and status reporting of MSTP and Rapid Spanning Tree Protocol (RSTP) components using YANG, a modern data modeling language widely adopted for network management and automation.

Key Topics

• YANG Data Models: Introduction of YANG schemas for MSTP and RSTP, enabling standardized, programmatic management of bridges and bridged networks.
• Network Automation: Facilitation of automated network configuration, monitoring, and troubleshooting through interoperable YANG models compatible with various network automation frameworks.
• MSTP Configuration and Reporting: YANG models provide detailed configuration capabilities for both the Common and Internal Spanning Tree (CIST) and Multiple Spanning Tree Instances (MSTIs), including VLAN and VID assignments within MST regions.
• State-of-the-Art Management: Support for real-time status reporting, facilitating the integration of MSTP with industrial and enterprise network management systems.
• Enhanced Conformance and Interoperability: The amendment clarifies bridge component requirements and options for MSTP management using YANG, ensuring that implementations meet consistent international standards.

Applications

Industrial Automation Networks

• Resilient and Flexible Topologies: MSTP YANG models empower automation networks to adopt complex topologies while maintaining loop-free, reliable operations across varying VLAN configurations.
• Programmable Network Management: Integration with industry-standard network controllers and management platforms ensures efficient commissioning, diagnostics, and maintenance.

Enterprise and Data Center Networks

• Simplified VLAN Management: YANG models enable centralized configuration of VLAN bridges and their spanning tree instances, leading to operational efficiency for large-scale, multi-tenant environments.
• Scalable Automation: Supports large networks by allowing administrators to automate repetitive configuration tasks and quickly adapt to changing network requirements.

Service Providers and Metropolitan Networks

• Standardized Configuration: The use of YANG enhances interoperability across multi-vendor environments, simplifying service deployment and lifecycle management in metropolitan area networks.

Related Standards

Organizations deploying or referencing ISO/IEC/IEEE 8802-1Q:2024/Amd 40:2026 may also consider the following related standards:

• IEEE 802.1Q™: The foundational standard for virtual LANs and bridging in LAN/MAN environments.
• IEEE 802.1Qcz™, 802.1Qcw™, 802.1Qcj™, 802.1Qdj™, 802.1Qdx™: Previous amendments addressing specific enhancements in bridging and network management.
• IEEE 802.1Q-2022: The consolidated standard for bridges and bridged networks, forming the basis for this amendment.
• YANG Data Modeling Language (RFC 6020, RFC 7950): The underlying technology for standardized, model-driven network management.
• Other MSTP and RSTP Implementations: As defined and referenced in the IEEE 802.1 family and related ISO/IEC standards for spanning tree protocols.

---

By adopting ISO/IEC/IEEE 8802-1Q:2024/Amd 40:2026, organizations can leverage YANG-based management to enhance the automation, reliability, and scalability of their LAN and metropolitan network infrastructure, in line with international best practices for telecommunications standards.

International
Standard
ISO/IEC/IEEE
8802-1Q
Third edition
Telecommunications and exchange
2024-08
between information technology
systems — Requirements for local
AMENDMENT 40
and metropolitan area networks —
2026-08
Part 1Q:
Bridges and bridged networks
AMENDMENT 40: YANG for the
multiple spanning tree protocol
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 40: YANG pour protocole MST (arbre de
recouvrement multiple)
Reference number
ISO/IEC/IEEE 8802-1Q:2024/
Amd.40:2026(en)
© IEEE 2025
ISO/IEC/IEEE 8802-1Q:2024/Amd.40:2026(en)
© IEEE 2025
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: [e-mail]
Website: www.ieee.org
Published in Switzerland
© IEEE 2025 – All rights reserved
ii
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
document should be noted.
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or
IEEE SA 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.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had received notice
of (a) patent(s) which may be required to implement this document. However, implementers are cautioned
that this may not represent the latest information, which may be obtained from the patent database available
at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for identifying
any or all such patent rights.
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:2024/Amd 40 was prepared by the LAN/MAN of the IEEE Computer Society (as IEEE
802.1Qdy-2025) 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 2025 – All rights reserved
iii
Title page
IEEE Std 802.1Qdy™-2025
(Amendment to IEEE Std 802.1Q™-2022
as amended by IEEE Std 802.1Qcz™-2023,
IEEE Std 802.1Qcw™-2023,
IEEE Std 802.1Qcj™-2023,
IEEE Std 802.1Qdj™-2024,
and IEEE Std 802.1Qdx™-2024)
IEEE Standard for
Local and Metropolitan Area Networks—
Bridges and Bridged Networks
Amendment 40:
YANG for the Multiple Spanning Tree
Protocol
Developed by the
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 12 February 2025
IEEE SA Standards Board
Abstract: This amendment to IEEE Std 802.1Q-2022 as amended by IEEE Std 802.1Qcz-2023,
IEEE Std 802.1Qcw-2023, IEEE Std 802.1Qcj-2023, IEEE Std 802.1Qdj-2024, and
IEEE Std 802.1Qdx-2024 addresses Multiple Spanning Tree Protocol (MSTP) requirements arising
from industrial automation networks. It specifies YANG for Bridge and Bridge component RSTP as
well as MSTP configuration and status reporting.
Keywords: amendment, Bridged Network, IEEE 802.1Q™, IEEE 802.1Qdy™, LAN, local area
network, MAC Bridge, metropolitan area network, MIB, MSTP, Multiple Spanning Tree Protocol,
Rapid Spanning Tree Protocol, RSTP, Virtual Bridged Network, virtual LAN, VLAN Bridge, YANG
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 21 February 2025. 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 979-8-8557-1851-5 STD27695
Print: ISBN 979-8-8557-1852-2 STDPD27695
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit https://www.ieee.org/about/corporate/governance/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.

Important Notices and Disclaimers Concerning IEEE Standards
Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers.
These notices and disclaimers, or a reference to this page (https://standards.ieee.org/ipr/disclaimers.html),
appear in all IEEE standards and may be found under the heading “Important Notices and Disclaimers
Concerning IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers involved in technical working groups
are not necessarily members of IEEE or IEEE SA 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 makes no warranties or representations concerning its standards, and expressly disclaims all
warranties, express or implied, concerning all standards, including but not limited to the warranties of
merchantability, fitness for a particular purpose and non-infringement. IEEE Standards documents do not
guarantee safety, security, health, or environmental protection, or compliance with law, or guarantee against
interference with or from other devices or networks. In addition, IEEE does not warrant or represent that the
use of the material contained in its standards is free from patent infringement. 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 their
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: THE
NEED TO PROCURE 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.
Translations
The IEEE consensus balloting process involves the review of documents in English only. In the event that an
IEEE standard is translated, only the English language version published by IEEE is the approved IEEE
standard.
Use by artificial intelligence systems
In no event shall material in any IEEE Standards documents be used for the purpose of creating, training, en-
hancing, developing, maintaining, or contributing to any artificial intelligence systems without the express,
written consent of the IEEE SA in advance. “Artificial intelligence” refers to any software, application, or
other system that uses artificial intelligence, machine learning, or similar technologies, to analyze, train, pro-
cess, or generate content. Requests for consent can be submitted using the Contact Us form.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations
Manual is not, and 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 or IEEE SA. At
lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards
shall make it clear that the presenter’s views should be considered the personal views of that individual rather
than the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group. Statements
made by volunteers may not represent the formal position of their employer(s) or affiliation(s). News releases
about IEEE standards issued by entities other than IEEE SA should be considered the view of the entity
issuing the release rather than the formal position of IEEE or IEEE SA.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations,
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 subcommittees of the IEEE SA Board of
Governors 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 evaluating comments or revisions to an IEEE standard is welcome
to join the relevant IEEE SA working group. You can indicate interest in a working group using the Interests
tab in the Manage Profile & Interests area of the IEEE SA myProject system. An IEEE Account is needed to
access the application.
Comments on standards should be submitted using the Contact Us form.
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 constitute compliance to any applicable regulatory
Available at: https://standards.ieee.org/about/contact/.
Available at: https://development.standards.ieee.org/myproject-web/public/view.html#landing.
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.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
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, neither IEEE nor its licensors waive any rights in copyright
to the documents.
Photocopies
Subject to payment of the appropriate licensing fees, 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; [phone];
https://www.copyright.com/. 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. An official 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 10 years. When a document is more than 10 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 IEEE Xplore or contact IEEE. For more
information about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number
and year of approval to access the web page of the published standard. Errata links are located under the
Available at: https://ieeexplore.ieee.org/browse/standards/collection/ieee.
Available at: https://standards.ieee.org/standard/index.html.
Additional Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to
periodically check for errata.
Patents
IEEE standards are developed in compliance with the IEEE SA Patent Policy.
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 https://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.
IMPORTANT NOTICE
Technologies, application of technologies, and recommended procedures in various industries evolve over
time. The IEEE standards development process allows participants to review developments in industries,
technologies, and practices, and to determine what, if any, updates should be made to the IEEE standard.
During this evolution, the technologies and recommendations in IEEE standards may be implemented in
ways not foreseen during the standard’s development. IEEE standards development activities consider
research and information presented to the standards development group in developing any safety
recommendations. Other information about safety practices, changes in technology or technology
implementation, or impact by peripheral systems also may be pertinent to safety considerations during
implementation of the standard. Implementers and users of IEEE Standards documents are responsible for
determining and complying with all appropriate safety, security, environmental, health, data privacy, and
interference protection practices and all applicable laws and regulations.
Available at: https://standards.ieee.org/about/sasb/patcom/materials.html.
Participants
At the time this standard was submitted to the IEEE SA Standards Board for approval, the IEEE 802.1
Working Group had the following membership:
Glenn Parsons, Chair
Jessy V. Rouyer, Vice Chair
János Farkas, Chair, Time-Sensitive Networking Task Group
David McCall, Vice Chair, Time-Sensitive Networking Task Group
Martin Mittelberger, Editor
Mahin Ahmed Daniel Hopf Rajeev Roy
Katsuyuki Akizuki Woojung Huh Atsushi Sato
Venkat Arunarthi Satoko Itaya Frank Schewe
Ralf Assmann Yoshihiro Ito Mick Seaman
Rudy Belliardi Michael Karl Maik Seewald
Stephan Kehrer
Christian Boiger Ramesh Sivakolundu
Paul Bottorff Marcel Kiessling Johannes Specht
Radhakrishna Canchi Gavin Lai Nemanja Stamenic
Feng Chen Yunping (Lily) Lyu Marius Stanica
Lihao Chen Christophe Mangin Guenter Steindl
Abhijit Choudhury Scott Mansfield Karim Traore
Anna Engelmann Olaf Mater Max Turner
Donald Fedyk Hiroki Nakano Balázs Varga
Norman Finn Takumi Nomura Ganesh Venkatesan
Geoffrey Garner Donald R. Pannell Leon Wessels
Craig Gunther Dieter Proell Ludwig Winkel
Stephen Haddock Karen Randall Jordon Woods
Mark Hantel Maximilian Riegel Takahiro Yamaura
Marc Holness Silvana Rodrigues Nader Zein
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Boon Chong Ang Raj Jain Dieter Proell
Butch Anton SangKwon Jeong Benjamin Rolfe
Stefan Aust Pranav Jha
Jessy V. Rouyer
Murugan Balraj Piotr Karocki
Reinhard Schrage
Harry Bims Stuart Kerry
Mick Seaman
William Byrd Quist-Aphetsi Kester
Jhony Sembiring
Paul Cardinal Yongbum Kim
Johannes Specht
Pin Chang Hyeong Ho Lee
Guenter Steindl
Donald Dunn Daozhuang Lin
Walter Struppler
Marc Emmelmann Christophe Mangin
Max Turner
János Farkas Scott Mansfield
John Vergis
Donald Fedyk William Rogelio Marchand Nino
Stephen Webb
Avraham Freedman Ignacio Marin Garcia
Scott Willy
Stephen Haddock Jonathon McLendon
Ludwig Winkel
Marco Hernandez Martin Mittelberger
Andreas Wolf
Werner Hoelzl Bansi Patel
Oliver Holland Arumugam Paventhan Oren Yuen
When the IEEE SA Standards Board approved this standard on 12 February 2025, it had the following
membership:
Lei Wang, Chair
Vacant Position, Vice Chair
David J. Law, Past Chair
Alpesh Shah, Secretary
Edward Au Ronald W. Hotchkiss Daleep Mohla
Ted Burse Tyler Jaynes Annette Reilly
Xiaofeng (Alfred) Chen Thomas Koshy Robby Robson
Doug Edwards Howard Li Jon W. Rosdahl
Nehad El-Sherif Xiaohui Liu Dan Sabin
J. Travis Griffith Kevin W. Lu F. Keith Waters
Deborah Hagar Hiroshi Mano Sha Wei
Guido R. Hiertz Luyang (Eric) Zhang
Introduction
This introduction is not part of IEEE Std 802.1Qdy™-2025, IEEE Standard for Local and Metropolitan Area
Networks—Bridges and Bridged Networks—Amendment 40: YANG for the Multiple Spanning Tree Protocol.
IEEE Std 802.1Qdy™-2025: YANG for the Multiple Spanning Tree Protocol addresses requirements
arising from industrial automation networks, specifying YANG for Bridge and Bridge component MSTP
configuration and status reporting.
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
Contents
5. Conformance. 14
5.1 VLAN Bridge component requirements. 14
5.4.1 VLAN Bridge component options . 14
13. Spanning tree protocols . 15
13.25 State machine timers. 15
48. YANG Data Models . 16
48.2 IEEE 802.1Q YANG models. 16
48.2.14 Rapid Spanning Tree Protocol (RSTP) model . 16
48.2.15 Multiple Spanning Tree Protocol (MSTP) model . 17
48.3 Structure of the YANG models . 18
48.3.14 RSTP model . 18
48.3.15 MSTP model . 18
48.4 Security considerations . 20
48.4.14 Security considerations of the RSTP model . 20
48.4.15 Security considerations of the MSTP model . 20
48.5 YANG schema tree definitions. 21
48.5.26 Schema for the ieee802-dot1q-rstp YANG module . 21
48.5.27 Schema for the ieee802-dot1q-rstp-bridge YANG module . 21
48.5.28 Schema for the ieee802-dot1q-mstp YANG module . 22
48.5.29 Schema for the ieee802-dot1q-mstp-bridge YANG module . 22
48.6 YANG modules . 24
48.6.26 The ieee802-dot1q-rstp YANG module . 24
48.6.27 The ieee802-dot1q-rstp-bridge YANG module . 34
48.6.28 The ieee802-dot1q-mstp YANG module . 35
48.6.29 The ieee802-dot1q-mstp-bridge YANG module . 42
Annex A (normative) PICS proforma—Bridge implementations . 44
A.47 YANG. 44
Figures
Figure 48-24 RSTP model. 16
Figure 48-25 MSTP model . 17
Tables
Table 13-5 Timer and related parameter values. 15
Table 48-1 Summary of the YANG modules. 18
Table 48-15 RSTP model YANG modules. 18
Table 48-16 MSTP model YANG modules. 19
IEEE Standard for
Local and Metropolitan Area Networks—
Bridges and Bridged Networks
Amendment 40:
YANG for the Multiple Spanning Tree
Protocol
(This amendment is based on IEEE Std 802.1Q™-2022 as amended by IEEE Std 802.1Qcz™-2023,
IEEE Std 802.1Qcw™-2023, IEEE Std 802.1Qcj™-2023, IEEE Std 802.1Qdj™-2024, and IEEE Std
802.1Qdx™-2024.)
NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into
the existing base standard and its amendments to form the comprehensive standard.
The editing instructions are shown in bold italics. 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. Deletions
and 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.
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
5. Conformance
5.1 VLAN Bridge component requirements
5.4.1 VLAN Bridge component options
5.4.1.1 Multiple Spanning Tree (MST) operation (optional)
Insert new list item q) after item p) in 5.4.1.1 as follows:
q) Support YANG modules for the management of MSTP (48.6.26, 48.6.27, 48.6.28, and 48.6.29).
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
13. Spanning tree protocols
13.25 State machine timers
Change Table 13-5 as follows:
Table 13-5—Timer and related parameter values
Permitted Interoperability
Parameter Default
range recommendations
a a
Migrate Time 3.0 — —
a a
(Bridge) Hello Time 2.0 — —
Bridge Max Age 20.0 6.0–40.0 20.0
Bridge Forward Delay 15.0 4.0–30.0 15.0
Transmit Hold Count 6 1–10 6
Max Hops 20 6–40100 —
a
All times are in seconds. — Not applicable, value is fixed.
Change the Note in 13.25 as follows:
NOTE—Changes to Bridge Forward Delay do not affect reconfiguration times, unless the network includes Bridges that
do not conform to this revision of this standard. Changes to Bridge Max Age can have an effect, as it is possible for old
information to persist in loops in the physical topology for a number of “hops” equal to the value of Max Age in seconds,
and thus exhaust the Transmit Hold Count in small loops. The IEEE Std 802.1Qdy-2025 amendment to this standard
increased the permitted range of Max Hops to allow a spanning tree to provide initial and remedial connectivity in
extended ring topologies whenever physical connectivity is possible. Once configured such networks are not expected to
depend on spanning tree for failure protection.
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
48. YANG Data Models
48.2 IEEE 802.1Q YANG models
Insert 48.2.14 and 48.2.15 at the end of 48.2 as follows:
48.2.14 Rapid Spanning Tree Protocol (RSTP) model
The RSTP model augments the VLAN Bridge components model (48.2.1, Figure 48-4) and the Interface
management model for Bridge Ports (48.2.1, Figure 48-5) with nodes common to both RSTP and MSTP.
These nodes control the configuration of the CST (and the CIST, when augmented by the Multiple Spanning
Tree model, 48.2.15) and report on protocol operation. The RSTP model is illustrated in Figure 48-24.
Figure 48-24—RSTP model
component (name) bridge-port
leafref bridge-name; // r-w
string name; // r-w
leafref component-name; // r-w
...
...
rstp // (13.4) rstp // (13.4)
enum force-protocol-version; // (13.7.2)  r-w bool admin-bridge-port-enabled; // (8.4) r-w
bridge-id bridge-id port-state port-state; // (8.4) r
{ uint64 bridge-id; // (13.26.2) r port-role port-role; // (13.4) r
id-priority bridge-priority; // (14.2)  r-w bool restricted-role; // (13.20) r-w
uint16 system-id-extension; // (13.26.2) r bool restricted-tcn; // (13.20) r-w
ieee:macaddress bridge-address; }; // (8.13.8) r
port-id port-id
bridge-id root-id
{ uint16 port-id; // (13.26) r
{ uint64 bridge-id; // (13.4) r
id-priority port-priority; // (14.2) r-w
id-priority bridge-priority; // (14.2) r
id-port-number port-number; }; // (12.3) r
uint16 system-id-extension; // (13.26) r
uint32 fix-port-path-cost; // (13.10) r-w
ieee:macaddress bridge-address; }; // (8.13.8) r
uint32 port-path-cost; // (13.4) r-w
uint32 root-path-cost; // (13.4) r
uint8 designated-protocol-version; // (14.2) r
union root-port; // (13.4) r
bridge-id root-id
uint8 max-age; // (13.15) r
{ uint64 bridge-id; // (13.4) r
uint8 hello-time; // (13.25) r
id-priority bridge-priority; // (14.2) r
uint8 forward-delay; // (13.25) r
uint16 system-id-extension; // (13.26) r
uint8 bridge-max-age; // (13.25) r-w
ieee:macaddress bridge-address; }; // (8.13.8) r
uint8 bridge-forward-delay; // (13.25) r-w
uint32 root-path-cost; // (13.4) r
uint8 tx-hold-count; // (13.25) r-w
bridge-id designated-bridge-id
yang:date-and-time last-topology-change; // (13.25) r
{ uint64 bridge-id; // (13.4) r
id-priority bridge-priority; // (14.2) r-w
uint16 system-id-extension; // (13.26) r
ieee:macaddress bridge-address; }; // (8.13.8) r
port-id designated-port-id
{ uint16 port-id; // (13.26) r
id-priority port-priority; // (14.2) r
id-port-number port-number; }; // (12.3) r
VLAN Bridge component and port nodes
bool admin-edge-port; // (13.33) r-w
bool oper-edge-port; // (13.33) r
Objects added or augmented by this model
bool auto-edge-port; // (13.33) r-w
bool disputed-port; // (13.21) r
bool isolate-port; // (13.23) r
action port-protocol-migration-check; // (13.32)
Figure 48-24—RSTP model
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
48.2.15 Multiple Spanning Tree Protocol (MSTP) model
The Multiple Spanning Tree Protocol model augments the bridge-mst container of the VLAN Bridge
components model (48.2.1) and the RSTP model (48.2.14) with nodes for MSTP. These nodes control the
configuration of the CIST and MSTIs and the assignment of VLANs and VIDs to MSTIs (8.9) within MST
Regions. They also report on MSTP protocol operation. The Multiple Spanning Tree Protocol model is
illustrated in Figure 48-25.
Figure 48-25—MSTP model
component (name) bridge-port
string name; // r-w leafref bridge-name; // r-w
... leafref component-name; // r-w
...
bridge-mst bridge-vlan
int * mstid; // (12.12.1) r-w …
*
vid-to-fid (vid) // (8.6.1, 8.8.8, 8.9)
vlan-index-typevid; // (8.9)r-w
uint32 fid; // (8.9)r-w
*
rstp // (48.6.26) fid-to-mstid (fid) // (8.8.8, 8.9) rstp // (48.6.26)
... uint32 fid; // (8.9.3) r-w ...
mstid-type mstid; // (8.9.3) r-w
bridge-mstp // (13.5) port-mstp // (13.5)
uint8 max-hops; // (Table 13-5, 13.26.4) r-w bool boundary-port; // (13.12) r
bool restricted-domain-role; // (13.27.63) r-w
ist // (7.3, 13.5) ist // (7.3, 13.5)
uint32 internal-root-path-cost; // (13.9, Fig. 14-1) r uint32 fix-internal-port-path-cost; // (13.10) r-w
uint32 internal-port-path-cost; // (13.10) r
uint32 internal-root-path-cost; // (13.9) r
bridge-id designated-bridge-id
{ uint64 bridge-id; // (13.10) r
id-priority bridge-priority; // (14.2) r-w
uint16 system-id-extension; // (13.26) r
ieee:macaddress bridge-address; }; // (8.13.8) r
uint8 remaining-hops; // (13.20) r
mst-config-id // (13.8)
mst-config-id // (13.8, Figure 14-1)
uint8 format-selector; // (13.8) r
uint8 format-selector; // (13.8) r
string configuration-name; // (13.8) r
string configuration-name; // (13.8) r
uint16 revision-level; // (13.8) r
uint16 revision-level; // (13.8) r
binary configuration-digest; // (13.8) r
binary configuration-digest; // (13.8) r
*
msti (mstid) // (8.4, 13.26, 13.9, 13.11)
*
msti (mstid) // (8.4)
uint16 mstid; // 1.4091  (8.6.1, 8.9) r-w
uint16 mstid; // (8.6.1, 8.9) r-w
id-priority bridge-priority; // (13.11) r-w
port-state port-state; // (8.4) r
bridge-id regional-root-id
union port-role; // (13.5) r
{ uint64 bridge-id; // (13.10) r
port-id port-id;
id-priority bridge-priority; // (14.2) r
{ uint16 port-id; // (13.26) r
uint16 system-id-extension; // (13.26) r
id-priority port-priority; // (14.2) r-w
ieee:macaddress bridge-address; }; // (8.13.8) r
id-port-number port-number; }; // (12.3) r
uint32 internal-root-path-cost; // (13.9) r
uint32 fix-internal-port-path-cost; // (13.11) r-w
union root-port; // (13.5) r
uint32 internal-port-path-cost; // (13.2.1) r
bridge-id regional-root-id;
{ uint64 bridge-id; // (13.10) r
id-priority bridge-priority; // (14.2) r
uint16 system-id-extension; // (13.26) r
ieee:macaddress bridge-address; }; // (8.13.8) r
uint32 internal-root-path-cost; // (13.9) r
bridge-id designated-bridge-id
VLAN Bridge component and port nodes + RSTP nodes
{ uint64 bridge-id; // (13.10) r
id-priority bridge-priority; // (14.2) r
Objects added or augmented by this model
uint16 system-id-extension; // (13.26) r
ieee:macaddress bridge-address; }; // (8.13.8) r
port-id designated-port-id
{ uint16 port-id; // (13.26) r
id-priority port-priority; // (14.2) r
id-port-number port-number; }; // (12.3) r
bool disputed-port; // (13.21) r
uint8 remaining-hops; // (13.20) r
Figure 48-25—MSTP model
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
48.3 Structure of the YANG models
Insert four new rows at the end of Table 48-1 as follows (unchanged rows not shown):
Table 48-1—Summary of the YANG modules
Module References Managed Initial YANG specification
functionality Notes
ieee802-dot1q-rstp 48.5.26, IEEE Std 802.1Qdy
48.6.26 Bridge and Bridge Port RSTP parameters.
8.4, 8.7, 8.8,
8.10,
ieee802-dot1q-rstp-bridge 48.5.27, IEEE Std 802.1Qdy
Clause 13
48.6.27 Augments Bridge components and Bridge Ports with
RSTP parameters.
ieee802-dot1q-mstp 48.5.28, IEEE Std 802.1Qdy
48.6.28 Bridge and Bridge Port MSTP parameters.
8.4, 8.7, 8.8,
8.8, 8.9, 8.10,
ieee802-dot1q-mstp-bridge 48.5.29, IEEE Std 802.1Qdy
Clause 13
48.6.29 Augments RSTP-capable Bridge components and
Bridge Ports with MSTP parameters.
Insert 48.3.14 and 48.3.15 after 48.3.13 (inserted by IEEE Std 802.1Qdx-2024) as follows:
48.3.14 RSTP model
A bridge implementing the RSTP model (48.2.14) implements the YANG modules in Table 48-15.
Table 48-15—RSTP model YANG modules
YANG module
ieee802-types
ieee802-dot1q-types
ieee802-dot1q-bridge
ieee802-dot1q-rstp
ieee802-dot1q-rstp-bridge
48.3.15 MSTP model
A bridge implementing the MSTP model (48.2.15) implements the YANG modules in Table 48-16.
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
Table 48-16—MSTP model YANG modules
YANG module
ieee802-types
ieee802-dot1q-types
ieee802-dot1q-bridge
ieee802-dot1q-rstp
ieee802-dot1q-rstp-bridge
ieee802-dot1q-mstp
ieee802-dot1q-mstp-bridge
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
48.4 Security considerations
Insert 48.4.14 and 48.4.15 after 48.4.13 (inserted by IEEE Std 802.1Qdx-2024) as follows:
48.4.14 Security considerations of the RSTP model
All writeable nodes in the ieee802-dot1q-rstp YANG module could be manipulated to interfere with basic
networking connectivity.
See 48.4.1 for related ieee802-dot1q-bridge YANG model security considerations.
48.4.15 Security considerations of the MSTP model
All writeable nodes in the ieee802-dot1q-mstp YANG module could be manipulated to interfere with basic
networking connectivity.
See 48.4.1 for related ieee802-dot1q-bridge YANG model security considerations.
IEEE Std 802.1Qdy™-2025
IEEE Standard for Local and Metropolitan Area Networks—Bridges and Bridged Networks
Amendment 40: YANG for the Multiple Spanning Tree Protocol
48.5 YANG schema tree definitions
Insert 48.5.26, 48.5.27, 48.5.28, and 48.5.29 at the end of 48.5 as follows:
48.5.26 Schema for the ieee802-dot1q-rstp YANG module
This YANG module does not have a YANG schema tree.
48.5.27 Schema for the ieee802-dot1q-rstp-bridge YANG module
module: ieee802-dot1q-rstp-bridge
augment /dot1q:bridges/dot1q:bridge/dot1q:component:
+--rw rstp!
+--rw force-protocol-version?  enumeration
+--rw bridge-id
| +--ro bridge-id?       uint64
| +--rw bridge-priority?    id-priority
| +--ro system-id-extension?  uint16
| +--ro bridge-address?    ieee:mac-address
+--ro root-id
| +--ro bridge-id?       uint64
| +--ro bridge-priority?    id-priority
| +--ro system-id-extension?  uint16
| +--ro bridge-address?    ieee:mac-address
+--ro root-path-cost?      uint32
+--ro root-port?        union
+--ro max-age?         uint8
+--ro hello-time?        uint8
+--ro forward-delay?      uint8
+--rw bridge-max-age?      uint8
+--rw bridge-forward-delay?   uint8
+--rw tx-hold-count?      uint8
+--ro l
...