draft-ietf-pim-igmp-mld-yang-09.txt   draft-ietf-pim-igmp-mld-yang-10.txt 
PIM Working Group X. Liu PIM Working Group X. Liu
Internet-Draft Volta Internet-Draft Volta
Intended Status: Standard Track F. Guo Intended Status: Standard Track F. Guo
Expires: April 19, 2019 Huawei Expires: July 19, 2019 Huawei
M. Sivakumar M. Sivakumar
Juniper Juniper
P. McAllister P. McAllister
Metaswitch Networks Metaswitch Networks
A. Peter A. Peter
Individual Individual
October 19, 2018 January 19, 2019
A YANG data model for Internet Group Management Protocol (IGMP) and A YANG data model for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Multicast Listener Discovery (MLD)
draft-ietf-pim-igmp-mld-yang-09 draft-ietf-pim-igmp-mld-yang-10
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference 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 April 15, 2019. This Internet-Draft will expire on July 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
This document defines a YANG data model that can be used to This document defines a YANG data model that can be used to
configure and manage Internet Group Management Protocol (IGMP) and configure and manage Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) devices. Multicast Listener Discovery (MLD) devices.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
1.1. Terminology ............................................ 3 1.1. Terminology ............................................ 3
1.2. Tree Diagrams .......................................... 3 1.2. Tree Diagrams .......................................... 3
1.3. Prefixes in Data Node Names............................. 3 1.3. Prefixes in Data Node Names ............................ 3
2. Design of Data model......................................... 4 2. Design of Data model......................................... 4
2.1. Scope of model ......................................... 4 2.1. Scope of model ......................................... 4
2.2. Optional capabilities................................... 4 2.2. Optional capabilities .................................. 4
2.3. Position of address family in hierarchy................. 5 2.3. Position of address family in hierarchy ................ 5
3. Module Structure ............................................ 5 3. Module Structure ............................................ 5
3.1. IGMP Configuration and Operational state................ 5 3.1. IGMP Configuration and Operational state ............... 5
3.2. MLD Configuration and Operational State................. 7 3.2. MLD Configuration and Operational State ................ 8
3.3. IGMP and MLD RPC........................................ 9 3.3. IGMP and MLD RPC ...................................... 10
4. IGMP and MLD YANG Modules................................... 10 4. IGMP and MLD YANG Modules .................................. 11
5. Security Considerations..................................... 33 5. Security Considerations .................................... 34
6. IANA Considerations ........................................ 35 6. IANA Considerations ........................................ 36
7. Acknowledgments ............................................ 35 7. Acknowledgments ............................................ 37
8. Contributing Authors........................................ 36 8. Contributing Authors........................................ 37
9. References ................................................. 36 9. References ................................................. 37
9.1. Normative References................................... 36 9.1. Normative References .................................. 37
9.2. Informative References................................. 38 9.2. Informative References ................................ 39
1. Introduction 1. Introduction
YANG [RFC6020] [RFC7950] is a data definition language that was YANG [RFC6020] [RFC7950] is a data definition language that was
introduced to model the configuration and running state of a device introduced to model the configuration and running state of a device
managed using network management protocols such as NETCONF [RFC6241] managed using network management protocols such as NETCONF [RFC6241]
or RESTCONF [RFC8040]. YANG is now also being used as a component of or RESTCONF [RFC8040]. YANG is now also being used as a component of
wider management interfaces, such as CLIs. wider management interfaces, such as CLIs.
This document defines a YANG data model that can be used to This document defines a YANG data model that can be used to
skipping to change at page 5, line 44 skipping to change at page 5, line 44
Interface-level: IGMP configuration and operational state Interface-level: IGMP configuration and operational state
attributes specific to the given interface. attributes specific to the given interface.
Where fields are not genuinely essential to protocol operation, they Where fields are not genuinely essential to protocol operation, they
are marked as optional. Some fields will be essential but have a are marked as optional. Some fields will be essential but have a
default specified, so that they need not be configured explicitly. default specified, so that they need not be configured explicitly.
This model augments the core routing data model "ietf-routing" This model augments the core routing data model "ietf-routing"
specified in [RFC8349]. The IGMP model augments "/rt:routing/ specified in [RFC8349]. The IGMP model augments "/rt:routing/
rt:control-plane-protocols" as opposed to augmenting "/rt:routing/ rt:control-plane-protocols/rt:control-plane-protocol", following the
rt:control-plane-protocols/rt:control-plane-protocol", as the latter convention described in [RFC8349].
would allow multiple protocol instances, while the IGMP protocol is
designed to be enabled or disabled as a single protocol instance on
a network instance or a logical network element.
augment /rt:routing/rt:control-plane-protocols: augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--rw igmp {feature-igmp}? +--rw igmp {feature-igmp}?
+--rw global +--rw global
| +--rw enable? boolean {global-admin-enable}? | +--rw enable? boolean {global-admin-enable}?
| +--rw max-entries? uint32 {global-max-entries}? | +--rw max-entries? uint32 {global-max-entries}?
| +--rw max-groups? uint32 {global-max-groups}? | +--rw max-groups? uint32 {global-max-groups}?
| +--ro entries-count? uint32 | +--ro entries-count? uint32
| +--ro groups-count? uint32 | +--ro groups-count? uint32
| +--ro statistics | +--ro statistics
| +--ro discontinuity-time? yang:date-and-time | +--ro discontinuity-time? yang:date-and-time
| +--ro error | +--ro error
skipping to change at page 6, line 32 skipping to change at page 6, line 30
| | +--ro leave? yang:counter64 | | +--ro leave? yang:counter64
| +--ro sent | +--ro sent
| +--ro total? yang:counter64 | +--ro total? yang:counter64
| +--ro query? yang:counter64 | +--ro query? yang:counter64
| +--ro report? yang:counter64 | +--ro report? yang:counter64
| +--ro leave? yang:counter64 | +--ro leave? yang:counter64
+--rw interfaces +--rw interfaces
+--rw last-member-query-interval? uint16 +--rw last-member-query-interval? uint16
+--rw query-interval? uint16 +--rw query-interval? uint16
+--rw query-max-response-time? uint16 +--rw query-max-response-time? uint16
+--rw require-router-alert? boolean {intf-require-router-alert}? +--rw require-router-alert? boolean
| {intf-require-router-alert}?
+--rw robustness-variable? uint8 +--rw robustness-variable? uint8
+--rw version? uint8 +--rw version? uint8
+--rw max-groups-per-interface? uint32 {intf-max-groups}? +--rw max-groups-per-interface? uint32
| {intf-max-groups}?
+--rw interface* [interface-name] +--rw interface* [interface-name]
+--rw interface-name if:interface-ref +--rw interface-name if:interface-ref
+--rw last-member-query-interval? uint16 +--rw last-member-query-interval? uint16
+--rw query-interval? uint16 +--rw query-interval? uint16
+--rw query-max-response-time? uint16 +--rw query-max-response-time? uint16
+--rw require-router-alert? boolean {intf-require-router-alert}? +--rw require-router-alert? boolean
| {intf-require-router-alert}?
+--rw robustness-variable? uint8 +--rw robustness-variable? uint8
+--rw version? uint8 +--rw version? uint8
+--rw enable? boolean {intf-admin-enable}? +--rw enable? boolean
+--rw group-policy? -> /acl:acls/acl/name | {intf-admin-enable}?
+--rw immediate-leave? empty {intf-immediate-leave}? +--rw group-policy?
+--rw max-groups? uint32 {intf-max-groups}? | -> /acl:acls/acl/name
+--rw max-group-sources? uint32 {intf-max-group-sources}? +--rw immediate-leave? empty
+--rw source-policy? -> /acl:acls/acl/name {intf-source-policy}? | {intf-immediate-leave}?
+--rw verify-source-subnet? empty {intf-verify-source-subnet}? +--rw max-groups? uint32
+--rw explicit-tracking? empty {intf-explicit-tracking}? | {intf-max-groups}?
+--rw exclude-lite? empty {intf-exclude-lite}? +--rw max-group-sources? uint32
+--rw join-group* rt-types:ipv4-multicast-group-address {intf-join-group}? | {intf-max-group-sources}?
+--rw ssm-map* [ssm-map-source-addr ssm-map-group-policy] {intf-ssm-map}? +--rw source-policy?
| -> /acl:acls/acl/name {intf-source-policy}?
+--rw verify-source-subnet? empty
| {intf-verify-source-subnet}?
+--rw explicit-tracking? empty
| {intf-explicit-tracking}?
+--rw exclude-lite? empty
| {intf-exclude-lite}?
+--rw join-group*
| rt-types:ipv4-multicast-group-address
| {intf-join-group}?
+--rw ssm-map*
| [ssm-map-source-addr ssm-map-group-policy]
| {intf-ssm-map}?
| +--rw ssm-map-source-addr ssm-map-ipv4-addr-type | +--rw ssm-map-source-addr ssm-map-ipv4-addr-type
| +--rw ssm-map-group-policy string | +--rw ssm-map-group-policy string
+--rw static-group* [group-addr source-addr] {intf-static-group}? +--rw static-group* [group-addr source-addr]
| +--rw group-addr rt-types:ipv4-multicast-group-address | {intf-static-group}?
| +--rw source-addr rt-types:ipv4-multicast-source-address | +--rw group-addr
| | rt-types:ipv4-multicast-group-address
| +--rw source-addr
| rt-types:ipv4-multicast-source-address
+--ro oper-status enumeration +--ro oper-status enumeration
+--ro querier inet:ipv4-address +--ro querier inet:ipv4-address
+--ro joined-group* rt-types:ipv4-multicast-group-address {intf-join-group}? +--ro joined-group*
| rt-types:ipv4-multicast-group-address
| {intf-join-group}?
+--ro group* [group-address] +--ro group* [group-address]
+--ro group-address rt-types:ipv4-multicast-group-address +--ro group-address
| rt-types:ipv4-multicast-group-address
+--ro expire uint32 +--ro expire uint32
+--ro filter-mode enumeration +--ro filter-mode enumeration
+--ro up-time uint32 +--ro up-time uint32
+--ro last-reporter? inet:ipv4-address +--ro last-reporter? inet:ipv4-address
+--ro source* [source-address] +--ro source* [source-address]
+--ro source-address inet:ipv4-address +--ro source-address inet:ipv4-address
+--ro expire uint32 +--ro expire uint32
+--ro up-time uint32 +--ro up-time uint32
+--ro host-count? uint32 {intf-explicit-tracking}? +--ro host-count? uint32
| {intf-explicit-tracking}?
+--ro last-reporter? inet:ipv4-address +--ro last-reporter? inet:ipv4-address
+--ro host* [host-address] {intf-explicit-tracking}? +--ro host* [host-address]
{intf-explicit-tracking}?
+--ro host-address inet:ipv4-address +--ro host-address inet:ipv4-address
+--ro host-filter-mode enumeration +--ro host-filter-mode enumeration
3.2. MLD Configuration and Operational State 3.2. MLD Configuration and Operational State
The MLD YANG model uses the same structure as IGMP YANG model. The The MLD YANG model uses the same structure as IGMP YANG model. The
MLD module also defines in a three-level hierarchy structure as MLD module also defines in a three-level hierarchy structure as
listed below: listed below:
augment /rt:routing/rt:control-plane-protocols: augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--rw mld {feature-mld}? +--rw mld {feature-mld}?
+--rw global +--rw global
| +--rw enable? boolean {global-admin-enable}? | +--rw enable? boolean {global-admin-enable}?
| +--rw max-entries? uint32 {global-max-entries}? | +--rw max-entries? uint32 {global-max-entries}?
| +--rw max-groups? uint32 {global-max-groups}? | +--rw max-groups? uint32 {global-max-groups}?
| +--ro entries-count? uint32 | +--ro entries-count? uint32
| +--ro groups-count? uint32 | +--ro groups-count? uint32
| +--ro statistics | +--ro statistics
| +--ro discontinuity-time? yang:date-and-time | +--ro discontinuity-time? yang:date-and-time
| +--ro error | +--ro error
skipping to change at page 8, line 19 skipping to change at page 8, line 43
| | +--ro leave? yang:counter64 | | +--ro leave? yang:counter64
| +--ro sent | +--ro sent
| +--ro total? yang:counter64 | +--ro total? yang:counter64
| +--ro query? yang:counter64 | +--ro query? yang:counter64
| +--ro report? yang:counter64 | +--ro report? yang:counter64
| +--ro leave? yang:counter64 | +--ro leave? yang:counter64
+--rw interfaces +--rw interfaces
+--rw last-member-query-interval? uint16 +--rw last-member-query-interval? uint16
+--rw query-interval? uint16 +--rw query-interval? uint16
+--rw query-max-response-time? uint16 +--rw query-max-response-time? uint16
+--rw require-router-alert? boolean {intf-require-router-alert}? +--rw require-router-alert? boolean
| {intf-require-router-alert}?
+--rw robustness-variable? uint8 +--rw robustness-variable? uint8
+--rw version? uint8 +--rw version? uint8
+--rw max-groups-per-interface? uint32 {intf-max-groups}? +--rw max-groups-per-interface? uint32
| {intf-max-groups}?
+--rw interface* [interface-name] +--rw interface* [interface-name]
+--rw interface-name if:interface-ref +--rw interface-name if:interface-ref
+--rw last-member-query-interval? uint16 +--rw last-member-query-interval? uint16
+--rw query-interval? uint16 +--rw query-interval? uint16
+--rw query-max-response-time? uint16 +--rw query-max-response-time? uint16
+--rw require-router-alert? boolean {intf-require-router-alert}? +--rw require-router-alert? boolean
| {intf-require-router-alert}?
+--rw robustness-variable? uint8 +--rw robustness-variable? uint8
+--rw version? uint8 +--rw version? uint8
+--rw enable? boolean {intf-admin-enable}? +--rw enable? boolean
+--rw group-policy? -> /acl:acls/acl/name | {intf-admin-enable}?
+--rw immediate-leave? empty {intf-immediate-leave}? +--rw group-policy?
+--rw max-groups? uint32 {intf-max-groups}? | -> /acl:acls/acl/name
+--rw max-group-sources? uint32 {intf-max-group-sources}? +--rw immediate-leave? empty
+--rw source-policy? -> /acl:acls/acl/name {intf-source-policy}? | {intf-immediate-leave}?
+--rw verify-source-subnet? empty {intf-verify-source-subnet}? +--rw max-groups? uint32
+--rw explicit-tracking? empty {intf-explicit-tracking}? | {intf-max-groups}?
+--rw exclude-lite? empty {intf-exclude-lite}? +--rw max-group-sources? uint32
+--rw join-group* rt-types:ipv6-multicast-group-address {intf-join-group}? | {intf-max-group-sources}?
+--rw ssm-map* [ssm-map-source-addr ssm-map-group-policy] {intf-ssm-map}? +--rw source-policy?
| -> /acl:acls/acl/name {intf-source-policy}?
+--rw verify-source-subnet? empty
| {intf-verify-source-subnet}?
+--rw explicit-tracking? empty
| {intf-explicit-tracking}?
+--rw exclude-lite? empty
| {intf-exclude-lite}?
+--rw join-group*
| rt-types:ipv6-multicast-group-address
| {intf-join-group}?
+--rw ssm-map*
| [ssm-map-source-addr ssm-map-group-policy]
| {intf-ssm-map}?
| +--rw ssm-map-source-addr ssm-map-ipv6-addr-type | +--rw ssm-map-source-addr ssm-map-ipv6-addr-type
| +--rw ssm-map-group-policy string | +--rw ssm-map-group-policy string
+--rw static-group* [group-addr source-addr] {intf-static-group}? +--rw static-group* [group-addr source-addr]
| +--rw group-addr rt-types:ipv6-multicast-group-address | {intf-static-group}?
| +--rw source-addr rt-types:ipv6-multicast-source-address | +--rw group-addr
| | rt-types:ipv6-multicast-group-address
| +--rw source-addr
| rt-types:ipv6-multicast-source-address
+--ro oper-status enumeration +--ro oper-status enumeration
+--ro querier inet:ipv6-address +--ro querier inet:ipv6-address
+--ro joined-group* rt-types:ipv6-multicast-group-address {intf-join-group}? +--ro joined-group*
| rt-types:ipv6-multicast-group-address
| {intf-join-group}?
+--ro group* [group-address] +--ro group* [group-address]
+--ro group-address rt-types:ipv6-multicast-group-address +--ro group-address
| rt-types:ipv6-multicast-group-address
+--ro expire uint32 +--ro expire uint32
+--ro filter-mode enumeration +--ro filter-mode enumeration
+--ro up-time uint32 +--ro up-time uint32
+--ro last-reporter? inet:ipv6-address +--ro last-reporter? inet:ipv6-address
+--ro source* [source-address] +--ro source* [source-address]
+--ro source-address inet:ipv6-address +--ro source-address inet:ipv6-address
+--ro expire uint32 +--ro expire uint32
+--ro up-time uint32 +--ro up-time uint32
+--ro host-count? uint32 {intf-explicit-tracking}? +--ro host-count? uint32
| {intf-explicit-tracking}?
+--ro last-reporter? inet:ipv6-address +--ro last-reporter? inet:ipv6-address
+--ro host* [host-address] {intf-explicit-tracking}? +--ro host* [host-address]
{intf-explicit-tracking}?
+--ro host-address inet:ipv6-address +--ro host-address inet:ipv6-address
+--ro host-filter-mode enumeration +--ro host-filter-mode enumeration
3.3. IGMP and MLD RPC 3.3. IGMP and MLD RPC
IGMP and MLD RPC clears the specified IGMP and MLD group membership. IGMP and MLD RPC clears the specified IGMP and MLD group membership.
rpcs: rpcs:
+---x clear-igmp-groups {rpc-clear-groups}? +---x clear-igmp-groups {rpc-clear-groups}?
skipping to change at page 10, line 7 skipping to change at page 11, line 7
mld}? mld}?
+---w group-addrss? rt-types:ipv6-multicast-group- +---w group-addrss? rt-types:ipv6-multicast-group-
address address
+---w source-address? rt-types:ipv6-multicast-source- +---w source-address? rt-types:ipv6-multicast-source-
address address
4. IGMP and MLD YANG Modules 4. IGMP and MLD YANG Modules
<CODE BEGINS> file "ietf-igmp-mld@2018-09-15.yang" <CODE BEGINS> file "ietf-igmp-mld@2019-01-03.yang"
module ietf-igmp-mld { module ietf-igmp-mld {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld"; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld";
// replace with IANA namespace when assigned // replace with IANA namespace when assigned
prefix igmp-mld; prefix igmp-mld;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
skipping to change at page 11, line 24 skipping to change at page 12, line 24
Editor: Pete McAllister Editor: Pete McAllister
<mailto:pete.mcallister@metaswitch.com> <mailto:pete.mcallister@metaswitch.com>
Editor: Anish Peter Editor: Anish Peter
<mailto:anish.ietf@gmail.com>"; <mailto:anish.ietf@gmail.com>";
description description
"The module defines a collection of YANG definitions common for "The module defines a collection of YANG definitions common for
IGMP and MLD."; IGMP and MLD.";
revision 2019-01-03 {
description
"Updated yang data model to address the review comment to
augment control-plane-protocol with protocol type.";
reference
"RFC XXXX: A YANG Data Model for IGMP and MLD";
}
revision 2018-09-15 { revision 2018-09-15 {
description description
"Updated yang data model for default value, address type and "Updated yang data model for default value, address type and
repeated leaf definition."; repeated leaf definition.";
reference reference
"RFC XXXX: A YANG Data Model for IGMP and MLD"; "RFC XXXX: A YANG Data Model for IGMP and MLD";
} }
revision 2018-06-21 { revision 2018-06-21 {
description description
"Updated yang data model for parameter range and description."; "Updated yang data model for parameter range and description.";
skipping to change at page 14, line 38 skipping to change at page 15, line 46
} }
type inet:ipv6-address; type inet:ipv6-address;
} }
description description
"Multicast source IP address type for SSM map."; "Multicast source IP address type for SSM map.";
} // source-ipv6-addr-type } // source-ipv6-addr-type
/* /*
* Identities * Identities
*/ */
identity igmp {
base "rt:control-plane-protocol";
description "IGMP protocol.";
reference
"RFC3376: Internet Group Management Protocol, Version 3.";
}
identity mld {
base "rt:control-plane-protocol";
description "MLD protocol.";
reference
"RFC3810: Multicast Listener Discovery Version 2 (MLDv2) for
IPv6.";
}
/* /*
* Groupings * Groupings
*/ */
grouping global-config-attributes { grouping global-config-attributes {
description "Global IGMP and MLD configuration."; description "Global IGMP and MLD configuration.";
leaf enable { leaf enable {
if-feature global-admin-enable; if-feature global-admin-enable;
type boolean; type boolean;
skipping to change at page 29, line 21 skipping to change at page 30, line 40
mandatory true; mandatory true;
description description
"Filter mode for a multicast membership "Filter mode for a multicast membership
host may be either include or exclude."; host may be either include or exclude.";
} }
}// interface-state-host-attributes-igmp-mld }// interface-state-host-attributes-igmp-mld
/* /*
* Configuration and Operational state data nodes (NMDA version) * Configuration and Operational state data nodes (NMDA version)
*/ */
augment "/rt:routing/rt:control-plane-protocols" augment "/rt:routing/rt:control-plane-protocols/"
{ + "rt:control-plane-protocol" {
when "derived-from-or-self(rt:type, 'igmp-mld:igmp')" {
description
"This augmentation is only valid for a control-plane
protocol instance of IGMP (type 'igmp').";
}
description description
"IGMP augmentation to routing control plane protocol "IGMP augmentation to routing control plane protocol
configuration and state."; configuration and state.";
container igmp { container igmp {
if-feature feature-igmp; if-feature feature-igmp;
description description
"IGMP configuration and operational state data."; "IGMP configuration and operational state data.";
container global { container global {
skipping to change at page 30, line 20 skipping to change at page 31, line 44
} }
uses interface-config-attributes-igmp { uses interface-config-attributes-igmp {
if-feature per-interface-config; if-feature per-interface-config;
} }
uses interface-state-attributes-igmp; uses interface-state-attributes-igmp;
} // interface } // interface
} // interfaces } // interfaces
} // igmp } // igmp
}//augment }//augment
augment "/rt:routing/rt:control-plane-protocols" augment "/rt:routing/rt:control-plane-protocols/"
{ + "rt:control-plane-protocol" {
when "derived-from-or-self(rt:type, 'igmp-mld:mld')" {
description
"This augmentation is only valid for a control-plane
protocol instance of IGMP (type 'mld').";
}
description description
"MLD augmentation to routing control plane protocol "MLD augmentation to routing control plane protocol
configuration and state."; configuration and state.";
container mld { container mld {
if-feature feature-mld; if-feature feature-mld;
description description
"MLD configuration and operational state data."; "MLD configuration and operational state data.";
container global { container global {
skipping to change at page 31, line 33 skipping to change at page 33, line 13
rpc clear-igmp-groups { rpc clear-igmp-groups {
if-feature rpc-clear-groups; if-feature rpc-clear-groups;
description description
"Clears the specified IGMP cache entries."; "Clears the specified IGMP cache entries.";
input { input {
leaf interface-name { leaf interface-name {
if-feature feature-igmp; if-feature feature-igmp;
type leafref { type leafref {
path "/rt:routing/rt:control-plane-protocols/" path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "igmp-mld:igmp/igmp-mld:interfaces/" + "igmp-mld:igmp/igmp-mld:interfaces/"
+ "igmp-mld:interface/igmp-mld:interface-name"; + "igmp-mld:interface/igmp-mld:interface-name";
} }
description description
"Name of the IGMP interface. "Name of the IGMP interface.
If it is not specified, groups from all interfaces are If it is not specified, groups from all interfaces are
cleared."; cleared.";
} }
leaf group-address { leaf group-address {
type rt-types:ipv4-multicast-group-address; type rt-types:ipv4-multicast-group-address;
skipping to change at page 32, line 19 skipping to change at page 33, line 49
rpc clear-mld-groups { rpc clear-mld-groups {
if-feature rpc-clear-groups; if-feature rpc-clear-groups;
description description
"Clears the specified MLD cache entires."; "Clears the specified MLD cache entires.";
input { input {
leaf interface-name { leaf interface-name {
if-feature feature-mld; if-feature feature-mld;
type leafref { type leafref {
path "/rt:routing/rt:control-plane-protocols/" path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "igmp-mld:mld/igmp-mld:interfaces/" + "igmp-mld:mld/igmp-mld:interfaces/"
+ "igmp-mld:interface/igmp-mld:interface-name"; + "igmp-mld:interface/igmp-mld:interface-name";
} }
description description
"Name of the MLD interface. "Name of the MLD interface.
If it is not specified, groups from all interfaces are If it is not specified, groups from all interfaces are
cleared."; cleared.";
} }
leaf group-addrss { leaf group-addrss {
type rt-types:ipv6-multicast-group-address; type rt-types:ipv6-multicast-group-address;
skipping to change at page 33, line 51 skipping to change at page 35, line 30
igmp:interfaces/interface igmp:interfaces/interface
This subtree specifies the configuration for the IGMP attributes This subtree specifies the configuration for the IGMP attributes
at the interface level on a device. Modifying the configuration at the interface level on a device. Modifying the configuration
can cause IGMP membership deleted or reconstructed on a specific can cause IGMP membership deleted or reconstructed on a specific
interface of a device. interface of a device.
These subtrees are all under These subtrees are all under
/rt:routing/rt:control-plane protocols/igmp: /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp:
mld:global mld:global
This subtree specifies the configuration for the MLD attributes at This subtree specifies the configuration for the MLD attributes at
the global level on a device. Modifying the configuration can the global level on a device. Modifying the configuration can
cause MLD membership deleted or reconstructed on all the cause MLD membership deleted or reconstructed on all the
interfaces of a device. interfaces of a device.
mld:interfaces mld:interfaces
This subtree specifies the configuration for the MLD attributes at This subtree specifies the configuration for the MLD attributes at
all of the interfaces level on a device. Modifying the all of the interfaces level on a device. Modifying the
configuration can cause MLD membership deleted or reconstructed on configuration can cause MLD membership deleted or reconstructed on
skipping to change at page 34, line 25 skipping to change at page 36, line 7
mld:interfaces/interface mld:interfaces/interface
This subtree specifies the configuration for the MLD attributes at This subtree specifies the configuration for the MLD attributes at
the interface level on a device. Modifying the configuration can the interface level on a device. Modifying the configuration can
cause MLD membership deleted or reconstructed on a specific cause MLD membership deleted or reconstructed on a specific
interface of a device. interface of a device.
These subtrees are all under These subtrees are all under
/rt:routing/rt:control-plane-protocols/mld: /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/mld:
Unauthorized access to any data node of these subtrees can adversely Unauthorized access to any data node of these subtrees can adversely
affect the membership records of multicast routing subsystem on the affect the membership records of multicast routing subsystem on the
local device. This may lead to network malfunctions, delivery of local device. This may lead to network malfunctions, delivery of
packets to inappropriate destinations, and other problems. packets to inappropriate destinations, and other problems.
Some of the readable data nodes in this YANG module may be Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments. It considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and or notification) to these data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability: data nodes and their sensitivity/vulnerability:
/rt:routing/rt:control-plane-protocols/igmp /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp
/rt:routing/rt:control-plane-protocols/mld /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/mld
Unauthorized access to any data node of the above subtree can Unauthorized access to any data node of the above subtree can
disclose the operational state information of IGMP or MLD on this disclose the operational state information of IGMP or MLD on this
device. 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:
skipping to change at page 36, line 26 skipping to change at page 38, line 6
9.1. Normative References 9.1. Normative References
[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, August 1989.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997. 2", RFC 2236, November 1997.
[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 Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008 (TLS) Protocol Version 1.2", RFC 5246, August 2008
[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 October 2010
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011 (NETCONF)", RFC 6241, June 2011
[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
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, April Protocol (NETCONF) Access Control Model", RFC 6536, March
2012 2012
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, July 2013 RFC 6991, July 2013
[RFC7950] Bjorklund, M., 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, August 2016
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017 Protocol", RFC 8040, January 2017
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294, "Common YANG Data Types for the Routing Area", RFC 8294,
December 2017 December 2017
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, April 2018 (NMDA)", RFC 8342, March 2018
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, April 2018 Management", RFC 8343, March 2018
[RFC8344] M. Bjorklund, "A YANG Data Model for IP Management", [RFC8344] M. Bjorklund, "A YANG Data Model for IP Management",
RFC8344, April 2018 RFC8344, March 2018
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, April 2018 Routing Management (NMDA Version)", RFC 8349, March 2018
[I-D.ietf-acl-yang] M. Jethanandani, L. Huang, S. Agarwal and D. [I-D.ietf-acl-yang] M. Jethanandani, L. Huang, S. Agarwal and D.
Blair, "Network Access Control List (ACL) YANG Data Blair, "Network Access Control List (ACL) YANG Data
Model", draft-ietf-netmod-acl-model-19(work in progress), Model", draft-ietf-netmod-acl-model-19(work in progress),
April 2018 April 2018
9.2. Informative References 9.2. Informative References
[RFC4541] M. Christensen, K. Kimball and F. Solensky, [RFC4541] M. Christensen, K. Kimball and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
skipping to change at page 38, line 23 skipping to change at page 39, line 37
Group Management Protocol (IGMP) / Multicast Listener Group Management Protocol (IGMP) / Multicast Listener
Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD
Proxying")", RFC 4605, August 2006. Proxying")", RFC 4605, August 2006.
[RFC5790] H. Liu, W. Cao and H. Asaeda, "Lightweight Internet Group [RFC5790] H. Liu, W. Cao and H. Asaeda, "Lightweight Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast 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 February 2010
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, April 2018 BCP 215, RFC 8340, March 2018
[I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors
and Reviewers of YANG Data Model Documents", draft-ietf- and Reviewers of YANG Data Model Documents", draft-ietf-
netmod-rfc6087bis-20(work in progress), April 2018 netmod-rfc6087bis-20(work in progress), March 2018
Authors' Addresses Authors' Addresses
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Feng Guo Feng Guo
Huawei Technologies Huawei Technologies
 End of changes. 50 change blocks. 
86 lines changed or deleted 171 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/