rfc9166.original   rfc9166.txt 
PIM Working Group H. Zhao
Internet Draft Ericsson
Intended status: Standards Track X. Liu
Expires: April 07, 2022 Volta Networks
Y. Liu
China Mobile
M. Sivakumar
Juniper
A. Peter
Individual
October 08, 2021 Internet Engineering Task Force (IETF) H. Zhao
Request for Comments: 9166 Ericsson
Category: Standards Track X. Liu
ISSN: 2070-1721 IBM Corporation
Y. Liu
China Mobile
A. Peter
Individual
M. Sivakumar
Juniper Networks
January 2022
A Yang Data Model for IGMP and MLD Snooping A YANG Data Model for Internet Group Management Protocol (IGMP) and
draft-ietf-pim-igmp-mld-snooping-yang-20.txt Multicast Listener Discovery (MLD) Snooping
Abstract Abstract
This document defines a YANG data model that can be used to configure This document defines a YANG data model that can be used to configure
and manage Internet Group Management Protocol (IGMP) and Multicast and manage Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping devices. The YANG module in this Listener Discovery (MLD) snooping devices. The YANG module in this
document conforms to Network Management Datastore Architecture (NMDA). document conforms to the Network Management Datastore Architecture
(NMDA).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on April 07, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9166.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
(http://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 Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction
1.1. Terminology...............................................3 1.1. Terminology
1.2. Tree Diagrams.............................................3 1.2. Tree Diagrams
1.3. Prefixes in Data Node Names...............................4 1.3. Prefixes in Data Node Names
2. Design of Data Model...........................................4 2. Design of Data Model
2.1. Overview..................................................5 2.1. Overview
2.2. Optional Capabilities.....................................5 2.2. Optional Capabilities
2.3. Position of Address Family in Hierarchy...................6 2.3. Position of Address Family in Hierarchy
3. Module Structure...............................................6 3. Module Structure
3.1. IGMP Snooping Instances...................................6 3.1. IGMP Snooping Instances
3.2. MLD Snooping Instances....................................8 3.2. MLD Snooping Instances
3.3. Using IGMP and MLD Snooping Instances....................10 3.3. Using IGMP and MLD Snooping Instances
3.4. IGMP and MLD Snooping Actions............................11 3.4. IGMP and MLD Snooping Actions
4. IGMP and MLD Snooping YANG Module.............................11 4. IGMP and MLD Snooping YANG Module
5. Security Considerations.......................................31 5. Security Considerations
6. IANA Considerations...........................................33 6. IANA Considerations
6.1. XML Registry.............................................33 6.1. XML Registry
6.2. YANG Module Names Registry...............................33 6.2. YANG Module Names Registry
7. References....................................................34 7. References
7.1. Normative References.....................................34 7.1. Normative References
7.2. Informative References...................................35 7.2. Informative References
Appendix A. Data Tree Example...................................36 Appendix A. Data Tree Example
Authors' Addresses...............................................39 Authors' Addresses
1. Introduction
This document defines a YANG [RFC7950] data model for the management of 1. Introduction
Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping [RFC4541] devices.
The YANG module in this document conforms to the Network Management This document defines a YANG [RFC7950] data model for the management
Datastore Architecture defined in [RFC8342]. The "Network Management of IGMP and MLD snooping [RFC4541] devices.
Datastore Architecture" (NMDA) adds the ability to inspect the current
operational values for configuration, allowing clients to use identical
paths for retrieving the configured values and the operational values.
1.1. Terminology The YANG module in this document conforms to the NMDA defined in
[RFC8342]. The NMDA adds the ability to inspect the current
operational values for configuration, allowing clients to use
identical paths for retrieving the configured values and the
operational values.
The terminology for describing YANG data models is found in [RFC6020] 1.1. Terminology
and [RFC7950], including: The terminology for describing YANG data models is found in [RFC6020]
and [RFC7950], including:
* augment * augment
* data model * data model
* data node * data node
* identity * identity
* module * module
The following terminologies are used in this document: The following terminologies are used in this document:
* mrouter: multicast router, which is a router that has multicast mrouter: multicast router, which is a router that has multicast
routing enabled [RFC4286]. routing enabled [RFC4286].
* mrouter interfaces: snooping switch ports where multicast routers mrouter interfaces: snooping switch ports where multicast routers
are attached [RFC4541]. are attached [RFC4541].
The following abbreviations are used in this document and defined model: The following abbreviations are used in this document and defined
model:
IGMP: Internet Group Management Protocol [RFC3376]. IGMP: Internet Group Management Protocol [RFC3376].
MLD: Multicast Listener Discovery [RFC3810]. MLD: Multicast Listener Discovery [RFC3810].
1.2. Tree Diagrams 1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in Tree diagrams used in this document follow the notation defined in
[RFC8340].
[RFC8340]. 1.3. Prefixes in Data Node Names
1.3. Prefixes in Data Node Names In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise,
names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1.
In this document, names of data nodes, actions, and other data model +==========+======================+===========+
objects are often used without a prefix, as long as it is clear from the | Prefix | YANG module | Reference |
context in which YANG module each name is defined. Otherwise, names are +==========+======================+===========+
prefixed using the standard prefix associated with the corresponding | inet | ietf-inet-types | [RFC6991] |
YANG module, as shown in Table 1. +----------+----------------------+-----------+
| yang | ietf-yang-types | [RFC6991] |
+----------+----------------------+-----------+
| if | ietf-interfaces | [RFC8343] |
+----------+----------------------+-----------+
| rt | ietf-routing | [RFC8349] |
+----------+----------------------+-----------+
| rt-types | ietf-routing-types | [RFC8294] |
+----------+----------------------+-----------+
| dot1q | ieee802-dot1q-bridge | [dot1Qcp] |
+----------+----------------------+-----------+
+----------+-----------------------+---------------------------------+ Table 1: Prefixes and Corresponding YANG
| Prefix | YANG module | Reference | Modules
+==========+=======================+=================================+
| inet | ietf-inet-types | [RFC6991] |
+----------+-----------------------+---------------------------------+
| yang | ietf-yang-types | [RFC6991] |
+----------+-----------------------+---------------------------------+
| if | ietf-interfaces | [RFC8343] |
+----------+-----------------------+---------------------------------+
| rt | ietf-routing | [RFC8349] |
+----------+-----------------------+---------------------------------+
| rt-types | ietf-routing-types | [RFC8294] |
+----------+-----------------------+---------------------------------+
| dot1q | ieee802-dot1q-bridge | [dot1Qcp] |
+----------+-----------------------+---------------------------------+
Table 1: Prefixes and Corresponding YANG Modules
2. Design of Data Model 2. Design of Data Model
An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and
up forwarding tables for multicast traffic. If a switch does not run sets up forwarding tables for multicast traffic. If a switch does
IGMP/MLD snooping, multicast traffic will be flooded in the broadcast not run IGMP/MLD snooping, multicast traffic will be flooded in the
domain. If a switch runs IGMP/MLD snooping, multicast traffic will be broadcast domain. If a switch runs IGMP/MLD snooping, multicast
forwarded based on the forwarding tables to avoid wasting bandwidth. The traffic will be forwarded based on the forwarding tables to avoid
IGMP/MLD snooping switch does not need to run any of the IGMP/MLD wasting bandwidth. The IGMP/MLD snooping switch does not need to run
protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD any of the IGMP/MLD protocols. Because the IGMP/MLD snooping is
protocols, the data model defined in this document does not augment, or independent of the IGMP/MLD protocols, the data model defined in this
even require, the IGMP/MLD data model defined in [RFC8652]. document does not augment, or even require, the IGMP/MLD data model
The model covers considerations for Internet Group Management Protocol defined in [RFC8652]. The model covers considerations for IGMP and
(IGMP) and Multicast Listener Discovery (MLD) Snooping Switches MLD snooping switches [RFC4541].
[RFC4541].
IGMP and MLD snooping switches do not adhere to the conceptual model IGMP and MLD snooping switches do not adhere to the conceptual model
that provides the strict separation of functionality between different that provides the strict separation of functionality between
communications layers in the ISO model, and instead utilize information different communications layers in the ISO model and instead utilize
in the upper level protocol headers as factors to be considered in information in the upper-level protocol headers as factors to be
processing at the lower levels [RFC4541]. considered in processing at the lower levels [RFC4541].
IGMP Snooping switches utilize IGMP, and could support IGMPv1 [RFC1112], IGMP snooping switches utilize IGMP and could support IGMPv1
IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD Snooping switches utilize [RFC1112], IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD snooping
MLD, and could support MLDv1 [RFC2710] and MLDv2 [RFC3810]. The goal of switches utilize MLD and could support MLDv1 [RFC2710] and MLDv2
this document is to define a data model that provides a common user [RFC3810]. The goal of this document is to define a data model that
interface to IGMP and MLD Snooping. provides a common user interface to IGMP and MLD snooping.
2.1. Overview 2.1. Overview
The IGMP and MLD Snooping YANG module defined in this document has all The YANG module on IGMP and MLD snooping defined in this document has
the common building blocks for the IGMP and MLD Snooping switches. all the common building blocks for the IGMP and MLD snooping
switches.
The YANG module includes IGMP and MLD Snooping instance definition, The YANG module includes an IGMP and MLD snooping instance definition
using instance in the L2 service type of BRIDGE [dot1Qcp]. It also that uses the instance in the L2 service type of bridge [dot1Qcp].
includes actions for clearing IGMP and MLD Snooping group tables. It also includes actions for clearing IGMP and MLD snooping group
tables.
The YANG module doesn't cover L2VPN, which will be specified in a The YANG module doesn't cover L2VPN, which will be specified in a
separated document. separate document.
2.2. Optional Capabilities 2.2. Optional Capabilities
This model is designed to represent the basic capability subsets of IGMP This model is designed to represent the basic capability subsets of
and MLD Snooping. The main design goals of this document are that the IGMP and MLD snooping. The main design goals of this document are
basic capabilities described in the model are supported by any major that the basic capabilities described in the model are supported by
now-existing implementation, and that the configuration of all any major now-existing implementation and that the configuration of
implementations meeting the specifications is easy to express through all implementations meeting the specifications is easy to express
some combination of the optional features in the model and simple vendor through some combination of the optional features in the model and
augmentations. simple vendor augmentations.
There is also value in widely supported features being standardized, to There is also value in widely supported features being standardized
provide a standardized way to access these features, to save work for to provide a standardized way to access these features, to save work
individual vendors, and so that mapping between different vendors' for individual vendors, and to ensure that mapping between different
configuration is not needlessly complicated. Therefore, this model vendors' configuration is not needlessly complicated. Therefore,
declares a number of features representing capabilities that not all this model declares a number of features representing capabilities
deployed devices support. that not all deployed devices support.
The extensive use of feature declarations should also substantially The extensive use of feature declarations should also substantially
simplify the capability negotiation process for a vendor's IGMP and MLD simplify the capability negotiation process for a vendor's IGMP and
Snooping implementations. MLD snooping implementations.
On the other hand, operational state parameters are not so widely On the other hand, operational state parameters are not so widely
designated as features, as there are many cases where the defaulting designated as features, as there are many cases where the defaulting
of an operational state parameter would not cause any harm to the of an operational state parameter would not cause any harm to the
system, and it is much more likely that an implementation without system, and it is much more likely that an implementation without
native support for a piece of operational state would be able to derive intrinsic support for a piece of operational state would be able to
a suitable value for a state variable that is not natively supported. derive a suitable value for a state variable that is not
intrinsically supported.
2.3. Position of Address Family in Hierarchy 2.3. Position of Address Family in Hierarchy
IGMP Snooping only supports IPv4, while MLD Snooping only supports IPv6. IGMP snooping only supports IPv4, while MLD snooping only supports
The data model defined in this document can be used for both IPv4 and IPv6. The data model defined in this document can be used for both
IPv6 address families. IPv4 and IPv6 address families.
This document defines IGMP Snooping and MLD Snooping as separate schema This document defines IGMP snooping and MLD snooping as separate
branches in the structure. The benefits are: schema branches in the structure. The benefits are:
* The model can support IGMP Snooping (IPv4), MLD Snooping (IPv6), or * The model can support IGMP snooping (IPv4), MLD snooping (IPv6),
both optionally and independently. Such flexibility cannot be achieved or both optionally and independently. Such flexibility cannot be
cleanly with a combined branch. achieved cleanly with a combined branch.
* The structure is consistent with other YANG data models such as * The structure is consistent with other YANG data models such as
[RFC8652], which uses separate branches for IPv4 and IPv6. [RFC8652], which uses separate branches for IPv4 and IPv6.
* Having separate branches for IGMP Snooping and MLD Snooping allows * Having separate branches for IGMP snooping and MLD snooping allows
minor differences in their behavior to be modelled more simply and minor differences in their behavior to be modeled more simply and
cleanly. The two branches can better support different features and node cleanly. The two branches can better support different features
types. and node types.
3. Module Structure 3. Module Structure
This model augments the core routing data model specified in [RFC8349]. This model augments the core routing data model specified in
[RFC8349].
+--rw routing +--rw routing
+--rw router-id? +--rw router-id?
+--rw control-plane-protocols +--rw control-plane-protocols
| +--rw control-plane-protocol* [type name] | +--rw control-plane-protocol* [type name]
| +--rw type | +--rw type
| +--rw name | +--rw name
| +--rw igmp-snooping-instance <= Augmented by this Model | +--rw igmp-snooping-instance <= Augmented by this Model
... ...
| +--rw mld-snooping-instance <= Augmented by this Model | +--rw mld-snooping-instance <= Augmented by this Model
... ...
The "igmp-snooping-instance" container instantiates an IGMP Snooping
Instance. The "mld-snooping-instance" container instantiates an MLD
Snooping Instance.
The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA) [RFC8342]. The operational
state data is combined with the associated configuration data in the
same hierarchy [RFC8407].
3.1. IGMP Snooping Instances
The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control-
plane-protocols/rt:control-plane-protocol to add the igmp-snooping-
instance container.
All the IGMP Snooping related attributes have been defined in the igmp- The "igmp-snooping-instance" container instantiates an IGMP snooping
snooping-instance. The read-write attributes represent configurable instance. The "mld-snooping-instance" container instantiates an MLD
data. The read-only attributes represent state data. snooping instance.
One igmp-snooping-instance could be used in one BRIDGE [dot1Qcp]
instance, and it corresponds to one BRIDGE instance.
Currently the value of l2-service-type in igmp-snooping-instance could
only be set bridge. After it is set, igmp-snooping-instance could be
used in the BRIDGE service.
The values of bridge-mrouter-interface is filled by the snooping device
dynamically. It is different from static-bridge-mrouter-interface which
is configured.
The attributes under the interfaces show the statistics of IGMP Snooping
related packets.
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--rw igmp-snooping-instance {igmp-snooping}?
+--rw l2-service-type? l2-service-type
+--rw enable? boolean
+--rw forwarding-table-type? enumeration
+--rw explicit-tracking? boolean
| {explicit-tracking}?
+--rw lite-exclude-filter? empty
| {lite-exclude-filter}?
+--rw send-query? boolean
+--rw fast-leave? empty {fast-leave}?
+--rw last-member-query-interval? uint16
+--rw query-interval? uint16
+--rw query-max-response-time? uint16
+--rw require-router-alert? boolean
| {require-router-alert}?
+--rw robustness-variable? uint8
+--rw static-bridge-mrouter-interface* if:interface-ref
| {static-mrouter-interface}?
+--rw igmp-version? uint8
+--rw querier-source? inet:ipv4-address
+--rw static-l2-multicast-group* [group source-addr]
| {static-l2-multicast-group}?
| +--rw group
| | rt-types:ipv4-multicast-group-address
| +--rw source-addr
| | rt-types:ipv4-multicast-source-address
| +--rw bridge-outgoing-interface* if:interface-ref
+--ro entries-count? yang:gauge32
+--ro bridge-mrouter-interface* if:interface-ref
+--ro group* [address]
| +--ro address
| | rt-types:ipv4-multicast-group-address
| +--ro mac-address? yang:phys-address
| +--ro expire? rt-types:timer-value-seconds16
| +--ro up-time uint32
| +--ro last-reporter? inet:ipv4-address
| +--ro source* [address]
| +--ro address
| | rt-types:ipv4-multicast-source-address
| +--ro bridge-outgoing-interface* if:interface-ref
| +--ro up-time uint32
| +--ro expire?
| | rt-types:timer-value-seconds16
| +--ro host-count? yang:gauge32
| | {explicit-tracking}?
| +--ro last-reporter? inet:ipv4-address
| +--ro host* [address] {explicit-tracking}?
| +--ro address inet:ipv4-address
| +--ro filter-mode filter-mode-type
+--ro interfaces
+--ro interface* [name]
+--ro name if:interface-ref
+--ro statistics
+--ro discontinuity-time? yang:date-and-time
+--ro received
| +--ro query-count? yang:counter64
| +--ro membership-report-v1-count? yang:counter64
| +--ro membership-report-v2-count? yang:counter64
| +--ro membership-report-v3-count? yang:counter64
| +--ro leave-count? yang:counter64
| +--ro pim-hello-count? yang:counter64
+--ro sent
+--ro query-count? yang:counter64
+--ro membership-report-v1-count? yang:counter64
+--ro membership-report-v2-count? yang:counter64
+--ro membership-report-v3-count? yang:counter64
+--ro leave-count? yang:counter64
+--ro pim-hello-count? yang:counter64
3.2. MLD Snooping Instances
The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control-
plane-protocols/rt:control-plane-protocol to add the mld-snooping-
instance container. The mld-snooping-instance could be used in the
BRIDGE [dot1Qcp] service to enable MLD Snooping.
All the MLD Snooping related attributes have been defined in the mld-
snooping-instance. The read-write attributes represent configurable
data. The read-only attributes represent state data.
The mld-snooping-instance has similar structure as IGMP snooping. Some
of leaves are protocol related. The mld-snooping-instance uses IPv6
addresses and mld-version, while igmp-snooping-instance uses IPv4
addresses and igmp-version. Statistic counters in each of the above
snooping instances are also tailored to the specific protocol type. One
mld-snooping-instance could be used in one BRIDGE instance, and it
corresponds to one BRIDGE instance.
Currently the value of l2-service-type in mld-snooping-instance could
only be set bridge. After it is set, mld-snooping-instance could be used
in the BRIDGE service.
The value of bridge-mrouter-interface is filled by the snooping device
dynamically. It is different from static-bridge-mrouter-interface which
is configured.
The attributes under the interfaces show the statistics of MLD Snooping
related packets.
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--rw mld-snooping-instance {mld-snooping}?
+--rw l2-service-type? l2-service-type
+--rw enable? boolean
+--rw forwarding-table-type? enumeration
+--rw explicit-tracking? boolean
| {explicit-tracking}?
+--rw lite-exclude-filter? empty
| {lite-exclude-filter}?
+--rw send-query? boolean
+--rw fast-leave? empty {fast-leave}?
+--rw last-member-query-interval? uint16
+--rw query-interval? uint16
+--rw query-max-response-time? uint16
+--rw require-router-alert? boolean
| {require-router-alert}?
+--rw robustness-variable? uint8
+--rw static-bridge-mrouter-interface* if:interface-ref
| {static-mrouter-interface}?
+--rw mld-version? uint8
+--rw querier-source? inet:ipv6-address
+--rw static-l2-multicast-group* [group source-addr]
| {static-l2-multicast-group}?
| +--rw group
| | rt-types:ipv6-multicast-group-address
| +--rw source-addr
| | rt-types:ipv6-multicast-source-address
| +--rw bridge-outgoing-interface* if:interface-ref
+--ro entries-count? yang:gauge32
+--ro bridge-mrouter-interface* if:interface-ref
+--ro group* [address]
| +--ro address
| | rt-types:ipv6-multicast-group-address
| +--ro mac-address? yang:phys-address
| +--ro expire? rt-types:timer-value-seconds16
| +--ro up-time uint32
| +--ro last-reporter? inet:ipv6-address
| +--ro source* [address]
| +--ro address
| | rt-types:ipv6-multicast-source-address
| +--ro bridge-outgoing-interface* if:interface-ref
| +--ro up-time uint32
| +--ro expire?
| | rt-types:timer-value-seconds16
| +--ro host-count? yang:gauge32
| | {explicit-tracking}?
| +--ro last-reporter? inet:ipv6-address
| +--ro host* [address] {explicit-tracking}?
| +--ro address inet:ipv6-address
| +--ro filter-mode filter-mode-type
+--ro interfaces
+--ro interface* [name]
+--ro name if:interface-ref
+--ro statistics
+--ro discontinuity-time? yang:date-and-time
+--ro received
| +--ro query-count? yang:counter64
| +--ro report-v1-count? yang:counter64
| +--ro report-v2-count? yang:counter64
| +--ro done-count? yang:counter64
| +--ro pim-hello-count? yang:counter64
+--ro sent
+--ro query-count? yang:counter64
+--ro report-v1-count? yang:counter64
+--ro report-v2-count? yang:counter64
+--ro done-count? yang:counter64
+--ro pim-hello-count? yang:counter64
3.3. Using IGMP and MLD Snooping Instances
The igmp-snooping-instance could be used in the service of BRIDGE
[dot1Qcp] to configure the IGMP Snooping.
For the BRIDGE service this model augments /dot1q:bridges/dot1q:bridge The YANG data model defined in this document conforms to the NMDA
to use igmp-snooping-instance. It means IGMP Snooping is enabled in the [RFC8342]. The operational state data is combined with the
whole bridge. associated configuration data in the same hierarchy [RFC8407].
It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/ 3.1. IGMP Snooping Instances
dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means
IGMP Snooping is enabled in the specified VLAN on the bridge.
The mld-snooping-instance could be used in concurrence with igmp- The YANG module ietf-igmp-mld-snooping augments /rt:routing/
snooping-instance to configure the MLD Snooping. rt:control-plane-protocols/rt:control-plane-protocol to add the igmp-
snooping-instance container.
augment /dot1q:bridges/dot1q:bridge: All the IGMP snooping-related attributes have been defined in the
+--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref igmp-snooping-instance. The read-write attributes represent
+--rw mld-snooping-instance? igmp-mld-snooping-instance-ref configurable data. The read-only attributes represent state data.
augment /dot1q:bridges/dot1q:bridge/dot1q:component One igmp-snooping-instance could be used in one bridge [dot1Qcp]
/dot1q:bridge-vlan/dot1q:vlan: instance, and it corresponds to one bridge instance.
+--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref
+--rw mld-snooping-instance? igmp-mld-snooping-instance-ref
3.4. IGMP and MLD Snooping Actions Currently, the value of l2-service-type in igmp-snooping-instance
could only be set to 'bridge'. After it is set, igmp-snooping-
instance could be used in the bridge service.
IGMP and MLD Snooping actions clear the specified IGMP and MLD Snooping The values of bridge-mrouter-interface are filled by the snooping
group tables. If both source X and group Y are specified, only source X device dynamically. It is different from static-bridge-mrouter-
from group Y in that specific instance will be cleared. interface, which is configured.
augment /rt:routing/rt:control-plane-protocols The attributes under the interfaces show the statistics of IGMP
/rt:control-plane-protocol: snooping-related packets.
+--rw igmp-snooping-instance {igmp-snooping}?
+---x clear-igmp-snooping-groups {action-clear-groups}?
+---w input
+---w group union
+---w source rt-types:ipv4-multicast-source-address
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol: /rt:control-plane-protocol:
+--rw mld-snooping-instance {mld-snooping}? +--rw igmp-snooping-instance {igmp-snooping}?
+---x clear-mld-snooping-groups {action-clear-groups}? +--rw l2-service-type? l2-service-type
+---w input +--rw enabled? boolean
+---w group union +--rw forwarding-table-type? enumeration
+---w source rt-types:ipv6-multicast-source-address +--rw explicit-tracking? boolean
| {explicit-tracking}?
4. IGMP and MLD Snooping YANG Module +--rw lite-exclude-filter? empty
| {lite-exclude-filter}?
This module references [RFC1112],[RFC2236],[RFC2710],[RFC3376], +--rw send-query? boolean
[RFC3810],[RFC4541],[RFC5790],[RFC6636],[RFC6991],[RFC7761], +--rw fast-leave? empty {fast-leave}?
[RFC8343],[dot1Qcp]. +--rw last-member-query-interval? uint16
+--rw query-interval? uint16
<CODE BEGINS> file ietf-igmp-mld-snooping@2021-10-08.yang +--rw query-max-response-time? uint16
module ietf-igmp-mld-snooping { +--rw require-router-alert? boolean
yang-version 1.1; | {require-router-alert}?
namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping"; +--rw robustness-variable? uint8
+--rw static-bridge-mrouter-interface* if:interface-ref
prefix ims; | {static-mrouter-interface}?
+--rw igmp-version? uint8
import ietf-inet-types { +--rw querier-source? inet:ipv4-address
prefix "inet"; +--rw static-l2-multicast-group* [group source-addr]
reference | {static-l2-multicast-group}?
"RFC 6991: Common YANG Data Types"; | +--rw group
} | | rt-types:ipv4-multicast-group-address
| +--rw source-addr
import ietf-yang-types { | | rt-types:ipv4-multicast-source-address
prefix "yang"; | +--rw bridge-outgoing-interface* if:interface-ref
reference +--ro entries-count? yang:gauge32
"RFC 6991: Common YANG Data Types"; +--ro bridge-mrouter-interface* if:interface-ref
} +--ro group* [address]
| +--ro address
import ietf-interfaces { | | rt-types:ipv4-multicast-group-address
prefix "if"; | +--ro mac-address? yang:phys-address
reference | +--ro expire? rt-types:timer-value-seconds16
"RFC 8343: A YANG Data Model for Interface Management"; | +--ro up-time uint32
} | +--ro last-reporter? inet:ipv4-address
| +--ro source* [address]
import ietf-routing { | +--ro address
prefix "rt"; | | rt-types:ipv4-multicast-source-address
reference | +--ro bridge-outgoing-interface* if:interface-ref
"RFC 8349: A YANG Data Model for Routing Management (NMDA | +--ro up-time uint32
Version)"; | +--ro expire?
} | | rt-types:timer-value-seconds16
| +--ro host-count? yang:gauge32
import ietf-routing-types { | | {explicit-tracking}?
prefix "rt-types"; | +--ro last-reporter? inet:ipv4-address
reference | +--ro host* [address] {explicit-tracking}?
"RFC 8294: Common YANG Data Types for the Routing Area"; | +--ro address inet:ipv4-address
} | +--ro filter-mode filter-mode-type
+--ro interfaces
import ieee802-dot1q-bridge { +--ro interface* [name]
prefix "dot1q"; +--ro name if:interface-ref
reference +--ro statistics
"dot1Qcp: IEEE 802.1Qcp-2018 Bridges and Bridged Networks +--ro discontinuity-time? yang:date-and-time
- Amendment: YANG Data Model"; +--ro received
} | +--ro query-count? yang:counter64
| +--ro membership-report-v1-count? yang:counter64
organization | +--ro membership-report-v2-count? yang:counter64
"IETF PIM Working Group"; | +--ro membership-report-v3-count? yang:counter64
| +--ro leave-count? yang:counter64
contact | +--ro pim-hello-count? yang:counter64
"WG Web: <http://tools.ietf.org/wg/pim/> +--ro sent
WG List: <mailto:pim@ietf.org> +--ro query-count? yang:counter64
+--ro membership-report-v1-count? yang:counter64
Editors: Hongji Zhao +--ro membership-report-v2-count? yang:counter64
<mailto:hongji.zhao@ericsson.com> +--ro membership-report-v3-count? yang:counter64
+--ro leave-count? yang:counter64
Xufeng Liu +--ro pim-hello-count? yang:counter64
<mailto:xufeng.liu.ietf@gmail.com>
Yisong Liu
<mailto:liuyisong@chinamobile.com>
Anish Peter
<mailto:anish.ietf@gmail.com>
Mahesh Sivakumar
<mailto:sivakumar.mahesh@gmail.com>
";
description
"The module defines a collection of YANG definitions common for
all devices that implement Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping which is
described in RFC 4541.
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2021-10-08 {
description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for IGMP and MLD Snooping";
}
/*
* Features
*/
feature igmp-snooping {
description
"Support IGMP snooping.";
reference
"RFC 4541";
}
feature mld-snooping {
description
"Support MLD snooping.";
reference
"RFC 4541";
}
feature fast-leave {
description
"Support configuration of fast leave. The fast leave feature
does not send last member query messages to hosts.";
reference
"RFC 3376";
}
feature static-l2-multicast-group {
description
"Support configuration of static L2 multicast group.";
}
feature static-mrouter-interface {
description
"Support multicast router interface explicitly configured
by management";
reference
"RFC 4541";
}
feature action-clear-groups {
description
"Support clearing statistics by action for IGMP & MLD snooping.";
}
feature require-router-alert {
description
"Support configuration of require-router-alert.";
reference
"RFC 3376";
}
feature lite-exclude-filter {
description
"Enable the support of the simplified EXCLUDE filter.";
reference
"RFC 5790";
}
feature explicit-tracking {
description
"Support configuration of per instance explicit-tracking.";
reference
"RFC 6636";
}
/* identities */ 3.2. MLD Snooping Instances
identity l2-service-type {
description
"Base identity for L2 service type in IGMP & MLD snooping";
}
identity bridge { The YANG module ietf-igmp-mld-snooping augments /rt:routing/
base l2-service-type; rt:control-plane-protocols/rt:control-plane-protocol to add the mld-
description snooping-instance container. The mld-snooping-instance could be used
"This identity represents BRIDGE service."; in the bridge [dot1Qcp] service to enable MLD snooping.
}
identity filter-mode { All the MLD snooping-related attributes have been defined in the mld-
description snooping-instance. The read-write attributes represent configurable
"Base identity for filter mode in IGMP & MLD snooping"; data. The read-only attributes represent state data.
}
identity include { The mld-snooping-instance has a similar structure to IGMP snooping.
base filter-mode; Some leaves are protocol related. The mld-snooping-instance uses
description IPv6 addresses and mld-version, while igmp-snooping-instance uses
"This identity represents include mode."; IPv4 addresses and igmp-version. Statistic counters in each of the
} above snooping instances are also tailored to the specific protocol
type. One mld-snooping-instance could be used in one bridge instance
and corresponds to one bridge instance.
identity exclude { Currently, the value of l2-service-type in mld-snooping-instance
base filter-mode; could only be set to 'bridge'. After it is set, mld-snooping-
description instance could be used in the bridge service.
"This identity represents exclude mode.";
}
identity igmp-snooping { The value of bridge-mrouter-interface is filled by the snooping
base rt:control-plane-protocol; device dynamically. It is different from static-bridge-mrouter-
description interface, which is configured.
"IGMP snooping";
}
identity mld-snooping { The attributes under the interfaces show the statistics of MLD
base rt:control-plane-protocol; snooping-related packets.
description
"MLD snooping";
}
/* augment /rt:routing/rt:control-plane-protocols
* Typedefs /rt:control-plane-protocol:
*/ +--rw mld-snooping-instance {mld-snooping}?
+--rw l2-service-type? l2-service-type
+--rw enabled? boolean
+--rw forwarding-table-type? enumeration
+--rw explicit-tracking? boolean
| {explicit-tracking}?
+--rw lite-exclude-filter? empty
| {lite-exclude-filter}?
+--rw send-query? boolean
+--rw fast-leave? empty {fast-leave}?
+--rw last-member-query-interval? uint16
+--rw query-interval? uint16
+--rw query-max-response-time? uint16
+--rw require-router-alert? boolean
| {require-router-alert}?
+--rw robustness-variable? uint8
+--rw static-bridge-mrouter-interface* if:interface-ref
| {static-mrouter-interface}?
+--rw mld-version? uint8
+--rw querier-source? inet:ipv6-address
+--rw static-l2-multicast-group* [group source-addr]
| {static-l2-multicast-group}?
| +--rw group
| | rt-types:ipv6-multicast-group-address
| +--rw source-addr
| | rt-types:ipv6-multicast-source-address
| +--rw bridge-outgoing-interface* if:interface-ref
+--ro entries-count? yang:gauge32
+--ro bridge-mrouter-interface* if:interface-ref
+--ro group* [address]
| +--ro address
| | rt-types:ipv6-multicast-group-address
| +--ro mac-address? yang:phys-address
| +--ro expire? rt-types:timer-value-seconds16
| +--ro up-time uint32
| +--ro last-reporter? inet:ipv6-address
| +--ro source* [address]
| +--ro address
| | rt-types:ipv6-multicast-source-address
| +--ro bridge-outgoing-interface* if:interface-ref
| +--ro up-time uint32
| +--ro expire?
| | rt-types:timer-value-seconds16
| +--ro host-count? yang:gauge32
| | {explicit-tracking}?
| +--ro last-reporter? inet:ipv6-address
| +--ro host* [address] {explicit-tracking}?
| +--ro address inet:ipv6-address
| +--ro filter-mode filter-mode-type
+--ro interfaces
+--ro interface* [name]
+--ro name if:interface-ref
+--ro statistics
+--ro discontinuity-time? yang:date-and-time
+--ro received
| +--ro query-count? yang:counter64
| +--ro report-v1-count? yang:counter64
| +--ro report-v2-count? yang:counter64
| +--ro done-count? yang:counter64
| +--ro pim-hello-count? yang:counter64
+--ro sent
+--ro query-count? yang:counter64
+--ro report-v1-count? yang:counter64
+--ro report-v2-count? yang:counter64
+--ro done-count? yang:counter64
+--ro pim-hello-count? yang:counter64
typedef l2-service-type { 3.3. Using IGMP and MLD Snooping Instances
type identityref {
base "l2-service-type";
}
description "The L2 service type used with IGMP & MLD snooping ";
}
typedef filter-mode-type {
type identityref {
base "filter-mode";
}
description "The host filter mode";
}
typedef igmp-mld-snooping-instance-ref { The igmp-snooping-instance could be used in the service of bridge
type leafref { [dot1Qcp] to configure the IGMP snooping.
path "/rt:routing/rt:control-plane-protocols"+
"/rt:control-plane-protocol/rt:name";
}
description
"This type is used by data models which need to
reference IGMP & MLD snooping instance.";
}
/* For the bridge service, this model augments /dot1q:bridges/
* Groupings dot1q:bridge to use igmp-snooping-instance. It means IGMP snooping
*/ is enabled in the bridge.
grouping instance-config-attributes-igmp-mld-snooping { It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/
description dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means
"IGMP and MLD snooping configuration of each VLAN."; IGMP snooping is enabled in the specified VLAN on the bridge.
leaf enable { The mld-snooping-instance could be used in concurrence with igmp-
type boolean; snooping-instance to configure the MLD snooping.
default false;
description
"Set the value to true to enable IGMP & MLD snooping.";
}
leaf forwarding-table-type { augment /dot1q:bridges/dot1q:bridge:
type enumeration { +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref
enum "mac" { +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref
description
"MAC-based lookup mode";
}
enum "ip" {
description
"IP-based lookup mode";
}
}
default "ip";
description "The default forwarding table type is ip";
}
leaf explicit-tracking { augment /dot1q:bridges/dot1q:bridge/dot1q:component
if-feature explicit-tracking; /dot1q:bridge-vlan/dot1q:vlan:
type boolean; +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref
default false; +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref
description
"Track the IGMPv3 and MLDv2 snooping membership reports
from individual hosts. It contributes to saving network
resources and shortening leave latency.";
}
leaf lite-exclude-filter { 3.4. IGMP and MLD Snooping Actions
if-feature lite-exclude-filter;
type empty;
description
"For IGMP Snooping, the presence of this
leaf enables the support of the simplified EXCLUDE filter
in the Lightweight IGMPv3 protocol, which simplifies the
standard versions of IGMPv3.
For MLD Snooping, the presence of this
leaf enables the support of the simplified EXCLUDE filter
in the Lightweight MLDv2 protocol, which simplifies the
standard versions of MLDv2.";
reference
"RFC 5790";
}
leaf send-query { IGMP and MLD snooping actions clear the specified IGMP and MLD
type boolean; snooping group tables. If both source X and group Y are specified,
default false; only source X from group Y in that specific instance will be cleared.
description
"When it is true, this switch will send out periodic
IGMP General Query Message or MLD General Query Message.";
}
leaf fast-leave { augment /rt:routing/rt:control-plane-protocols
if-feature fast-leave; /rt:control-plane-protocol:
type empty; +--rw igmp-snooping-instance {igmp-snooping}?
description +---x clear-igmp-snooping-groups {action-clear-groups}?
"When immediate leave is enabled, the IGMP software assumes +---w input
that no more than one host is present on each VLAN port."; +---w group union
} +---w source rt-types:ipv4-multicast-source-address
leaf last-member-query-interval { augment /rt:routing/rt:control-plane-protocols
type uint16 { /rt:control-plane-protocol:
range "10..10230"; +--rw mld-snooping-instance {mld-snooping}?
} +---x clear-mld-snooping-groups {action-clear-groups}?
units deciseconds; +---w input
default 10; +---w group union
description +---w source rt-types:ipv6-multicast-source-address
"Last Member Query Interval, which may be tuned to modify
the leave latency of the network.
It is represented in units of 1/10 second.";
reference "RFC 3376. Sec. 8.8.";
}
leaf query-interval {
type uint16;
units seconds;
default 125;
description
"The Query Interval is the interval between General Queries
sent by the Querier.";
reference "RFC 3376. Sec. 4.1.7, 8.2, 8.14.2.";
}
leaf query-max-response-time { 4. IGMP and MLD Snooping YANG Module
type uint16;
units deciseconds;
default 100;
description
"Query maximum response time specifies the maximum time
allowed before sending a responding report.
It is represented in units of 1/10 second.";
reference "RFC 3376. Sec. 4.1.1, 8.3, 8.14.3.";
}
leaf require-router-alert { This module references [RFC1112], [RFC2236], [RFC2710], [RFC3376],
if-feature require-router-alert; [RFC3810], [RFC4541], [RFC5790], [RFC6636], [RFC6991], [RFC7761],
type boolean; [RFC8343], and [dot1Qcp].
default false;
description
"When the value is true, router alert should exist
in the IP header of IGMP or MLD packet. If it doesn't exist,
the IGMP or MLD packet will be ignored.";
reference "RFC 3376. Sec. 9.1, 9.2, 9.3.";
}
leaf robustness-variable { <CODE BEGINS> file "ietf-igmp-mld-snooping@2021-12-20.yang"
type uint8 { module ietf-igmp-mld-snooping {
range "1..7"; yang-version 1.1;
} namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping";
default 2; prefix ims;
description
"Querier's Robustness Variable allows tuning for the
expected packet loss on a network.";
reference "RFC 3376. Sec. 4.1.6, 8.1, 8.14.1.";
}
leaf-list static-bridge-mrouter-interface { import ietf-inet-types {
when 'derived-from-or-self(../l2-service-type,"ims:bridge")'; prefix inet;
if-feature static-mrouter-interface; reference
type if:interface-ref; "RFC 6991: Common YANG Data Types";
description "static mrouter interface in BRIDGE forwarding"; }
} import ietf-yang-types {
} // instance-config-attributes-igmp-mld-snooping prefix yang;
grouping instance-state-group-attributes-igmp-mld-snooping { reference
description "RFC 6991: Common YANG Data Types";
"Attributes for both IGMP and MLD snooping groups."; }
import ietf-interfaces {
prefix if;
reference
"RFC 8343: A YANG Data Model for Interface Management";
}
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management (NMDA
Version)";
}
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ieee802-dot1q-bridge {
prefix dot1q;
reference
"dot1Qcp: IEEE 802.1Qcp-2018 Standard for Local and
Metropolitan area networks--Bridges and Bridged Networks
--Amendment 30: YANG Data Model";
}
leaf mac-address { organization
type yang:phys-address; "IETF PIM Working Group";
description "Destination MAC address for L2 multicast."; contact
} "WG Web: <http://datatracker.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
leaf expire { Editors: Hongji Zhao
type rt-types:timer-value-seconds16; <mailto:hongji.zhao@ericsson.com>
units seconds;
description
"The time left before multicast group timeout.";
}
leaf up-time { Xufeng Liu
type uint32; <mailto:xufeng.liu.ietf@gmail.com>
units seconds;
mandatory true;
description
"The time elapsed since L2 multicast record created.";
}
} // instance-state-group-attributes-igmp-mld-snooping
grouping instance-state-attributes-igmp-mld-snooping { Yisong Liu
<mailto:liuyisong@chinamobile.com>
description Anish Peter
"State attributes for IGMP & MLD snooping instance."; <mailto:anish.ietf@gmail.com>
leaf entries-count { Mahesh Sivakumar
type yang:gauge32; <mailto:sivakumar.mahesh@gmail.com>
config false;
description
"The number of L2 multicast entries in IGMP & MLD snooping";
}
leaf-list bridge-mrouter-interface { ";
when 'derived-from-or-self(../l2-service-type,"ims:bridge")'; description
type if:interface-ref; "The module defines a collection of YANG definitions common for
config false; all devices that implement Internet Group Management Protocol
description (IGMP) and Multicast Listener Discovery (MLD) snooping, which is
"Indicates a list of mrouter interfaces dynamically learned in a described in RFC 4541.
bridge. When this switch receives IGMP/MLD queries from a
multicast router on an interface, the interface will become
mrouter interface for IGMP/MLD snooping.";
}
} // instance-config-attributes-igmp-mld-snooping
grouping instance-state-source-attributes-igmp-mld-snooping { Copyright (c) 2021 IETF Trust and the persons identified as
description authors of the code. All rights reserved.
"State attributes for IGMP & MLD snooping instance.";
leaf-list bridge-outgoing-interface { Redistribution and use in source and binary forms, with or
when 'derived-from-or-self(../../../l2-service- without modification, is permitted pursuant to, and subject to
type,"ims:bridge")'; the license terms contained in, the Simplified BSD License set
type if:interface-ref; forth in Section 4.c of the IETF Trust's Legal Provisions
description "Outgoing interface in BRIDGE forwarding"; Relating to IETF Documents
} (http://trustee.ietf.org/license-info).
leaf up-time { This version of this YANG module is part of RFC 9166; see the
type uint32; RFC itself for full legal notices.";
units seconds;
mandatory true;
description
"The time elapsed since L2 multicast record created";
}
leaf expire { revision 2021-12-20 {
type rt-types:timer-value-seconds16; description
units seconds; "Initial revision.";
description reference
"The time left before multicast group timeout."; "RFC 9166: A YANG Data Model for Internet Group Management
} Protocol (IGMP) and Multicast Listener Discovery (MLD)
Snooping";
}
leaf host-count { /*
if-feature explicit-tracking; * Features
type yang:gauge32; */
description
"The number of host addresses.";
}
} // instance-state-source-attributes-igmp-mld-snooping
grouping igmp-snooping-statistics { feature igmp-snooping {
description description
"The statistics attributes for IGMP snooping."; "Support IGMP snooping.";
reference
"RFC 4541: Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery (MLD)
Snooping Switches";
}
leaf query-count { feature mld-snooping {
type yang:counter64; description
description "Support MLD snooping.";
"The number of Membership Query messages."; reference
reference "RFC 4541: Considerations for Internet Group Management
"RFC 2236"; Protocol (IGMP) and Multicast Listener Discovery (MLD)
} Snooping Switches";
leaf membership-report-v1-count { }
type yang:counter64;
description
"The number of Version 1 Membership Report messages.";
reference
"RFC 1112";
}
leaf membership-report-v2-count {
type yang:counter64;
description
"The number of Version 2 Membership Report messages.";
reference
"RFC 2236";
}
leaf membership-report-v3-count {
type yang:counter64;
description
"The number of Version 3 Membership Report messages.";
reference
"RFC 3376";
}
leaf leave-count {
type yang:counter64;
description
"The number of Leave Group messages.";
reference
"RFC 2236";
}
leaf pim-hello-count {
type yang:counter64;
description
"The number of PIM hello messages.";
reference
"RFC 7761";
}
} // igmp-snooping-statistics
grouping mld-snooping-statistics { feature fast-leave {
description description
"The statistics attributes for MLD snooping."; "Support configuration of fast leave. The fast leave feature
does not send last member query messages to hosts.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3";
}
leaf query-count { feature static-l2-multicast-group {
type yang:counter64; description
description "Support configuration of static L2 multicast group.";
"The number of Multicast Listener Query messages."; }
reference
"RFC 3810";
}
leaf report-v1-count {
type yang:counter64;
description
"The number of Version 1 Multicast Listener Report.";
reference
"RFC 2710";
}
leaf report-v2-count {
type yang:counter64;
description
"The number of Version 2 Multicast Listener Report.";
reference
"RFC 3810";
}
leaf done-count {
type yang:counter64;
description
"The number of Version 1 Multicast Listener Done.";
reference
"RFC 2710";
}
leaf pim-hello-count {
type yang:counter64;
description
"The number of PIM hello messages.";
reference
"RFC 7761";
}
} // mld-snooping-statistics
augment "/rt:routing/rt:control-plane-protocols"+ feature static-mrouter-interface {
"/rt:control-plane-protocol" { description
when 'derived-from-or-self(rt:type, "ims:igmp-snooping")' { "Support multicast router interface explicitly configured
description by management.";
"This container is only valid for IGMP snooping."; reference
} "RFC 4541: Considerations for Internet Group Management
description Protocol (IGMP) and Multicast Listener Discovery (MLD)
"IGMP snooping augmentation to control plane protocol Snooping Switches";
configuration and state."; }
container igmp-snooping-instance { feature action-clear-groups {
if-feature igmp-snooping; description
description "Support clearing statistics by action for IGMP and MLD
"IGMP snooping instance to configure igmp-snooping."; snooping.";
}
leaf l2-service-type { feature require-router-alert {
type l2-service-type; description
default bridge; "Support configuration of require-router-alert.";
description reference
"It indicates BRIDGE or other services."; "RFC 3376: Internet Group Management Protocol, Version 3";
} }
uses instance-config-attributes-igmp-mld-snooping; feature lite-exclude-filter {
description
"Enable the support of the simplified EXCLUDE filter.";
reference
"RFC 5790: Lightweight Internet Group Management Protocol
Version 3 (IGMPv3) and Multicast Listener Discovery Version
2 (MLDv2) Protocols";
}
leaf igmp-version { feature explicit-tracking {
type uint8 { description
range "1..3"; "Support configuration of per-instance explicit-tracking.";
} reference
default 2; "RFC 6636: Tuning the Behavior of the Internet Group Management
description "IGMP version."; Protocol (IGMP) and Multicast Listener Discovery (MLD) for
} Routers in Mobile and Wireless Networks";
leaf querier-source { }
type inet:ipv4-address;
description
"The source address of IGMP General Query message,
which is sent out by this switch.";
}
list static-l2-multicast-group { /* identities */
if-feature static-l2-multicast-group;
key "group source-addr";
description
"A static multicast route, (*,G) or (S,G).";
leaf group { identity l2-service-type {
type rt-types:ipv4-multicast-group-address; description
description "Base identity for L2 service type in IGMP and MLD snooping.";
"Multicast group IPv4 address"; }
}
leaf source-addr { identity bridge {
type rt-types:ipv4-multicast-source-address; base l2-service-type;
description description
"Multicast source IPv4 address."; "This identity represents bridge service.";
} }
leaf-list bridge-outgoing-interface { identity filter-mode {
when 'derived-from-or-self(../../l2-service- description
type,"ims:bridge")'; "Base identity for filter mode in IGMP and MLD snooping.";
type if:interface-ref; }
description "Outgoing interface in BRIDGE forwarding";
}
} // static-l2-multicast-group
uses instance-state-attributes-igmp-mld-snooping; identity include {
base filter-mode;
description
"This identity represents include mode.";
}
list group { identity exclude {
base filter-mode;
description
"This identity represents exclude mode.";
}
key "address"; identity igmp-snooping {
base rt:control-plane-protocol;
description
"IGMP snooping.";
}
config false; identity mld-snooping {
base rt:control-plane-protocol;
description
"MLD snooping.";
}
description "IGMP snooping information"; /*
* Typedefs
*/
leaf address { typedef l2-service-type {
type rt-types:ipv4-multicast-group-address; type identityref {
description base l2-service-type;
"Multicast group IPv4 address"; }
} description
"The L2 service type used with IGMP and MLD
snooping.";
}
uses instance-state-group-attributes-igmp-mld-snooping; typedef filter-mode-type {
leaf last-reporter { type identityref {
type inet:ipv4-address; base filter-mode;
description }
"Address of the last host which has sent report to join description
the multicast group."; "The host filter mode.";
} }
list source { typedef igmp-mld-snooping-instance-ref {
key "address"; type leafref {
description "Source IPv4 address for multicast stream"; path "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:name";
}
description
"This type is used by data models that need to
reference IGMP or MLD snooping instance.";
}
leaf address { /*
type rt-types:ipv4-multicast-source-address; * Groupings
description "Source IPv4 address for multicast stream"; */
}
uses instance-state-source-attributes-igmp-mld-snooping; grouping instance-config-attributes-igmp-mld-snooping {
description
"IGMP and MLD snooping configuration of each VLAN.";
leaf enabled {
type boolean;
default "false";
description
"Set the value to true to enable IGMP and MLD snooping.";
}
leaf forwarding-table-type {
type enumeration {
enum mac {
description
"MAC-based lookup mode.";
}
enum ip {
description
"IP-based lookup mode.";
}
}
default "ip";
description
"The default forwarding table type is ip.";
}
leaf explicit-tracking {
if-feature "explicit-tracking";
type boolean;
default "false";
description
"Track the IGMPv3 and MLDv2 snooping membership reports
from individual hosts. It contributes to saving network
resources and shortening leave latency.";
}
leaf lite-exclude-filter {
if-feature "lite-exclude-filter";
type empty;
description
"For IGMP snooping, the presence of this
leaf enables the support of the simplified EXCLUDE filter
in the Lightweight IGMPv3 protocol, which simplifies the
standard versions of IGMPv3.
For MLD Snooping, the presence of this
leaf enables the support of the simplified EXCLUDE filter
in the Lightweight MLDv2 protocol, which simplifies the
standard versions of MLDv2.";
reference
"RFC 5790: Lightweight Internet Group Management Protocol
Version 3 (IGMPv3) and Multicast Listener Discovery Version
2 (MLDv2) Protocols";
}
leaf send-query {
type boolean;
default "false";
description
"When it is true, this switch will send out a periodic IGMP
General Query Message or MLD General Query Message.";
}
leaf fast-leave {
if-feature "fast-leave";
type empty;
description
"When fast leave is enabled, the software assumes
that no more than one host is present on each VLAN port.";
}
leaf last-member-query-interval {
type uint16 {
range "10..10230";
}
units "deciseconds";
default "10";
description
"Last Member Query Interval, which may be tuned to modify
the leave latency of the network.
It is represented in units of 1/10 second.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3,
Section 8.8";
}
leaf query-interval {
type uint16;
units "seconds";
default "125";
description
"The Query Interval is the interval between General Queries
sent by the Querier.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3,
Sections 4.1.7, 8.2, and 8.14.2";
}
leaf query-max-response-time {
type uint16;
units "deciseconds";
default "100";
description
"Query maximum response time specifies the maximum time
allowed before sending a responding report.
It is represented in units of 1/10 second.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3,
Sections 4.1.1, 8.3, and 8.14.3";
}
leaf require-router-alert {
if-feature "require-router-alert";
type boolean;
default "false";
description
"When the value is true, a router alert should exist
in the IP header of the IGMP or MLD packet. If it
doesn't exist, the IGMP or MLD packet will be ignored.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3,
Sections 9.1, 9.2, and 9.3";
}
leaf robustness-variable {
type uint8 {
range "1..7";
}
default "2";
description
"Querier's Robustness Variable allows tuning for the
expected packet loss on a network.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3,
Sections 4.1.6, 8.1, and 8.14.1";
}
leaf-list static-bridge-mrouter-interface {
when 'derived-from-or-self(../l2-service-type,"ims:bridge")';
if-feature "static-mrouter-interface";
type if:interface-ref;
description
"Static mrouter interface in bridge forwarding";
}
} // instance-config-attributes-igmp-mld-snooping
leaf last-reporter { grouping instance-state-group-attributes-igmp-mld-snooping {
type inet:ipv4-address; description
description "Attributes for both IGMP and MLD snooping groups.";
"Address of the last host which has sent report leaf mac-address {
to join the multicast group."; type yang:phys-address;
} description
"Destination MAC address for L2 multicast.";
}
leaf expire {
type rt-types:timer-value-seconds16;
units "seconds";
description
"The time left before multicast group timeout.";
}
leaf up-time {
type uint32;
units "seconds";
mandatory true;
description
"The time elapsed since the L2 multicast record was
created.";
}
} // instance-state-group-attributes-igmp-mld-snooping
list host { grouping instance-state-attributes-igmp-mld-snooping {
if-feature explicit-tracking; description
key "address"; "State attributes for IGMP or MLD snooping instance.";
description leaf entries-count {
"List of multicast membership hosts type yang:gauge32;
of the specific multicast source-group."; config false;
description
"The number of L2 multicast entries in IGMP and MLD
snooping.";
}
leaf-list bridge-mrouter-interface {
when 'derived-from-or-self(../l2-service-type,"ims:bridge")';
type if:interface-ref;
config false;
description
"Indicates a list of mrouter interfaces dynamically learned
in a bridge. When this switch receives IGMP/MLD queries
from a multicast router on an interface, the interface will
become an mrouter interface for IGMP/MLD snooping.";
}
} // instance-config-attributes-igmp-mld-snooping
leaf address { grouping instance-state-source-attributes-igmp-mld-snooping {
type inet:ipv4-address; description
description "State attributes for IGMP or MLD snooping instance.";
"Multicast membership host address."; leaf-list bridge-outgoing-interface {
} when 'derived-from-or-self(../../../l2-service-type,
leaf filter-mode { "ims:bridge")';
type filter-mode-type; type if:interface-ref;
mandatory true; description
description "Outgoing interface in bridge forwarding.";
"Filter mode for a multicast membership }
host may be either include or exclude."; leaf up-time {
} type uint32;
}// list host units "seconds";
} // list source mandatory true;
} // list group description
"The time elapsed since L2 multicast record was created.";
}
leaf expire {
type rt-types:timer-value-seconds16;
units "seconds";
description
"The time left before multicast group timeout.";
}
leaf host-count {
if-feature "explicit-tracking";
type yang:gauge32;
description
"The number of host addresses.";
}
} // instance-state-source-attributes-igmp-mld-snooping
container interfaces { grouping igmp-snooping-statistics {
config false; description
"The statistics attributes for IGMP snooping.";
leaf query-count {
type yang:counter64;
description description
"Contains the interfaces associated with the IGMP snooping "The number of Membership Query messages.";
instance"; reference
"RFC 2236: Internet Group Management Protocol, Version 2";
}
leaf membership-report-v1-count {
type yang:counter64;
description
"The number of Version 1 Membership Report messages.";
reference
"RFC 1112: Host extensions for IP multicasting";
}
leaf membership-report-v2-count {
type yang:counter64;
description
"The number of Version 2 Membership Report messages.";
reference
"RFC 2236: Internet Group Management Protocol, Version 2";
}
leaf membership-report-v3-count {
type yang:counter64;
description
"The number of Version 3 Membership Report messages.";
reference
"RFC 3376: Internet Group Management Protocol, Version 3";
}
leaf leave-count {
type yang:counter64;
description
"The number of Leave Group messages.";
reference
"RFC 2236: Internet Group Management Protocol, Version 2";
}
leaf pim-hello-count {
type yang:counter64;
description
"The number of PIM hello messages.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification (Revised)";
}
} // igmp-snooping-statistics
list interface { grouping mld-snooping-statistics {
key "name"; description
"The statistics attributes for MLD snooping.";
leaf query-count {
type yang:counter64;
description
"The number of Multicast Listener Query messages.";
reference
"RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
for IPv6";
}
leaf report-v1-count {
type yang:counter64;
description
"The number of Version 1 Multicast Listener Report.";
reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6";
}
leaf report-v2-count {
type yang:counter64;
description
"The number of Version 2 Multicast Listener Report.";
reference
"RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
for IPv6";
}
leaf done-count {
type yang:counter64;
description
"The number of Version 1 Multicast Listener Done.";
reference
"RFC 2710: Multicast Listener Discovery (MLD) for IPv6";
}
leaf pim-hello-count {
type yang:counter64;
description
"The number of PIM hello messages.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification (Revised)";
}
} // mld-snooping-statistics
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol" {
when 'derived-from-or-self(rt:type, "ims:igmp-snooping")' {
description
"This container is only valid for IGMP snooping.";
}
description
"IGMP snooping augmentation to control-plane protocol
configuration and state.";
container igmp-snooping-instance {
if-feature "igmp-snooping";
description
"IGMP snooping instance to configure igmp-snooping.";
leaf l2-service-type {
type l2-service-type;
default "bridge";
description description
"A list of interfaces associated with the IGMP snooping "It indicates bridge or other services.";
instance"; }
uses instance-config-attributes-igmp-mld-snooping;
leaf name { leaf igmp-version {
type uint8 {
range "1..3";
}
default "2";
description
"IGMP version.";
}
leaf querier-source {
type inet:ipv4-address;
description
"The source address of the IGMP General Query message,
which is sent out by this switch.";
}
list static-l2-multicast-group {
if-feature "static-l2-multicast-group";
key "group source-addr";
description
"A static multicast route, (*,G) or (S,G).";
leaf group {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.";
}
leaf source-addr {
type rt-types:ipv4-multicast-source-address;
description
"Multicast source IPv4 address.";
}
leaf-list bridge-outgoing-interface {
when 'derived-from-or-self(../../l2-service-type,
"ims:bridge")';
type if:interface-ref; type if:interface-ref;
description description
"The name of interface"; "Outgoing interface in bridge forwarding.";
} }
} // static-l2-multicast-group
container statistics { uses instance-state-attributes-igmp-mld-snooping;
list group {
key "address";
config false;
description
"IGMP snooping information.";
leaf address {
type rt-types:ipv4-multicast-group-address;
description description
"The interface statistics for IGMP snooping"; "Multicast group IPv4 address.";
}
leaf discontinuity-time { uses instance-state-group-attributes-igmp-mld-snooping;
type yang:date-and-time; leaf last-reporter {
type inet:ipv4-address;
description
"Address of the last host that has sent a report to join
the multicast group.";
}
list source {
key "address";
description
"Source IPv4 address for multicast stream.";
leaf address {
type rt-types:ipv4-multicast-source-address;
description description
"The time on the most recent occasion at which any one "Source IPv4 address for multicast stream.";
or more of the statistic counters suffered a
discontinuity. If no such discontinuities have
occurred since the last re-initialization of the local
management subsystem, then this node contains the time
the local management subsystem re-initialized
itself.";
} }
container received { uses instance-state-source-attributes-igmp-mld-snooping;
leaf last-reporter {
type inet:ipv4-address;
description description
"Number of received snooped IGMP packets"; "Address of the last host that has sent a report
to join the multicast group.";
uses igmp-snooping-statistics;
} }
container sent { list host {
if-feature "explicit-tracking";
key "address";
description description
"Number of sent snooped IGMP packets"; "List of multicast membership hosts
of the specific multicast source group.";
uses igmp-snooping-statistics; leaf address {
type inet:ipv4-address;
description
"Multicast membership host address.";
}
leaf filter-mode {
type filter-mode-type;
mandatory true;
description
"Filter mode for a multicast membership
host may be either include or exclude.";
}
} // list host
} // list source
} // list group
container interfaces {
config false;
description
"Contains the interfaces associated with the IGMP snooping
instance.";
list interface {
key "name";
description
"A list of interfaces associated with the IGMP snooping
instance.";
leaf name {
type if:interface-ref;
description
"The name of the interface.";
}
container statistics {
description
"The interface statistics for IGMP snooping.";
leaf discontinuity-time {
type yang:date-and-time;
description
"The time on the most recent occasion at which any
one or more of the statistic counters suffered a
discontinuity. If no such discontinuities have
occurred since the last re-initialization of the
local management subsystem, then this node contains
the time the local management subsystem
re-initialized itself.";
}
container received {
description
"Number of received snooped IGMP packets.";
uses igmp-snooping-statistics;
}
container sent {
description
"Number of sent snooped IGMP packets.";
uses igmp-snooping-statistics;
}
} }
} }
} }
} action clear-igmp-snooping-groups {
if-feature "action-clear-groups";
action clear-igmp-snooping-groups {
if-feature action-clear-groups;
description
"Clear IGMP snooping cache tables.";
input {
leaf group {
type union {
type enumeration {
enum 'all-groups' {
description
"All multicast group addresses.";
}
}
type rt-types:ipv4-multicast-group-address;
}
mandatory true;
description
"Multicast group IPv4 address. If value 'all-groups' is
specified, all IGMP snooping group entries are cleared
for specified source address.";
}
leaf source {
type rt-types:ipv4-multicast-source-address;
mandatory true;
description
"Multicast source IPv4 address. If value '*' is specified,
all IGMP snooping source-group tables are cleared.";
}
}
} // action clear-igmp-snooping-groups
} // igmp-snooping-instance
} // augment
augment "/rt:routing/rt:control-plane-protocols"+
"/rt:control-plane-protocol" {
when 'derived-from-or-self(rt:type, "ims:mld-snooping")' {
description
"This container is only valid for MLD snooping.";
}
description
"MLD snooping augmentation to control plane protocol
configuration and state.";
container mld-snooping-instance {
if-feature mld-snooping;
description
"MLD snooping instance to configure mld-snooping.";
leaf l2-service-type {
type l2-service-type;
default bridge;
description
"It indicates BRIDGE or other services.";
}
uses instance-config-attributes-igmp-mld-snooping;
leaf mld-version {
type uint8 {
range "1..2";
}
default 2;
description "MLD version.";
}
leaf querier-source {
type inet:ipv6-address;
description
"The source address of MLD General Query message,
which is sent out by this switch.";
}
list static-l2-multicast-group {
if-feature static-l2-multicast-group;
key "group source-addr";
description
"A static multicast route, (*,G) or (S,G).";
leaf group {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
leaf-list bridge-outgoing-interface {
when 'derived-from-or-self(../../l2-service-
type,"ims:bridge")';
type if:interface-ref;
description "Outgoing interface in BRIDGE forwarding";
}
} // static-l2-multicast-group
uses instance-state-attributes-igmp-mld-snooping;
list group {
key "address";
config false;
description "MLD snooping statistics information";
leaf address {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address";
}
uses instance-state-group-attributes-igmp-mld-snooping;
leaf last-reporter {
type inet:ipv6-address;
description
"Address of the last host which has sent report
to join the multicast group.";
}
list source {
key "address";
description "Source IPv6 address for multicast stream";
leaf address {
type rt-types:ipv6-multicast-source-address;
description "Source IPv6 address for multicast stream";
}
uses instance-state-source-attributes-igmp-mld-snooping;
leaf last-reporter {
type inet:ipv6-address;
description description
"Address of the last host which has sent report "Clear IGMP snooping cache tables.";
to join the multicast group."; input {
} leaf group {
type union {
list host { type enumeration {
if-feature explicit-tracking; enum all-groups {
key "address"; description
description "All multicast group addresses.";
"List of multicast membership hosts }
of the specific multicast source-group."; }
type rt-types:ipv4-multicast-group-address;
leaf address { }
type inet:ipv6-address; mandatory true;
description description
"Multicast membership host address."; "Multicast group IPv4 address. If value
} 'all-groups' is specified, all IGMP snooping
leaf filter-mode { group entries are cleared for the specified source
type filter-mode-type; address.";
mandatory true; }
description leaf source {
"Filter mode for a multicast membership type rt-types:ipv4-multicast-source-address;
host may be either include or exclude."; mandatory true;
} description
}// list host "Multicast source IPv4 address. If value '*' is
} // list source specified, all IGMP snooping source-group tables
} // list group are cleared.";
}
container interfaces { }
config false; } // action clear-igmp-snooping-groups
} // igmp-snooping-instance
} // augment
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol" {
when 'derived-from-or-self(rt:type, "ims:mld-snooping")' {
description description
"Contains the interfaces associated with the MLD snooping "This container is only valid for MLD snooping.";
instance"; }
description
list interface { "MLD snooping augmentation to control-plane protocol
key "name"; configuration and state.";
container mld-snooping-instance {
if-feature "mld-snooping";
description
"MLD snooping instance to configure mld-snooping.";
leaf l2-service-type {
type l2-service-type;
default "bridge";
description description
"A list of interfaces associated with the MLD snooping "It indicates bridge or other services.";
instance"; }
uses instance-config-attributes-igmp-mld-snooping;
leaf name { leaf mld-version {
type uint8 {
range "1..2";
}
default "2";
description
"MLD version.";
}
leaf querier-source {
type inet:ipv6-address;
description
"The source address of MLD General Query message, which
is sent out by this switch.";
}
list static-l2-multicast-group {
if-feature "static-l2-multicast-group";
key "group source-addr";
description
"A static multicast route, (*,G) or (S,G).";
leaf group {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.";
}
leaf source-addr {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.";
}
leaf-list bridge-outgoing-interface {
when 'derived-from-or-self(../../l2-service-type,
"ims:bridge")';
type if:interface-ref; type if:interface-ref;
description description
"The name of interface"; "Outgoing interface in bridge forwarding.";
} }
} // static-l2-multicast-group
container statistics { uses instance-state-attributes-igmp-mld-snooping;
list group {
key "address";
config false;
description
"MLD snooping statistics information.";
leaf address {
type rt-types:ipv6-multicast-group-address;
description description
"The interface statistics for MLD snooping"; "Multicast group IPv6 address.";
}
leaf discontinuity-time { uses instance-state-group-attributes-igmp-mld-snooping;
type yang:date-and-time; leaf last-reporter {
type inet:ipv6-address;
description
"Address of the last host that has sent report
to join the multicast group.";
}
list source {
key "address";
description
"Source IPv6 address for multicast stream.";
leaf address {
type rt-types:ipv6-multicast-source-address;
description description
"The time on the most recent occasion at which any one "Source IPv6 address for multicast stream.";
or more of the statistic counters suffered a
discontinuity. If no such discontinuities have
occurred since the last re-initialization of the local
management subsystem, then this node contains the time
the local management subsystem re-initialized
itself.";
} }
container received { uses instance-state-source-attributes-igmp-mld-snooping;
leaf last-reporter {
type inet:ipv6-address;
description description
"Number of received snooped MLD packets"; "Address of the last host that has sent report
to join the multicast group.";
uses mld-snooping-statistics;
} }
container sent { list host {
if-feature "explicit-tracking";
key "address";
description description
"Number of sent snooped MLD packets"; "List of multicast membership hosts
of the specific multicast source group.";
uses mld-snooping-statistics; leaf address {
type inet:ipv6-address;
description
"Multicast membership host address.";
}
leaf filter-mode {
type filter-mode-type;
mandatory true;
description
"Filter mode for a multicast membership
host may be either include or exclude.";
}
} // list host
} // list source
} // list group
container interfaces {
config false;
description
"Contains the interfaces associated with the MLD snooping
instance.";
list interface {
key "name";
description
"A list of interfaces associated with the MLD snooping
instance.";
leaf name {
type if:interface-ref;
description
"The name of the interface.";
}
container statistics {
description
"The interface statistics for MLD snooping.";
leaf discontinuity-time {
type yang:date-and-time;
description
"The time on the most recent occasion at which
any one or more of the statistic counters suffered
a discontinuity. If no such discontinuities have
occurred since the last re-initialization of the
local management subsystem, then this node contains
the time the local management subsystem
re-initialized itself.";
}
container received {
description
"Number of received snooped MLD packets.";
uses mld-snooping-statistics;
}
container sent {
description
"Number of sent snooped MLD packets.";
uses mld-snooping-statistics;
}
} }
} }
} }
} action clear-mld-snooping-groups {
if-feature "action-clear-groups";
action clear-mld-snooping-groups { description
if-feature action-clear-groups; "Clear MLD snooping cache tables.";
description input {
"Clear MLD snooping cache tables."; leaf group {
type union {
input { type enumeration {
leaf group { enum all-groups {
type union { description
type enumeration { "All multicast group addresses.";
enum 'all-groups' { }
description }
"All multicast group addresses."; type rt-types:ipv6-multicast-group-address;
} }
} mandatory true;
type rt-types:ipv6-multicast-group-address; description
} "Multicast group IPv6 address. If value 'all-groups'
mandatory true; is specified, all MLD snooping group entries are
description cleared for the specified source address.";
"Multicast group IPv6 address. If value 'all-groups' is }
specified, all MLD snooping group entries are cleared leaf source {
for specified source address."; type rt-types:ipv6-multicast-source-address;
} mandatory true;
leaf source { description
type rt-types:ipv6-multicast-source-address; "Multicast source IPv6 address. If value '*' is
mandatory true; specified, all MLD snooping source-group tables
description are cleared.";
"Multicast source IPv6 address. If value '*' is specified, }
all MLD snooping source-group tables are cleared."; }
} } // action clear-mld-snooping-groups
} } // mld-snooping-instance
} // action clear-mld-snooping-groups } // augment
}// mld-snooping-instance
} // augment
augment "/dot1q:bridges/dot1q:bridge" {
description
"Use IGMP & MLD snooping instance in BRIDGE.";
leaf igmp-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure IGMP snooping instance under bridge view";
}
leaf mld-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure MLD snooping instance under bridge view";
}
}
augment "/dot1q:bridges/dot1q:bridge"+ augment "/dot1q:bridges/dot1q:bridge" {
"/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" { description
description "Use IGMP or MLD snooping instance in bridge.";
"Use IGMP & MLD snooping instance in certain VLAN of BRIDGE"; leaf igmp-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure IGMP snooping instance under bridge view.";
}
leaf mld-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure MLD snooping instance under bridge view.";
}
}
leaf igmp-snooping-instance { augment "/dot1q:bridges/dot1q:bridge"
type igmp-mld-snooping-instance-ref; + "/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" {
description description
"Configure IGMP snooping instance under VLAN view"; "Use IGMP or MLD snooping instance in a certain VLAN
} of bridge.";
leaf igmp-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure IGMP snooping instance under VLAN view.";
}
leaf mld-snooping-instance {
type igmp-mld-snooping-instance-ref;
description
"Configure MLD snooping instance under VLAN view.";
}
}
}
<CODE ENDS>
leaf mld-snooping-instance { 5. Security Considerations
type igmp-mld-snooping-instance-ref;
description
"Configure MLD snooping instance under VLAN view";
}
}
}
<CODE ENDS>
5. Security Considerations The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The YANG module specified in this document defines a schema for data The Network Configuration Access Control Model (NACM) [RFC8341]
that is designed to be accessed via network management protocols such as provides the means to restrict access for particular NETCONF or
NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the RESTCONF users to a preconfigured subset of all available NETCONF or
secure transport layer, and the mandatory-to-implement secure transport RESTCONF protocol operations and content.
is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and
the mandatory-to-implement secure transport is TLS [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] provides There are a number of data nodes defined in this YANG module that are
the means to restrict access for particular NETCONF or RESTCONF users to writable/creatable/deletable (i.e., config true, which is the
a preconfigured subset of all available NETCONF or RESTCONF protocol default). These data nodes may be considered sensitive or vulnerable
operations and content. in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
There are a number of data nodes defined in this YANG module that are Under /rt:routing/rt:control-plane-protocols/rt:control-plane-
writable/creatable/deletable (i.e., config true, which is the default). protocol:/
These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their
sensitivity/vulnerability:
Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance
ims:igmp-snooping-instance ims:mld-snooping-instance
ims:mld-snooping-instance The subtrees under /dot1q:bridges/dot1q:bridge
The subtrees under /dot1q:bridges/dot1q:bridge ims:igmp-snooping-instance
ims:igmp-snooping-instance ims:mld-snooping-instance
ims:mld-snooping-instance The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component/
dot1q:bridge-vlan/dot1q:vlan
The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component ims:igmp-snooping-instance
/dot1q:bridge-vlan/dot1q:vlan
ims:igmp-snooping-instance ims:mld-snooping-instance
ims:mld-snooping-instance Unauthorized access to any data node of these subtrees can adversely
affect the IGMP and MLD snooping subsystem of both the local device
and the network. This may lead to network malfunctions, delivery of
packets to inappropriate destinations, and other problems.
Unauthorized access to any data node of these subtrees can adversely Some of the readable data nodes in this YANG module may be considered
affect the IGMP & MLD Snooping subsystem of both the local device and sensitive or vulnerable in some network environments. It is thus
the network. This may lead to network malfunctions, delivery of packets important to control read access (e.g., via get, get-config, or
to inappropriate destinations, and other problems. notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
Some of the readable data nodes in this YANG module may be considered Under /rt:routing/rt:control-plane-protocols/rt:control-plane-
sensitive or vulnerable in some network environments. It is thus protocol:/
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability:
Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance
ims:igmp-snooping-instance ims:mld-snooping-instance
ims:mld-snooping-instance Unauthorized access to any data node of these subtrees can disclose
the operational state information of IGMP and MLD snooping on this
device. The group/source/host information may expose multicast group
memberships and, transitively, the associations between the user on
the host and the contents from the source, which could be privately
sensitive. Some of the action operations in this YANG module may be
considered sensitive or vulnerable in some network environments. It
is thus important to control access to these operations. These are
the operations and their sensitivity/vulnerability:
Unauthorized access to any data node of these subtrees can disclose the Under /rt:routing/rt:control-plane-protocols/rt:control-plane-
operational state information of IGMP & MLD Snooping on this device. The protocol:/
group/source/host information may expose multicast group memberships,
and transitively the associations between the user on the host and the
contents from the source which could be privately sensitive. Some of the
action operations in this YANG module may be considered sensitive or
vulnerable in some network environments. It is thus important to control
access to these operations. These are the operations and their
sensitivity/vulnerability:
Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ ims:igmp-snooping-instance/ims:clear-igmp-snooping-groups
ims:igmp-snooping-instance/ims:clear-igmp-snooping-groups ims:mld-snooping-instance/ims:clear-mld-snooping-groups
ims:mld-snooping-instance/ims:clear-mld-snooping-groups Some of the actions in this YANG module may be considered sensitive
Some of the actions in this YANG module may be considered sensitive or or vulnerable in some network environments. The IGMP and MLD
vulnerable in some network environments. The IGMP & MLD Snooping YANG snooping YANG module supports the "clear-igmp-snooping-groups" and
module supports the "clear-igmp-snooping-groups" and "clear-mld- "clear-mld-snooping-groups" actions. If unauthorized action is
snooping-groups" actions. If unauthorized action is invoked, the IGMP invoked, the IGMP and MLD snooping group tables will be cleared
and MLD Snooping group tables will be cleared unexpectedly. Especially unexpectedly. Especially when using wildcard, all the multicast
when using wildcard, all the multicast traffic will be flooded in the traffic will be flooded in the broadcast domain. The devices that
broadcast domain. The devices that use this YANG module should heed the use this YANG module should heed the security considerations in
Security Considerations in [RFC4541]. [RFC4541].
6. IANA Considerations 6. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 6.1. XML Registry
actual RFC number (and remove this note).
6.1. XML Registry This document registers the following namespace URI in the "IETF XML
Registry" [RFC3688]:
This document registers the following namespace URIs in the IETF XML URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
Registrant Contact: The IETF.
XML: N/A; the requested URI is an XML namespace.
registry [RFC3688]: 6.2. YANG Module Names Registry
URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping This document registers the following YANG module in the "YANG Module
Registrant Contact: The IETF. Names" registry [RFC7950]:
XML: N/A, the requested URI is an XML namespace.
6.2. YANG Module Names Registry Name: ietf-igmp-mld-snooping
Namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
Prefix: ims
Reference: RFC 9166
This document registers the following YANG modules in the YANG Module 7. References
Names registry [RFC7950]:
name: ietf-igmp-mld-snooping
namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
prefix: ims
reference: RFC XXXX
7. References
7.1. Normative References 7.1. Normative References
[dot1Qcp] IEEE, "Standard for Local and metropolitan area networks-- [dot1Qcp] IEEE, "Standard for Local and metropolitan area networks--
Bridges and Bridged Networks--Amendment 30: YANG Data Bridges and Bridged Networks--Amendment 30: YANG Data
Model", IEEE Std 802.1Qcp-2018 (Revision of IEEE Std Model", IEEE Std 802.1Qcp-2018,
802.1Q-2014), September 2018, DOI 10.1109/IEEESTD.2018.8467507, September 2018,
<https://ieeexplore.ieee.org/servlet/opac?punumber=8467505> <https://ieeexplore.ieee.org/servlet/
opac?punumber=8467505>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
RFC 2236, November 1997. 2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<https://www.rfc-editor.org/info/rfc2236>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2004. DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4286] B. Haberman and J. Martin, "Multicast Router Discovery", [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, DOI 10.17487/RFC4286, December 2005,
<https://www.rfc-editor.org/info/rfc4286>.
[RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
for Internet Group Management Protocol (IGMP) and Multicast "Considerations for Internet Group Management Protocol
Listener Discovery (MLD) Snooping Switches", RFC 4541, May (IGMP) and Multicast Listener Discovery (MLD) Snooping
2006. Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC5790] H. Liu, W. Cao, H. Asaeda, "Lightweight Internet Group [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010. DOI 10.17487/RFC5790, February 2010,
<https://www.rfc-editor.org/info/rfc5790>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Bierman, Ed., "Network Configuration Protocol (NETCONF)", and A. Bierman, Ed., "Network Configuration Protocol
RFC 6241, June 2011. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6636] H. Asaeda, H. Liu, Q. Wu, "Tuning the Behavior of the [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
Internet Group Management Protocol (IGMP) and Multicast the Internet Group Management Protocol (IGMP) and
Listener Discovery (MLD) for Routers in Mobile and Wireless Multicast Listener Discovery (MLD) for Routers in Mobile
Networks", RFC 6636, May 2012. and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636,
May 2012, <https://www.rfc-editor.org/info/rfc6636>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
July 2013. RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Z. Zhang, L. Zheng, "Protocol Independent Multicast - Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Sparse Mode (PIM-SM): Protocol Specification (Revised)", Multicast - Sparse Mode (PIM-SM): Protocol Specification
RFC 7761, March 2016. (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016. RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
RFC 8040, January 2017. Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
Data Types for the Routing Area", RFC 8294, December 2017. "Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
[RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
8340, March 2018. BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Control Model", RFC 8341, March 2018. Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
Datastore Architecture (NMDA)", RFC 8342, March 2018. and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
RFC 8343, March 2018. Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Management (NMDA Version)", RFC 8349, March 2018. Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
7.2. Informative References 7.2. Informative References
[RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
7951, August 2016. RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", RFC 8407, October Documents Containing YANG Data Models", BCP 216, RFC 8407,
2018. DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A.
YANG Data Model for the Internet Group Management Protocol Peter, "A YANG Data Model for the Internet Group
(IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, Management Protocol (IGMP) and Multicast Listener
November 2019. Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November
2019, <https://www.rfc-editor.org/info/rfc8652>.
Appendix A. Data Tree Example Appendix A. Data Tree Example
This section contains an example for bridge service in the JSON encoding This section contains an example of bridge service in the JSON
[RFC7951], containing both configuration and state data. encoding [RFC7951], containing both configuration and state data.
+-----------+ +-----------+
+ Source + + Source +
+-----+-----+ +-----+-----+
| |
-----------------+---------------------------- -----------------+----------------------------
|eth1/1 |eth1/1
+---+---+ +---+---+
+ R1 + + R1 +
+-+---+-+ +-+---+-+
skipping to change at page 36, line 42 skipping to change at line 1752
+---+---+ +--+---+ +---+---+ +--+---+
eth2/2 | | eth3/2 eth2/2 | | eth3/2
| | | |
---------------+----------+------------------- ---------------+----------+-------------------
| | | |
| | | |
+--------+--+ +---+--------+ +--------+--+ +---+--------+
+ Receiver1 + + Receiver2 + + Receiver1 + + Receiver2 +
+-----------+ +------------+ +-----------+ +------------+
The configuration data for R1 in the above figure could be as follows: The configuration data for R1 in the above figure could be as
follows:
{
"ietf-interfaces:interfaces":{
"interface":[
{ {
"name":"eth1/1", "ietf-interfaces:interfaces":{
"type":"iana-if-type:ethernetCsmacd" "interface":[
} {
] "name":"eth1/1",
"type":"iana-if-type:ethernetCsmacd"
}, }
"ietf-routing:routing":{ ]
"control-plane-protocols":{ },
"control-plane-protocol":[ "ietf-routing:routing":{
{ "control-plane-protocols":{
"type":"ietf-igmp-mld-snooping:igmp-snooping", "control-plane-protocol":[
"name":"bis1", {
"ietf-igmp-mld-snooping:igmp-snooping-instance":{ "type":"ietf-igmp-mld-snooping:igmp-snooping",
"l2-service-type":"ietf-igmp-mld-snooping:bridge", "name":"bis1",
"enable":true "ietf-igmp-mld-snooping:igmp-snooping-instance":{
"l2-service-type":"ietf-igmp-mld-snooping:bridge",
"enabled":true
}
}
]
} }
} },
] "ieee802-dot1q-bridge:bridges":{
} "bridge":[
}, {
"ieee802-dot1q-bridge:bridges":{ "name":"isp1",
"bridge":[ "address":"00-23-ef-a5-77-12",
{ "bridge-type":"ieee802-dot1q-bridge:customer-vlan-bridge",
"name":"isp1", "component":[
"address":"00-23-ef-a5-77-12",
"bridge-type":"ieee802-dot1q-bridge:customer-vlan-bridge",
"component":[
{
"name":"comp1",
"type":"ieee802-dot1q-bridge:c-vlan-component",
"bridge-vlan":{
"vlan":[
{ {
"vid":101, "name":"comp1",
"ietf-igmp-mld-snooping:igmp-snooping-instance":"bis1" "type":"ieee802-dot1q-bridge:c-vlan-component",
"bridge-vlan":{
"vlan":[
{
"vid":101,
"ietf-igmp-mld-snooping:igmp-snooping-instance":"bis1"
}
]
}
} }
] ]
} }
} ]
] }
} }
]
}
}
The corresponding operational state data for R1 could be as follows: The corresponding operational state data for R1 could be as follows:
{
"ietf-interfaces:interfaces": {
"interface": [
{ {
"name": "eth1/1", "ietf-interfaces:interfaces": {
"type": "iana-if-type:ethernetCsmacd", "interface": [
"oper-status": "up", {
"statistics": { "name": "eth1/1",
"discontinuity-time": "2018-05-23T12:34:56-05:00" "type": "iana-if-type:ethernetCsmacd",
"oper-status": "up",
} "statistics": {
} "discontinuity-time": "2018-05-23T12:34:56-05:00"
] }
}, }
"ietf-routing:routing": { ]
"control-plane-protocols": { },
"control-plane-protocol": [ "ietf-routing:routing": {
{ "control-plane-protocols": {
"type": "ietf-igmp-mld-snooping:igmp-snooping", "control-plane-protocol": [
"name": "bis1", {
"ietf-igmp-mld-snooping:igmp-snooping-instance": { "type": "ietf-igmp-mld-snooping:igmp-snooping",
"l2-service-type": "ietf-igmp-mld-snooping:bridge", "name": "bis1",
"enable": true "ietf-igmp-mld-snooping:igmp-snooping-instance": {
"l2-service-type": "ietf-igmp-mld-snooping:bridge",
"enabled": true
}
}
]
} }
} },
] "ieee802-dot1q-bridge:bridges": {
} "bridge": [
}, {
"ieee802-dot1q-bridge:bridges": { "name": "isp1",
"bridge": [ "address": "00-23-ef-a5-77-12",
{ "bridge-type": "ieee802-dot1q-bridge:customer-vlan-bridge",
"name": "isp1", "component": [
"address": "00-23-ef-a5-77-12",
"bridge-type": "ieee802-dot1q-bridge:customer-vlan-bridge",
"component": [
{
"name": "comp1",
"type": "ieee802-dot1q-bridge:c-vlan-component",
"bridge-vlan": {
"vlan": [
{ {
"vid": 101, "name": "comp1",
"ietf-igmp-mld-snooping:igmp-snooping-instance": "bis1" "type": "ieee802-dot1q-bridge:c-vlan-component",
"bridge-vlan": {
"vlan": [
{
"vid": 101,
"ietf-igmp-mld-snooping:igmp-snooping-instance": "bis1"
}
]
}
} }
] ]
} }
} ]
] }
} }
]
}
}
The following action is to clear all the entries whose group address is
225.1.1.1 for igmp-snooping-instance bis1.
POST /restconf/operations/ietf-routing:routing/control-plane-protocols/\ The following action is to clear all the entries whose group address
control-plane-protocol=ietf-igmp-mld-snooping:igmp-snooping,bis1/\ is 225.1.1.1 for igmp-snooping-instance bis1.
ietf-igmp-mld-snooping:igmp-snooping-instance/\
clear-igmp-snooping-groups HTTP/1.1 POST /restconf/operations/ietf-routing:routing/\
Host: example.com control-plane-protocols/\
Content-Type: application/yang-data+json control-plane-protocol=ietf-igmp-mld-snooping:igmp-snooping,bis1/\
{ ietf-igmp-mld-snooping:igmp-snooping-instance/\
"ietf-igmp-mld-snooping:input" : { clear-igmp-snooping-groups HTTP/1.1
"group": "225.1.1.1", Host: example.com
"source": "*" Content-Type: application/yang-data+json
}
} {
"ietf-igmp-mld-snooping:input" : {
"group": "225.1.1.1",
"source": "*"
}
}
Authors' Addresses Authors' Addresses
Hongji Zhao Hongji Zhao
Ericsson (China) Communications Company Ltd. Ericsson (China) Communications Company Ltd.
Ericsson Tower, No. 5 Lize East Street, Ericsson Tower, No. 5 Lize East Street
Chaoyang District Beijing 100102, China Beijing
100102
China
Email: hongji.zhao@ericsson.com Email: hongji.zhao@ericsson.com
Xufeng Liu Xufeng Liu
Volta Networks IBM Corporation
USA 2300 Dulles Station Blvd.
Herndon, VA 20171
United States of America
EMail: xufeng.liu.ietf@gmail.com Email: xufeng.liu.ietf@gmail.com
Yisong Liu Yisong Liu
China Mobile China Mobile
China China
Email: liuyisong@chinamobile.com Email: liuyisong@chinamobile.com
Anish Peter Anish Peter
Individual Individual
EMail: anish.ietf@gmail.com Email: anish.ietf@gmail.com
Mahesh Sivakumar Mahesh Sivakumar
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, California Sunnyvale, CA
USA United States of America
EMail: sivakumar.mahesh@gmail.com Email: sivakumar.mahesh@gmail.com
 End of changes. 241 change blocks. 
1601 lines changed or deleted 1596 lines changed or added

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