summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9398.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9398.txt')
-rw-r--r--doc/rfc/rfc9398.txt1042
1 files changed, 1042 insertions, 0 deletions
diff --git a/doc/rfc/rfc9398.txt b/doc/rfc/rfc9398.txt
new file mode 100644
index 0000000..364eed7
--- /dev/null
+++ b/doc/rfc/rfc9398.txt
@@ -0,0 +1,1042 @@
+
+
+
+
+Internet Engineering Task Force (IETF) H. Zhao
+Request for Comments: 9398 Ericsson
+Category: Standards Track X. Liu
+ISSN: 2070-1721 Alef Edge
+ Y. Liu
+ China Mobile
+ M. Panchanathan
+ Cisco Systems, Inc.
+ M. Sivakumar
+ Juniper
+ May 2023
+
+
+ A YANG Data Model for Internet Group Management Protocol (IGMP) and
+ Multicast Listener Discovery (MLD) Proxy Devices
+
+Abstract
+
+ This document defines a YANG data model that can be used to configure
+ and manage Internet Group Management Protocol (IGMP) or Multicast
+ Listener Discovery (MLD) Proxy devices. The YANG module in this
+ document conforms to the Network Management Datastore Architecture
+ (NMDA).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (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.
+
+ 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/rfc9398.
+
+Copyright Notice
+
+ Copyright (c) 2023 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 1.1. Terminology
+ 1.2. Tree Diagrams
+ 1.3. Prefixes in Data Node Names
+ 2. Design of Data Model
+ 2.1. Overview
+ 2.2. Optional Features
+ 2.3. Position of Address Family in Hierarchy
+ 3. Module Structure
+ 3.1. IGMP Proxy Configuration and Operational State
+ 3.2. MLD Proxy Configuration and Operational State
+ 4. IGMP/MLD Proxy YANG Module
+ 5. Security Considerations
+ 6. IANA Considerations
+ 6.1. IETF XML Registry
+ 6.2. YANG Module Names Registry
+ 7. References
+ 7.1. Normative References
+ 7.2. Informative References
+ Appendix A. Data Tree Example
+ Authors' Addresses
+
+1. Introduction
+
+ This document defines a YANG data model [RFC7950] for the management
+ of Internet Group Management Protocol (IGMP) or Multicast Listener
+ Discovery (MLD) Proxy devices [RFC4605]. The YANG module in this
+ document conforms to the Network Management Datastore Architecture as
+ defined in [RFC8342].
+
+1.1. Terminology
+
+ The terminology for describing YANG data models is found in [RFC6020]
+ and [RFC7950], including:
+
+ * augment
+
+ * data model
+
+ * data node
+
+ * identity
+
+ * module
+
+ The following abbreviations are used in this document and in the
+ defined YANG data model:
+
+ IGMP: Internet Group Management Protocol [RFC3376].
+
+ MLD: Multicast Listener Discovery [RFC3810].
+
+ PIM: Protocol Independent Multicast [RFC7761].
+
+1.2. Tree Diagrams
+
+ Tree diagrams used in this document follow the notation defined in
+ [RFC8340].
+
+1.3. Prefixes in Data Node Names
+
+ In this document, names of data nodes and other data model objects
+ are often used without a prefix, as long as the context clearly
+ indicates the YANG module in which each name is defined. Otherwise,
+ names are prefixed using the standard prefix associated with the
+ corresponding YANG module, as shown in Table 1.
+
+ +==========+====================+===========+
+ | Prefix | YANG Module | Reference |
+ +==========+====================+===========+
+ | inet | ietf-inet-types | [RFC6991] |
+ +----------+--------------------+-----------+
+ | if | ietf-interfaces | [RFC8343] |
+ +----------+--------------------+-----------+
+ | rt | ietf-routing | [RFC8349] |
+ +----------+--------------------+-----------+
+ | rt-types | ietf-routing-types | [RFC8294] |
+ +----------+--------------------+-----------+
+ | pim-base | ietf-pim-base | [RFC9128] |
+ +----------+--------------------+-----------+
+
+ Table 1: Prefixes and Corresponding YANG
+ Modules
+
+2. Design of Data Model
+
+ The model covers forwarding based on IGMP and MLD proxying [RFC4605].
+ One goal of this document is to define a data model that provides a
+ common user interface for IGMP/MLD Proxy devices.
+
+2.1. Overview
+
+ The model defined in this document has all the common building blocks
+ for IGMP/MLD Proxy devices and can be used to configure those
+ devices. The operational state data and statistics can also be
+ retrieved via this model.
+
+2.2. Optional Features
+
+ This model is designed to represent the basic capability subsets of
+ IGMP/MLD Proxies. The main design goals of this document are that
+ (1) the basic capabilities described in the model will be supported
+ by any major implementations that exist at the time of this writing
+ and (2) the configuration of all implementations meeting the
+ specifications will be easy to express through some combination of
+ the optional features in the model and simple vendor augmentations.
+
+ This model declares two features representing capabilities that not
+ all deployed devices support. One feature is called "igmp-proxy",
+ and the other feature is called "mld-proxy". Either or both features
+ could be implemented; this would provide more choices for vendors.
+
+2.3. Position of Address Family in Hierarchy
+
+ IGMP Proxies only support IPv4, while MLD Proxies only support IPv6.
+ The data model defined in this document can be used for both IPv4 and
+ IPv6 address families.
+
+ This document defines IGMP Proxies and MLD Proxies in separate schema
+ branches in the structure. The benefits of this technique are as
+ follows:
+
+ * The model can support IGMP Proxies (IPv4), MLD Proxies (IPv6), or
+ both, optionally and independently. Such flexibility cannot be
+ achieved cleanly with a combined branch.
+
+ * The structure is consistent with other YANG data models such as
+ the model defined in [RFC8652], which uses separate branches for
+ IPv4 and IPv6.
+
+ * Having separate branches for IGMP Proxies and MLD Proxies allows
+ minor differences in their behavior to be modeled more simply and
+ cleanly. The two branches can better support different features
+ and node types.
+
+3. Module Structure
+
+ This model augments the core routing data model specified in
+ [RFC8349].
+
+ +--rw routing
+ +--rw router-id?
+ +--rw control-plane-protocols
+ | +--rw control-plane-protocol* [type name]
+ | +--rw type
+ | +--rw name
+ | +--rw igmp-proxy <= Augmented by this model
+ ...
+ | +--rw mld-proxy <= Augmented by this model
+
+ The "igmp-proxy" container instantiates an IGMP Proxy. The "mld-
+ proxy" container instantiates an MLD Proxy.
+
+3.1. IGMP Proxy Configuration and Operational State
+
+ The YANG module augments /rt:routing/rt:control-plane-protocols/
+ rt:control-plane-protocol to add the igmp-proxy container.
+
+ All attributes related to IGMP Proxies are defined in the igmp-proxy
+ container. The read-write attributes represent configurable data.
+ The read-only attributes represent state data.
+
+ The igmp-version parameter represents the IGMP protocol version; the
+ default value is 2. If the value of the "enabled" parameter is
+ "true", it means that the IGMP Proxy is enabled.
+
+ The interface list under igmp-proxy contains upstream interfaces for
+ an IGMP Proxy. A constraint is provided to make sure that the
+ upstream interface for the IGMP Proxy is not configured to use PIM.
+
+ To configure a downstream interface for an IGMP Proxy, the ability to
+ enable IGMP on that interface is needed. This is defined in "A YANG
+ Data Model for the Internet Group Management Protocol (IGMP) and
+ Multicast Listener Discovery (MLD)" [RFC8652].
+
+ augment /rt:routing/rt:control-plane-protocols
+ /rt:control-plane-protocol:
+ +--rw igmp-proxy! {igmp-proxy}?
+ +--rw interfaces
+ +--rw interface* [name]
+ +--rw name if:interface-ref
+ +--rw igmp-version? uint8
+ +--rw enabled? boolean
+ +--rw sender-source-address? inet:ipv4-address-no-zone
+ +--ro group* [group-address]
+ +--ro group-address
+ | rt-types:ipv4-multicast-group-address
+ +--ro up-time? uint32
+ +--ro filter-mode enumeration
+ +--ro source* [source-address]
+ +--ro source-address
+ | inet:ipv4-address-no-zone
+ +--ro up-time? uint32
+ +--ro downstream-interface* [name]
+ +--ro name if:interface-ref
+
+3.2. MLD Proxy Configuration and Operational State
+
+ The YANG module augments /rt:routing/rt:control-plane-protocols/
+ rt:control-plane-protocol to add the mld-proxy container.
+
+ All attributes related to MLD Proxies are defined in the mld-proxy
+ container. The read-write attributes represent configurable data.
+ The read-only attributes represent state data.
+
+ The mld-version parameter represents the MLD protocol version; the
+ default value is 2. If the value of the "enabled" parameter is
+ "true", it means that the MLD Proxy is enabled.
+
+ The interface list under mld-proxy contains upstream interfaces for
+ an MLD Proxy. A constraint is provided to make sure that the
+ upstream interface for the MLD Proxy is not configured to use PIM.
+
+ To configure a downstream interface for an MLD Proxy, enable MLD on
+ that interface. This is defined in "A YANG Data Model for the
+ Internet Group Management Protocol (IGMP) and Multicast Listener
+ Discovery (MLD)" [RFC8652].
+
+ augment /rt:routing/rt:control-plane-protocols
+ /rt:control-plane-protocol:
+ +--rw mld-proxy! {mld-proxy}?
+ +--rw interfaces
+ +--rw interface* [name]
+ +--rw name if:interface-ref
+ +--rw mld-version? uint8
+ +--rw enabled? boolean
+ +--rw sender-source-address? inet:ipv6-address-no-zone
+ +--ro group* [group-address]
+ +--ro group-address
+ | rt-types:ipv6-multicast-group-address
+ +--ro up-time? uint32
+ +--ro filter-mode enumeration
+ +--ro source* [source-address]
+ +--ro source-address
+ | inet:ipv6-address-no-zone
+ +--ro up-time? uint32
+ +--ro downstream-interface* [name]
+ +--ro name if:interface-ref
+
+4. IGMP/MLD Proxy YANG Module
+
+ This module references [RFC4605], [RFC6991], [RFC8294], [RFC8343],
+ [RFC8349], and [RFC9128].
+
+ <CODE BEGINS> file "ietf-igmp-mld-proxy@2023-05-30.yang"
+ module ietf-igmp-mld-proxy {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy";
+ prefix igmp-mld-proxy;
+
+ import ietf-inet-types {
+ prefix inet;
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+ 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 ietf-pim-base {
+ prefix pim-base;
+ reference
+ "RFC 9128: YANG Data Model for Protocol Independent Multicast
+ (PIM)";
+ }
+
+ organization
+ "IETF PIM Working Group";
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/pim/>
+ WG List: <mailto:pim@ietf.org>
+
+ Editors: Hongji Zhao
+ <mailto:hongji.zhao@ericsson.com>
+
+ Xufeng Liu
+ <mailto:xufeng.liu.ietf@gmail.com>
+
+ Yisong Liu
+ <mailto:liuyisong@chinamobile.com>
+
+ Mani Panchanathan
+ <mailto:mapancha@cisco.com>
+
+ Mahesh Sivakumar
+ <mailto:sivakumar.mahesh@gmail.com>";
+ description
+ "This module defines a collection of YANG definitions common for
+ all Internet Group Management Protocol (IGMP) and Multicast
+ Listener Discovery (MLD) Proxy devices.
+
+ Copyright (c) 2023 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 Revised BSD License set
+ forth in Section 4.c of the IETF Trust's Legal Provisions
+ Relating to IETF Documents
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 9398; see the
+ RFC itself for full legal notices.";
+
+ revision 2023-05-30 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 9398: A YANG Data Model for Internet Group Management
+ Protocol (IGMP) and Multicast Listener Discovery (MLD)
+ Proxy Devices";
+ }
+
+ /*
+ * Features
+ */
+
+ feature igmp-proxy {
+ description
+ "Support for the IGMP Proxy protocol.";
+ reference
+ "RFC 4605: Internet Group Management Protocol (IGMP) /
+ Multicast Listener Discovery (MLD)-Based Multicast Forwarding
+ ('IGMP/MLD Proxying')";
+ }
+
+ feature mld-proxy {
+ description
+ "Support for the MLD Proxy protocol.";
+ reference
+ "RFC 4605: Internet Group Management Protocol (IGMP) /
+ Multicast Listener Discovery (MLD)-Based Multicast Forwarding
+ ('IGMP/MLD Proxying')";
+ }
+
+ /*
+ * Identities
+ */
+
+ identity igmp-proxy {
+ base rt:control-plane-protocol;
+ description
+ "IGMP Proxy protocol.";
+ }
+
+ identity mld-proxy {
+ base rt:control-plane-protocol;
+ description
+ "MLD Proxy protocol.";
+ }
+
+ /*
+ * Groupings
+ */
+
+ grouping per-interface-config-attributes {
+ description
+ "'config' attributes as listed under an interface entry.";
+ leaf enabled {
+ type boolean;
+ default "true";
+ description
+ "Set the value to 'true' to enable the IGMP/MLD Proxy.";
+ }
+ } // per-interface-config-attributes
+
+ grouping state-group-attributes {
+ description
+ "State group attributes.";
+ leaf up-time {
+ type uint32;
+ units "seconds";
+ description
+ "The elapsed time for (S,G) or (*,G).";
+ }
+ leaf filter-mode {
+ type enumeration {
+ enum include {
+ description
+ "In 'include' mode, reception of packets sent
+ to the specified multicast address is requested
+ only from those IP source addresses listed in the
+ 'source' list parameter.";
+ }
+ enum exclude {
+ description
+ "In 'exclude' mode, reception of packets sent
+ to the given multicast address is requested
+ from all IP source addresses except those
+ listed in the 'source' list parameter.";
+ }
+ }
+ mandatory true;
+ description
+ "Filter mode for a multicast group.
+ May be either 'include' or 'exclude'.";
+ }
+ } // state-group-attributes
+
+ /* augments */
+
+ augment "/rt:routing/rt:control-plane-protocols"
+ + "/rt:control-plane-protocol" {
+ when "derived-from-or-self(rt:type, "
+ + "'igmp-mld-proxy:igmp-proxy')" {
+ description
+ "This augmentation is only valid for IGMP Proxies.";
+ }
+ description
+ "IGMP Proxy augmentation to routing control plane protocol
+ configuration and state.";
+ container igmp-proxy {
+ if-feature "igmp-proxy";
+ presence "IGMP Proxy configuration.";
+ description
+ "IGMP Proxy instance configuration.";
+ container interfaces {
+ description
+ "Contains a list of upstream interfaces.";
+ list interface {
+ key "name";
+ description
+ "List of upstream interfaces.";
+ leaf name {
+ type if:interface-ref;
+ must 'not( current() = /rt:routing'
+ + '/rt:control-plane-protocols/pim-base:pim'
+ + '/pim-base:interfaces/pim-base:interface'
+ + '/pim-base:name )' {
+ description
+ "The upstream interface for the IGMP Proxy
+ must not be configured to use PIM.";
+ }
+ description
+ "The upstream interface name.";
+ }
+ leaf igmp-version {
+ type uint8 {
+ range "1..3";
+ }
+ default "2";
+ description
+ "IGMP version.";
+ }
+ uses per-interface-config-attributes;
+ leaf sender-source-address {
+ type inet:ipv4-address-no-zone;
+ description
+ "The sender source address of an
+ IGMP membership report message or leave message.";
+ }
+ list group {
+ key "group-address";
+ config false;
+ description
+ "List of the multicast groups in the membership
+ database built on this upstream interface.";
+ leaf group-address {
+ type rt-types:ipv4-multicast-group-address;
+ description
+ "Multicast group address.";
+ }
+ uses state-group-attributes;
+ list source {
+ key "source-address";
+ description
+ "Multicast source information
+ for the multicast group.";
+ leaf source-address {
+ type inet:ipv4-address-no-zone;
+ description
+ "Multicast source address.";
+ }
+ leaf up-time {
+ type uint32;
+ units "seconds";
+ description
+ "The elapsed time for (S,G) or (*,G).";
+ }
+ list downstream-interface {
+ key "name";
+ description
+ "List of downstream interfaces.";
+ leaf name {
+ type if:interface-ref;
+ description
+ "Downstream interfaces
+ for each upstream interface.";
+ }
+ }
+ } // list source
+ } // list group
+ } // interface
+ } // interfaces
+ }
+ }
+
+ augment "/rt:routing/rt:control-plane-protocols"
+ + "/rt:control-plane-protocol" {
+ when "derived-from-or-self(rt:type, "
+ + "'igmp-mld-proxy:mld-proxy')" {
+ description
+ "This augmentation is only valid for MLD Proxies.";
+ }
+ description
+ "MLD Proxy augmentation to routing control plane protocol
+ configuration and state.";
+ container mld-proxy {
+ if-feature "mld-proxy";
+ presence "MLD Proxy configuration.";
+ description
+ "MLD Proxy instance configuration.";
+ container interfaces {
+ description
+ "Contains a list of upstream interfaces.";
+ list interface {
+ key "name";
+ description
+ "List of upstream interfaces.";
+ leaf name {
+ type if:interface-ref;
+ must 'not( current() = /rt:routing'
+ + '/rt:control-plane-protocols/pim-base:pim'
+ + '/pim-base:interfaces/pim-base:interface'
+ + '/pim-base:name )' {
+ description
+ "The upstream interface for the MLD Proxy
+ must not be configured to use PIM.";
+ }
+ description
+ "The upstream interface name.";
+ }
+ leaf mld-version {
+ type uint8 {
+ range "1..2";
+ }
+ default "2";
+ description
+ "MLD version.";
+ }
+ uses per-interface-config-attributes;
+ leaf sender-source-address {
+ type inet:ipv6-address-no-zone;
+ description
+ "The sender source address of an
+ MLD membership report message or leave message.";
+ }
+ list group {
+ key "group-address";
+ config false;
+ description
+ "List of the multicast groups in the membership
+ database built on this upstream interface.";
+ leaf group-address {
+ type rt-types:ipv6-multicast-group-address;
+ description
+ "Multicast group address.";
+ }
+ uses state-group-attributes;
+ list source {
+ key "source-address";
+ description
+ "Multicast source information
+ for the multicast group.";
+ leaf source-address {
+ type inet:ipv6-address-no-zone;
+ description
+ "Multicast source address.";
+ }
+ leaf up-time {
+ type uint32;
+ units "seconds";
+ description
+ "The elapsed time for (S,G) or (*,G).";
+ }
+ list downstream-interface {
+ key "name";
+ description
+ "List of downstream interfaces.";
+ leaf name {
+ type if:interface-ref;
+ description
+ "Downstream interfaces
+ for each upstream interface.";
+ }
+ }
+ } // list source
+ } // list group
+ } // interface
+ } // interfaces
+ }
+ }
+ }
+ <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 Network Configuration Access Control Model (NACM) [RFC8341]
+ provides the means to restrict access for particular NETCONF or
+ RESTCONF users to a preconfigured subset of all available NETCONF or
+ RESTCONF protocol operations and content.
+
+ 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). 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:/ igmp-mld-proxy:igmp-proxy:
+
+ igmp-mld-proxy:interfaces
+ This subtree specifies the interface list for an IGMP Proxy.
+ Modifying the configuration may cause the IGMP Proxy interface to
+ be deleted or changed.
+
+ igmp-mld-proxy:interfaces/interface
+ This subtree specifies the configuration for the IGMP Proxy
+ attributes at the interface level. Modifying the configuration
+ may cause the IGMP Proxy to be deleted or changed on a specific
+ interface.
+
+ Under /rt:routing/rt:control-plane-protocols/rt:control-plane-
+ protocol:/ igmp-mld-proxy:mld-proxy:
+
+ igmp-mld-proxy:interfaces
+ This subtree specifies the interface list for an MLD Proxy.
+ Modifying the configuration may cause the MLD Proxy interface to
+ be deleted or changed.
+
+ igmp-mld-proxy:interfaces/interface
+ This subtree specifies the configuration for the MLD Proxy
+ attributes at the interface level. Modifying the configuration
+ may cause the MLD Proxy to be deleted or changed on a specific
+ interface.
+
+ Unauthorized access to any data nodes in these subtrees can adversely
+ affect the IGMP/MLD Proxy subsystem of both the local device and the
+ network. This may lead to network malfunctions, delivery of packets
+ to inappropriate destinations, and other problems.
+
+ Some of the readable data nodes in this YANG module may be considered
+ sensitive or vulnerable in some network environments. It is thus
+ 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:/
+
+ igmp-mld-proxy:igmp-proxy
+ igmp-mld-proxy:mld-proxy
+
+ Unauthorized access to any data nodes in these subtrees can disclose
+ operational state information about the IGMP/MLD Proxy on this
+ device. Group information or source information may expose multicast
+ group memberships.
+
+6. IANA Considerations
+
+6.1. IETF XML Registry
+
+ This document registers the following namespace URIs in the "IETF XML
+ Registry" [RFC3688]:
+
+ URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy
+ Registrant Contact: The IESG.
+ XML: N/A; the requested URI is an XML namespace.
+
+6.2. YANG Module Names Registry
+
+ This document registers the following YANG module in the "YANG Module
+ Names" registry [RFC6020]:
+
+ Name: ietf-igmp-mld-proxy
+ Namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy
+ Prefix: igmp-mld-proxy
+ Reference: RFC 9398
+
+7. References
+
+7.1. Normative References
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version
+ 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
+ <https://www.rfc-editor.org/info/rfc3376>.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ DOI 10.17487/RFC3688, January 2004,
+ <https://www.rfc-editor.org/info/rfc3688>.
+
+ [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
+ Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
+ DOI 10.17487/RFC3810, June 2004,
+ <https://www.rfc-editor.org/info/rfc3810>.
+
+ [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
+ "Internet Group Management Protocol (IGMP) / Multicast
+ Listener Discovery (MLD)-Based Multicast Forwarding
+ ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
+ August 2006, <https://www.rfc-editor.org/info/rfc4605>.
+
+ [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+ the Network Configuration Protocol (NETCONF)", RFC 6020,
+ DOI 10.17487/RFC6020, October 2010,
+ <https://www.rfc-editor.org/info/rfc6020>.
+
+ [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+ and A. Bierman, Ed., "Network Configuration Protocol
+ (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
+ Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+ <https://www.rfc-editor.org/info/rfc6242>.
+
+ [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
+ RFC 6991, DOI 10.17487/RFC6991, July 2013,
+ <https://www.rfc-editor.org/info/rfc6991>.
+
+ [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+ RFC 7950, DOI 10.17487/RFC7950, August 2016,
+ <https://www.rfc-editor.org/info/rfc7950>.
+
+ [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+ Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+ <https://www.rfc-editor.org/info/rfc8040>.
+
+ [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
+ "Common YANG Data Types for the Routing Area", RFC 8294,
+ DOI 10.17487/RFC8294, December 2017,
+ <https://www.rfc-editor.org/info/rfc8294>.
+
+ [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
+ Access Control Model", STD 91, RFC 8341,
+ DOI 10.17487/RFC8341, March 2018,
+ <https://www.rfc-editor.org/info/rfc8341>.
+
+ [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
+ and R. Wilton, "Network Management Datastore Architecture
+ (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
+ <https://www.rfc-editor.org/info/rfc8342>.
+
+ [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
+ Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
+ <https://www.rfc-editor.org/info/rfc8343>.
+
+ [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
+ 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
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+ [RFC8652] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A.
+ Peter, "A YANG Data Model for the Internet Group
+ Management Protocol (IGMP) and Multicast Listener
+ Discovery (MLD)", RFC 8652, DOI 10.17487/RFC8652, November
+ 2019, <https://www.rfc-editor.org/info/rfc8652>.
+
+ [RFC9128] Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
+ Y., and F. Hu, "YANG Data Model for Protocol Independent
+ Multicast (PIM)", RFC 9128, DOI 10.17487/RFC9128, October
+ 2022, <https://www.rfc-editor.org/info/rfc9128>.
+
+7.2. Informative References
+
+ [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
+ Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
+ Multicast - Sparse Mode (PIM-SM): Protocol Specification
+ (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
+ 2016, <https://www.rfc-editor.org/info/rfc7761>.
+
+ [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
+ RFC 7951, DOI 10.17487/RFC7951, August 2016,
+ <https://www.rfc-editor.org/info/rfc7951>.
+
+ [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+ BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+ <https://www.rfc-editor.org/info/rfc8340>.
+
+Appendix A. Data Tree Example
+
+ This section contains an example for the IGMP Proxy, shown in JSON
+ encoding [RFC7951] and containing both configuration and state data.
+ In the example, the IGMP Proxy is enabled on interface eth1/1.
+
+ The ability to enable IGMP on eth1/2 and eth1/3 is also needed. The
+ configuration details are omitted here because this document is
+ focused on IGMP/MLD Proxies.
+
+ +-----------+
+ + Source +
+ +-----+-----+
+ |
+ -----------------+----------------------------
+ |eth1/1
+ +---+----+
+ + R1 +
+ +-+----+-+
+ eth1/2 | \ eth1/3
+ | \
+ | \
+ | \
+ ---------------+---------+--------------------
+ | \
+ | \
+ +---------+--+ +---+--------+
+ + Receiver 1 + + Receiver 2 +
+ +------------+ +------------+
+
+ The configuration data for R1 in the above figure could be as
+ follows:
+
+ {
+ "ietf-interfaces:interfaces": {
+ "interface": [
+ {
+ "name": "eth1/1",
+ "type": "iana-if-type:ipForward",
+ "ietf-ip:ipv4": {
+ "address": [
+ {
+ "ip": "203.0.113.1",
+ "prefix-length": 24
+ }
+ ]
+ }
+ }
+ ]
+ },
+ "ietf-routing:routing": {
+ "control-plane-protocols": {
+ "control-plane-protocol": [
+ {
+ "type": "ietf-igmp-mld-proxy:igmp-proxy",
+ "name": "proxy1",
+ "ietf-igmp-mld-proxy:igmp-proxy": {
+ "interfaces": {
+ "interface": [
+ {
+ "name": "eth1/1",
+ "igmp-version": 3,
+ "enabled": true
+ }
+ ]
+ }
+ }
+ }
+ ]
+ }
+ }
+ }
+
+ The corresponding operational state data for R1 could be as follows:
+
+ {
+ "ietf-interfaces:interfaces": {
+ "interface": [
+ {
+ "name": "eth1/1",
+ "type": "iana-if-type:ipForward",
+ "admin-status": "up",
+ "oper-status": "up",
+ "if-index": 25678136,
+ "statistics": {
+ "discontinuity-time": "2021-05-23T10:34:56-06:00"
+ },
+ "ietf-ip:ipv4": {
+ "address": [
+ {
+ "ip": "203.0.113.1",
+ "prefix-length": 24
+ }
+ ]
+ }
+ }
+ ]
+ },
+ "ietf-routing:routing": {
+ "control-plane-protocols": {
+ "control-plane-protocol": [
+ {
+ "type": "ietf-igmp-mld-proxy:igmp-proxy",
+ "name": "proxy1",
+ "ietf-igmp-mld-proxy:igmp-proxy": {
+ "interfaces": {
+ "interface": [
+ {
+ "name": "eth1/1",
+ "igmp-version": 3,
+ "enabled": true,
+ "group": [
+ {
+ "group-address": "233.252.0.23",
+ "filter-mode": "include",
+ "source": [
+ {
+ "source-address": "192.0.2.1",
+ "downstream-interface": [
+ {
+ "name": "eth1/2"
+ },
+ {
+ "name": "eth1/3"
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ ]
+ }
+ }
+ }
+ ]
+ }
+ }
+ }
+
+Authors' Addresses
+
+ Hongji Zhao
+ Ericsson (China) Communications Company Ltd.
+ Ericsson Tower, No. 5 Lize East Street
+ Beijing
+ 100102
+ China
+ Email: hongji.zhao@ericsson.com
+
+
+ Xufeng Liu
+ Alef Edge
+ United States of America
+ Email: xufeng.liu.ietf@gmail.com
+
+
+ Yisong Liu
+ China Mobile
+ China
+ Email: liuyisong@chinamobile.com
+
+
+ Mani Panchanathan
+ Cisco Systems, Inc.
+ 3625 Cisco Way
+ San Jose, CA
+ United States of America
+ Email: mapancha@cisco.com
+
+
+ Mahesh Sivakumar
+ Juniper Networks
+ 1133 Innovation Way
+ Sunnyvale, CA
+ United States of America
+ Email: sivakumar.mahesh@gmail.com