draft-ietf-pim-igmp-mld-snooping-yang-10.txt   draft-ietf-pim-igmp-mld-snooping-yang-11.txt 
PIM Working Group H. Zhao PIM Working Group H. Zhao
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Standards Track X. Liu Intended status: Standards Track X. Liu
Expires: November 01, 2020 Volta Networks Expires: November 29, 2020 Volta Networks
Y. Liu Y. Liu
China Mobile China Mobile
M. Sivakumar M. Sivakumar
Juniper Juniper
A. Peter A. Peter
Individual Individual
May 02, 2020 May 30, 2020
A Yang Data Model for IGMP and MLD Snooping A Yang Data Model for IGMP and MLD Snooping
draft-ietf-pim-igmp-mld-snooping-yang-10.txt draft-ietf-pim-igmp-mld-snooping-yang-11.txt
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 Network Management Datastore Architecture (NMDA).
Status of this Memo Status of this Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 01, 2020. This Internet-Draft will expire on November 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................3 1.1. Terminology...............................................3
1.2. Tree Diagrams.............................................4 1.2. Tree Diagrams.............................................3
1.3. Prefixes in Data Node Names...............................4 1.3. Prefixes in Data Node Names...............................4
2. Design of Data Model...........................................5 2. Design of Data Model...........................................4
2.1. Overview..................................................5 2.1. Overview..................................................5
2.2. Optional Capabilities.....................................6 2.2. Optional Capabilities.....................................5
2.3. Position of Address Family in Hierarchy...................6 2.3. Position of Address Family in Hierarchy...................6
3. Module Structure...............................................7 3. Module Structure...............................................6
3.1. IGMP Snooping Instances...................................7 3.1. IGMP Snooping Instances...................................7
3.2. MLD Snooping Instances...................................10 3.2. MLD Snooping Instances....................................9
3.3. Using IGMP and MLD Snooping Instances....................12 3.3. Using IGMP and MLD Snooping Instances....................11
3.4. IGMP and MLD Snooping RPC................................13 3.4. IGMP and MLD Snooping RPC................................12
4. IGMP and MLD Snooping YANG Module.............................13 4. IGMP and MLD Snooping YANG Module.............................12
5. Security Considerations.......................................35 5. Security Considerations.......................................34
6. IANA Considerations...........................................37 6. IANA Considerations...........................................35
7. References....................................................38 7. References....................................................36
7.1. Normative References.....................................38 7.1. Normative References.....................................36
7.2. Informative References...................................40 7.2. Informative References...................................38
Appendix A. Data Tree Example...................................41 Appendix A. Data Tree Example...................................39
A.1 Bridge scenario...........................................41 A.1 Bridge scenario...........................................39
A.2 L2VPN scenario............................................44 A.2 L2VPN scenario............................................42
Authors' Addresses...............................................48 Authors' Addresses...............................................46
1. Introduction 1. Introduction
This document defines a YANG [RFC6020] data model for the management of This document defines a YANG [RFC6020] data model for the management of
Internet Group Management Protocol (IGMP) and Multicast Listener Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping [RFC4541] devices. Discovery (MLD) Snooping [RFC4541] devices.
The YANG module in this document conforms to the Network Management The YANG module in this document conforms to the Network Management
Datastore Architecture defined in [RFC8342]. The "Network Management Datastore Architecture defined in [RFC8342]. The "Network Management
Datastore Architecture" (NMDA) adds the ability to inspect the current Datastore Architecture" (NMDA) adds the ability to inspect the current
skipping to change at page 4, line 20 skipping to change at page 4, line 14
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 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 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 context in which YANG module each name is defined. Otherwise, names are
prefixed using the standard prefix associated with the corresponding prefixed using the standard prefix associated with the corresponding
YANG module, as shown in Table 1. YANG module, as shown in Table 1.
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+==========+=======================+=================================+ +==========+=======================+=================================+
| inet | ietf-inet-types | [RFC6991] | | inet | ietf-inet-types | [RFC6991] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| yang | ietf-yang-types | [RFC6991] | | yang | ietf-yang-types | [RFC6991] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| if | ietf-interfaces | [RFC8343] | | if | ietf-interfaces | [RFC8343] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| rt | ietf-routing | [RFC8349] | | rt | ietf-routing | [RFC8349] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| rt-types | ietf-routing-types | [RFC8294] | | rt-types | ietf-routing-types | [RFC8294] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| ni | ietf-network-instance | [RFC8529] | | ni | ietf-network-instance | [RFC8529] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| pw | ietf-pseudowires | [draft-ietf-bess-l2vpn-yang] | | pw | ietf-pseudowires | [draft-ietf-bess-l2vpn-yang] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| l2vpn | ietf-l2vpn | [draft-ietf-bess-l2vpn-yang] | | l2vpn | ietf-l2vpn | [draft-ietf-bess-l2vpn-yang] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
| dot1q | ieee802-dot1q-bridge | [dot1Qcp] | | dot1q | ieee802-dot1q-bridge | [dot1Qcp] |
+----------+-----------------------+---------------------------------+ +----------+-----------------------+---------------------------------+
Table 1: Prefixes and Corresponding YANG Modules 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
up forwarding tables for multicast traffic. If a switch does not run
IGMP/MLD snooping, multicast traffic will be flooded in the broadcast
domain. If a switch runs IGMP/MLD snooping, multicast traffic will be
forwarded based on the forwarding tables to avoid bandwidth waste. The
IGMP/MLD snooping switch does not need to run any of the IGMP/MLD
protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD
protocols, the data model defined in this document does not augment, or
even require, the IGMP/MLD data model defined in [RFC8652].
The model covers considerations for Internet Group Management Protocol The model covers considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping Switches (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
[RFC4541]. [RFC4541].
In recent years, a number of commercial vendors have introduced products IGMP and MLD snooping switches do not adhere to the conceptual model
described as "IGMP snooping switches" to the market. These devices do that provides the strict separation of functionality between different
not adhere to the conceptual model that provides the strict separation communications layers in the ISO model, and instead utilize information
of functionality between different communications layers in the ISO in the upper level protocol headers as factors to be considered in
model, and instead utilize information in the upper level protocol processing at the lower levels [RFC4541].
headers as factors to be considered in processing at the lower levels
[RFC4541].
IGMP Snooping switches utilize IGMP, and could support IGMPv1, IGMPv2,
and IGMPv3. IGMP snooping switches may maintain forwarding tables based
on either MAC addresses or IP addresses [RFC4541]. MLD Snooping switches
utilize MLD, and could support MLDv1 and MLDv2.
The goal of this document is to define a data model that provides a IGMP Snooping switches utilize IGMP, and could support IGMPv1 [RFC1112],
common user interface to IGMP and MLD Snooping. IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD Snooping switches utilize
MLD, and could support MLDv1 [RFC2710] and MLDv2 [RFC3810]. The goal of
this document is to define a data model that 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 IGMP and MLD Snooping YANG module defined in this document has all
the common building blocks for the IGMP and MLD Snooping switches. 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 IGMP and MLD Snooping instance definition,
using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN [draft- using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN [draft-
ietf-bess-l2vpn-yang]. The module also includes the RPC methods for ietf-bess-l2vpn-yang]. The module also includes the RPC methods for
clearing IGMP and MLD Snooping group tables. clearing IGMP and MLD Snooping group tables.
This YANG module conforms to Network Management Datastore Architecture This YANG module conforms to Network Management Datastore Architecture
(NMDA)[RFC8342]. This NMDA architecture provides an architectural (NMDA)[RFC8342]. This NMDA architecture provides an architectural
framework for datastores as they are used by network management framework for datastores as they are used by network management
protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG
[RFC7950] data modeling language. [RFC7950] data modeling language.
2.2. Optional Capabilities 2.2. Optional Capabilities
This model is designed to represent the capabilities of IGMP and MLD This model is designed to represent the basic capability subsets of IGMP
switches with various specifications, including the basic capability and MLD Snooping. The main design goals of this document are that the
subsets of IGMP and MLD Snooping. The main design goals of this document basic capabilities described in the model are supported by any major
are 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 all
implementations meeting the specifications is easy to express through implementations meeting the specifications is easy to express through
some combination of the optional features in the model and simple vendor some combination of the optional features in the model and simple vendor
augmentations. augmentations.
There is also value in widely supported features being standardized, to There is also value in widely supported features being standardized, to
provide a standardized way to access these features, to save work for provide a standardized way to access these features, to save work for
individual vendors, and so that mapping between different vendors' individual vendors, and so that mapping between different vendors'
configuration is not needlessly complicated. Therefore, this model configuration is not needlessly complicated. Therefore, this model
declares a number of features representing capabilities that not all declares a number of features representing capabilities that not all
deployed devices support. deployed devices support.
skipping to change at page 6, line 48 skipping to change at page 6, line 30
IPv6 address families. IPv6 address families.
This document defines IGMP Snooping and MLD Snooping as separate schema This document defines IGMP Snooping and MLD Snooping as separate schema
branches in the structure. The benefits are: 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), or
both optionally and independently. Such flexibility cannot be achieved both optionally and independently. Such flexibility cannot be achieved
cleanly with a combined branch. 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
[RFC8344], which uses separate branches for IPv4 and IPv6. [RFC8652], which uses separate branches for IPv4 and IPv6.
* The separate branches for IGMP Snooping and MLD Snooping can * The separate branches for IGMP Snooping and MLD Snooping can
accommodate their differences better and cleaner. The two branches can accommodate their differences better and cleaner. The two branches can
better support different features and node types. better support different features 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
skipping to change at page 12, line 23 skipping to change at page 11, line 42
The igmp-snooping-instance could be used in the scenario of BRIDGE The igmp-snooping-instance could be used in the scenario of BRIDGE
[dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] to configure the IGMP [dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] to configure the IGMP
Snooping. Snooping.
For the BRIDGE scenario this model augments /dot1q:bridges/dot1q:bridge For the BRIDGE scenario this model augments /dot1q:bridges/dot1q:bridge
to use igmp-snooping-instance. It means IGMP Snooping is enabled in the to use igmp-snooping-instance. It means IGMP Snooping is enabled in the
whole bridge. whole bridge.
It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/ It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/
dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means
IGMP Snooping is enabled in the certain VLAN of the bridge. IGMP Snooping is enabled in the specified VLAN on the bridge.
augment /dot1q:bridges/dot1q:bridge: augment /dot1q:bridges/dot1q:bridge:
+--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref
+--rw mld-snooping-instance? igmp-mld-snooping-instance-ref +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref
augment /dot1q:bridges/dot1q:bridge/dot1q:component augment /dot1q:bridges/dot1q:bridge/dot1q:component
/dot1q:bridge-vlan/dot1q:vlan: /dot1q:bridge-vlan/dot1q:vlan:
+--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref
+--rw mld-snooping-instance? igmp-mld-snooping-instance-ref +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref
For the L2VPN scenario this model augments /ni:network-instances/ For the L2VPN scenario this model augments /ni:network-instances/
ni:network-instance/ni:ni-type/l2vpn:l2vpn [RFC8529] to use igmp- ni:network-instance/ni:ni-type/l2vpn:l2vpn [RFC8529] to use igmp-
snooping-instance. It means IGMP Snooping is enabled in the specified snooping-instance. It means IGMP Snooping is enabled in the specified
l2vpn instance. l2vpn instance.
skipping to change at page 13, line 26 skipping to change at page 12, line 36
| +---w source? rt-types:ipv4-multicast-source-address | +---w source? rt-types:ipv4-multicast-source-address
+---x clear-mld-snooping-groups {rpc-clear-groups}? +---x clear-mld-snooping-groups {rpc-clear-groups}?
+---w input +---w input
+---w name? igmp-mld-snooping-instance-ref +---w name? igmp-mld-snooping-instance-ref
| {feature-mld-snooping}? | {feature-mld-snooping}?
+---w group? rt-types:ipv6-multicast-group-address +---w group? rt-types:ipv6-multicast-group-address
+---w source? rt-types:ipv6-multicast-source-address +---w source? rt-types:ipv6-multicast-source-address
4. IGMP and MLD Snooping YANG Module 4. IGMP and MLD Snooping YANG Module
This module references This module references [RFC3376],[RFC4541],[RFC6636],[RFC6991],
[RFC2236],[RFC3376],[RFC3810],[RFC4286],[RFC4541],[RFC4604],[RFC4607], [RFC8343],[RFC8529],[dot1Qcp], and [draft-ietf-bess-l2vpn-yang].
[RFC6020],[RFC6241],[RFC6636],[RFC6991],[RFC7950],[RFC8040],[RFC8342],
[RFC8343],[RFC8340],[RFC8529],[RFC8652],[dot1Qcp], and [draft-ietf-bess-
l2vpn-yang].
<CODE BEGINS> file ietf-igmp-mld-snooping@2020-04-29.yang <CODE BEGINS> file ietf-igmp-mld-snooping@2020-04-29.yang
module ietf-igmp-mld-snooping { module ietf-igmp-mld-snooping {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping"; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping";
prefix ims; prefix ims;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
skipping to change at page 35, line 26 skipping to change at page 34, line 35
operations and content. operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). writable/creatable/deletable (i.e., config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some These data nodes may be considered sensitive or vulnerable in some
network environments. Write operations (e.g., edit-config) to these data network environments. Write operations (e.g., edit-config) to these data
nodes without proper protection can have a negative effect on network nodes without proper protection can have a negative effect on network
operations. These are the subtrees and data nodes and their operations. These are the subtrees and data nodes and their
sensitivity/vulnerability: sensitivity/vulnerability:
/rt:routing/rt:control-plane-protocols Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/
/rt:control-plane-protocol:/ims:igmp-snooping-instance
/rt:routing/rt:control-plane-protocols ims:igmp-snooping-instance
/rt:control-plane-protocol:/ims:mld-snooping-instance ims:mld-snooping-instance
The subtrees under /dot1q:bridges/dot1q:bridge The subtrees under /dot1q:bridges/dot1q:bridge
/dot1q:bridges/dot1q:bridge/ims:igmp-snooping-instance ims:igmp-snooping-instance
/dot1q:bridges/dot1q:bridge/ims:mld-snooping-instance ims:mld-snooping-instance
The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component
/dot1q:bridge-vlan/dot1q:vlan /dot1q:bridge-vlan/dot1q:vlan
/dot1q:bridges/dot1q:bridge/dot1q:component ims:igmp-snooping-instance
/dot1q:bridge-vlan/dot1q:vlan/ims:igmp-snooping-instance
/dot1q:bridges/dot1q:bridge/dot1q:component
/dot1q:bridge-vlan/dot1q:vlan/ims:mld-snooping-instance
ims:mld-snooping-instance
Unauthorized access to any data node of these subtrees can adversely Unauthorized access to any data node of these subtrees can adversely
affect the IGMP & MLD Snooping subsystem of both the local device and affect the IGMP & MLD Snooping subsystem of both the local device and
the network. This may lead to network malfunctions, delivery of packets the network. This may lead to network malfunctions, delivery of packets
to inappropriate destinations, and other problems. to inappropriate destinations, and other problems.
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data nodes notification) to these data nodes. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/rt:routing/rt:control-plane-protocols Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/
/rt:control-plane-protocol:/ims:igmp-snooping-instance
/rt:routing/rt:control-plane-protocols ims:igmp-snooping-instance
/rt:control-plane-protocol:/ims:mld-snooping-instance ims:mld-snooping-instance
Unauthorized access to any data node of these subtrees can disclose the Unauthorized access to any data node of these subtrees can disclose the
operational state information of IGMP & MLD Snooping on this device. operational state information of IGMP & MLD Snooping on this device.
Some of the RPC operations in this YANG module may be considered Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
ims:clear-igmp-snooping-groups ims:clear-igmp-snooping-groups
skipping to change at page 37, line 15 skipping to change at page 35, line 48
6. IANA Considerations 6. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note). actual RFC number (and remove this note).
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
Registrant Contact: The IETF.
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document registers the following YANG modules in the YANG Module This document registers the following YANG modules in the YANG Module
Names registry [RFC7950]: Names registry [RFC7950]:
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-igmp-mld-snooping name: ietf-igmp-mld-snooping
namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
prefix: ims prefix: ims
reference: RFC XXXX reference: RFC XXXX
-------------------------------------------------------------------- --------------------------------------------------------------------
7. References 7. References
7.1. Normative References 7.1. Normative References
[dot1Qcp] Holness, M., "IEEE 802.1Qcp-2018 Bridges and Bridged [dot1Qcp] IEEE, "Standard for Local and metropolitan area networks--
Networks - Amendment: YANG Data Model", 2018. Bridges and Bridged Networks--Amendment 30: YANG Data
Model", IEEE Std 802.1Qcp-2018 (Revision of IEEE Std
802.1Q-2014), September 2018,
<https://ieeexplore.ieee.org/servlet/opac?punumber=8467505>
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2",
RFC 2236, November 1997. RFC 2236, November 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[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, October 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4286] B. Haberman and J. Martin, "Multicast Router Discovery", [RFC4286] B. Haberman and J. Martin, "Multicast Router Discovery",
RFC 4286, December 2005. RFC 4286, December 2005.
[RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations
for Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping Switches", RFC 4541, May
2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[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,
skipping to change at page 38, line 52 skipping to change at page 37, line 30
[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, June 2011.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
[RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, August 2016. RFC 7950, August 2016.
[RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC
7951, August 2016.
[RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol",
RFC 8040, January 2017. RFC 8040, January 2017.
[RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG
Data Types for the Routing Area", RFC 8294, December 2017. Data Types for the Routing Area", RFC 8294, December 2017.
[RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC
8340, March 2018. 8340, March 2018.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access
Control Model", RFC 8341, March 2018. Control Model", RFC 8341, March 2018.
[RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management
Datastore Architecture (NMDA)", RFC 8342, March 2018. Datastore Architecture (NMDA)", RFC 8342, March 2018.
[RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management",
RFC 8343, March 2018. RFC 8343, March 2018.
[RFC8344] M. Bjorklund, "A YANG Data Model for IP Management", RFC
8344, March 2018.
[RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing
Management (NMDA Version)", RFC 8349, March 2018. Management (NMDA Version)", RFC 8349, March 2018.
[RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", RFC 8407, October Documents Containing YANG Data Models", RFC 8407, October
2018. 2018.
[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, August 2018.
skipping to change at page 40, line 11 skipping to change at page 38, line 25
Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model
for MPLS-basedL2VPN", draft-ietf-bess-l2vpn-yang-10 (work for MPLS-basedL2VPN", draft-ietf-bess-l2vpn-yang-10 (work
in progress), July 2019. in progress), July 2019.
7.2. Informative References 7.2. Informative References
[RFC3916] X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed., [RFC3916] X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.,
"Requirements for Pseudo-Wire Emulation Edge-to-Edge "Requirements for Pseudo-Wire Emulation Edge-to-Edge
(PWE3)", RFC 3916, September 2004. (PWE3)", RFC 3916, September 2004.
[RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations
for Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping Switches", RFC 4541, May
2006.
[RFC6636] H. Asaeda, H. Liu, Q. Wu, "Tuning the Behavior of the [RFC6636] H. Asaeda, H. Liu, Q. Wu, "Tuning the Behavior of the
Internet Group Management Protocol (IGMP) and Multicast Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) for Routers in Mobile and Wireless Listener Discovery (MLD) for Routers in Mobile and Wireless
Networks", RFC 6636, May 2012. Networks", RFC 6636, May 2012.
[RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC
7951, August 2016.
Appendix A. Data Tree Example Appendix A. Data Tree Example
A.1 Bridge scenario A.1 Bridge scenario
This section contains an example for bridge scenario in the JSON This section contains an example for bridge scenario in the JSON
encoding [RFC7951], containing both configuration and state data. encoding [RFC7951], containing both configuration and state data.
+-----------+ +-----------+
+ Source + + Source +
+-----+-----+ +-----+-----+
skipping to change at page 41, line 27 skipping to change at page 39, line 27
|eth1/1 |eth1/1
+---+---+ +---+---+
+ R1 + + R1 +
+-+---+-+ +-+---+-+
eth1/2 | \ eth1/3 eth1/2 | \ eth1/3
| \ | \
| \ | \
| \ | \
| \ | \
eth2/1 | \ eth3/1 eth2/1 | \ eth3/1
+---+---+ +--+---+ +---+---+ +--+---+
+ R2 + + R3 + + R2 + + R3 +
+---+---+ +--+---+ +---+---+ +--+---+
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:
 End of changes. 66 change blocks. 
114 lines changed or deleted 83 lines changed or added

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