A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping

A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Ericsson (China) Communications Company Ltd.

Ericsson Tower, No. 5 Lize East Street Beijing 100102 China hongji.zhao@ericsson.com

IBM Corporation

2300 Dulles Station Blvd. Herndon VA 20171 United States of America xufeng.liu.ietf@gmail.com

China Mobile


          China


        
        liuyisong@chinamobile.com


    
      Individual
      
        anish.ietf@gmail.com
        
      
    
    
      Juniper Networks
      
        
          1133 Innovation Way
          Sunnyvale
          CA
          
          United States of America
        
        
        sivakumar.mahesh@gmail.com
        
      

    
    
    RTG
    PIM
    YANG
    IGMP Snooping
    MLD Snooping
    multicast
    data model
    ietf-igmp-mld-snooping
    network management
    routing
    
      
   This document defines a YANG data model that can be used to configure and
   manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery
   (MLD) snooping 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
            .
        
      
      
        Copyright Notice
        
            Copyright (c) 2022 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
            () 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
        
          
            .  Introduction
            
              
                .  Terminology
              
              
                .  Tree Diagrams
              
              
                .  Prefixes in Data Node Names
              
            
          
          
            .  Design of Data Model
            
              
                .  Overview
              
              
                .  Optional Capabilities
              
              
                .  Position of Address Family in Hierarchy
              
            
          
          
            .  Module Structure
            
              
                .  IGMP Snooping Instances
              
              
                .  MLD Snooping Instances
              
              
                .  Using IGMP and MLD Snooping Instances
              
              
                .  IGMP and MLD Snooping Actions
              
            
          
          
            .  IGMP and MLD Snooping YANG Module
          
          
            .  Security Considerations
          
          
            .  IANA Considerations
            
              
                .  XML Registry
              
              
                .  YANG Module Names Registry
              
            
          
          
            .  References
            
              
                .  Normative References
              
              
                .  Informative References
              
            
          
          
            .  Data Tree Example
          
          
            Authors' Addresses


  
    
      Introduction
      
   This document defines a YANG  data model for the management of
   IGMP and MLD snooping  devices.
      
   The YANG module in this document conforms to the NMDA defined in . The NMDA adds the ability to inspect the
   current operational values for configuration, allowing clients to use
   identical paths for retrieving the configured values and the operational
   values.
      
        Terminology
        
   The terminology for describing YANG data models is found in  and
   , including:

        
        
          augment
          data model
          data node
          identity
          module
        
        
   The following terminologies are used in this document:
        
          mrouter:
          multicast router, which is a router that has
        multicast routing enabled .
          mrouter interfaces:
          snooping switch ports where
        multicast routers are attached .
        
        
   The following abbreviations are used in this document and defined model:
        
          IGMP:
          Internet Group Management Protocol .
          MLD:
          Multicast Listener Discovery .
        
      
      
        Tree Diagrams
        
   Tree diagrams used in this document follow the notation defined in
   .
      
      
        Prefixes in Data Node Names
        
   In this document, names of data nodes, actions, and other data model
   objects are often used without a prefix, as long as it is clear from the
   context in which YANG module each name is defined. Otherwise, names are
   prefixed using the standard prefix associated with the corresponding YANG
   module, as shown in . 
        
        Prefixes and Corresponding YANG Modules
          
          
            
              Prefix
              YANG module
              Reference
            
          
          
            
              inet
              ietf-inet-types
              
                
            
            
              yang
              ietf-yang-types
              
                
            
            
              if
              ietf-interfaces
              
                
            
            
              rt
              ietf-routing
              
                
            
            
              rt-types
              ietf-routing-types
              
                
            
            
              dot1q
              ieee802-dot1q-bridge
              
                
            
          
        
      
    
    
      Design of Data Model
      
   An IGMP/MLD snooping switch  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 wasting bandwidth. 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 .  The model covers considerations for IGMP and MLD snooping switches .
      
   IGMP and MLD snooping switches do not adhere to the conceptual model that
   provides the strict separation of functionality between different
   communications layers in the ISO model and instead utilize information in
   the upper-level protocol headers as factors to be considered in processing
   at the lower levels .
      
   IGMP snooping switches utilize IGMP and could support IGMPv1 , IGMPv2 , and IGMPv3 . 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 common user
   interface to IGMP and MLD snooping.
      
        Overview
        
   The YANG module on IGMP and MLD snooping defined in this document has all the
        common building blocks for the IGMP and MLD snooping switches.
          
   The YANG module includes an IGMP and MLD snooping instance definition that uses the instance in the L2 service type of bridge . It also includes actions for clearing
        IGMP and MLD snooping group tables.
        The YANG module doesn't cover L2VPN, which will be specified in a separate document.
        
      
      
        Optional Capabilities
        
   This model is designed to represent the basic capability subsets of IGMP
   and MLD snooping. The main design goals of this document are that the basic
   capabilities described in the model are supported by any major now-existing
   implementation and that the configuration of all implementations meeting
   the specifications is easy to express through some combination of the
   optional features in the model and simple vendor augmentations.
        
   There is also value in widely supported features being standardized to
   provide a standardized way to access these features, to save work for
   individual vendors, and to ensure that mapping between different vendors'
   configuration is not needlessly complicated. Therefore, this model declares
   a number of features representing capabilities that not all deployed
   devices support.
        
   The extensive use of feature declarations should also substantially
   simplify the capability negotiation process for a vendor's IGMP and MLD
   snooping implementations.
        
   On the other hand, operational state parameters are not so widely
   designated as features, as there are many cases where the defaulting of an
   operational state parameter would not cause any harm to the system, and it
   is much more likely that an implementation without intrinsic support for a
   piece of operational state would be able to derive a suitable value for a
   state variable that is not intrinsically supported.
      
      
        Position of Address Family in Hierarchy
        
   IGMP snooping only supports IPv4, while MLD snooping only supports IPv6.
   The data model defined in this document can be used for both IPv4 and IPv6
   address families.
        
   This document defines IGMP snooping and MLD snooping as separate schema
   branches in the structure. The benefits are:

        
        
          The model can support IGMP snooping (IPv4), MLD snooping (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
        , which uses separate branches for IPv4 and
        IPv6.
          Having separate branches for IGMP snooping and MLD snooping allows
        minor differences in their behavior to be modeled more simply and
        cleanly. The two branches can better support different features and
        node types.
        
      
    
    
      Module Structure
      This model augments the core routing data model specified in .
      
   +--rw routing
      +--rw router-id?
      +--rw control-plane-protocols
      |  +--rw control-plane-protocol* [type name]
      |     +--rw type
      |     +--rw name
      |     +--rw igmp-snooping-instance <= Augmented by this Model
                     ...
      |     +--rw mld-snooping-instance   <= Augmented by this Model
                     ...

      
   The "igmp-snooping-instance" container instantiates an IGMP snooping
   instance. The "mld-snooping-instance" container instantiates an MLD
   snooping instance.
      
   The YANG data model defined in this document conforms to the NMDA . The operational state
   data is combined with the associated configuration data in the same
   hierarchy .
      
        IGMP Snooping Instances
        
   The YANG module ietf-igmp-mld-snooping augments
   /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol to add the
   igmp-snooping-instance container.
        
   All the IGMP snooping-related attributes have been defined in the
   igmp-snooping-instance. The read-write attributes represent configurable
   data. The read-only attributes represent state data.
        
	One igmp-snooping-instance could be used in one bridge  instance, and it corresponds to one bridge instance.
        
   Currently, the value of l2-service-type in igmp-snooping-instance could only be set to 'bridge'. After it is set, igmp-snooping-instance could be used in the bridge
   service.
        
   The values of bridge-mrouter-interface are filled by the snooping device
   dynamically. It is different from static-bridge-mrouter-interface,
   which is configured.
        
   The attributes under the interfaces show the statistics of IGMP snooping-related packets.
        
augment /rt:routing/rt:control-plane-protocols
         /rt:control-plane-protocol:
  +--rw igmp-snooping-instance {igmp-snooping}?
     +--rw l2-service-type?                     l2-service-type
     +--rw enabled?                             boolean
     +--rw forwarding-table-type?               enumeration
     +--rw explicit-tracking?                   boolean
     |       {explicit-tracking}?
     +--rw lite-exclude-filter?                 empty
     |       {lite-exclude-filter}?
     +--rw send-query?                          boolean
     +--rw fast-leave?                          empty {fast-leave}?
     +--rw last-member-query-interval?          uint16
     +--rw query-interval?                      uint16
     +--rw query-max-response-time?             uint16
     +--rw require-router-alert?                boolean
     |       {require-router-alert}?
     +--rw robustness-variable?                 uint8
     +--rw static-bridge-mrouter-interface*     if:interface-ref
     |       {static-mrouter-interface}?
     +--rw igmp-version?                        uint8
     +--rw querier-source?                      inet:ipv4-address
     +--rw static-l2-multicast-group* [group source-addr]
     |       {static-l2-multicast-group}?
     |  +--rw group
     |  |       rt-types:ipv4-multicast-group-address
     |  +--rw source-addr
     |  |       rt-types:ipv4-multicast-source-address
     |  +--rw bridge-outgoing-interface*   if:interface-ref
     +--ro entries-count?                       yang:gauge32
     +--ro bridge-mrouter-interface*            if:interface-ref
     +--ro group* [address]
     |  +--ro address
     |  |       rt-types:ipv4-multicast-group-address
     |  +--ro mac-address?     yang:phys-address
     |  +--ro expire?          rt-types:timer-value-seconds16
     |  +--ro up-time          uint32
     |  +--ro last-reporter?   inet:ipv4-address
     |  +--ro source* [address]
     |     +--ro address
     |     |       rt-types:ipv4-multicast-source-address
     |     +--ro bridge-outgoing-interface*   if:interface-ref
     |     +--ro up-time                      uint32
     |     +--ro expire?
     |     |       rt-types:timer-value-seconds16
     |     +--ro host-count?                  yang:gauge32
     |     |       {explicit-tracking}?
     |     +--ro last-reporter?               inet:ipv4-address
     |     +--ro host* [address] {explicit-tracking}?
     |        +--ro address        inet:ipv4-address
     |        +--ro filter-mode    filter-mode-type
     +--ro interfaces
        +--ro interface* [name]
           +--ro name          if:interface-ref
           +--ro statistics
              +--ro discontinuity-time?   yang:date-and-time
              +--ro received
              |  +--ro query-count?                  yang:counter64
              |  +--ro membership-report-v1-count?   yang:counter64
              |  +--ro membership-report-v2-count?   yang:counter64
              |  +--ro membership-report-v3-count?   yang:counter64
              |  +--ro leave-count?                  yang:counter64
              |  +--ro pim-hello-count?              yang:counter64
              +--ro sent
                 +--ro query-count?                  yang:counter64
                 +--ro membership-report-v1-count?   yang:counter64
                 +--ro membership-report-v2-count?   yang:counter64
                 +--ro membership-report-v3-count?   yang:counter64
                 +--ro leave-count?                  yang:counter64
                 +--ro pim-hello-count?              yang:counter64

      
      
        MLD Snooping Instances
        
   The YANG module ietf-igmp-mld-snooping augments
   /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol to add the
   mld-snooping-instance container. The mld-snooping-instance could be used in
   the bridge  service to
   enable MLD snooping.
        
   All the MLD snooping-related attributes have been defined in the
   mld-snooping-instance. The read-write attributes represent configurable
   data. The read-only attributes represent state data.
        
   The mld-snooping-instance has a similar structure to IGMP snooping. Some
   leaves are protocol related. The mld-snooping-instance uses IPv6 addresses
   and mld-version, while igmp-snooping-instance uses IPv4 addresses and
   igmp-version. Statistic counters in each of the above snooping instances
   are also tailored to the specific protocol type. One mld-snooping-instance
   could be used in one bridge instance and corresponds to one bridge instance.
        
   Currently, the value of l2-service-type in mld-snooping-instance could only be set to 'bridge'. After it is set, mld-snooping-instance could be used in the bridge
   service.
        
   The value of bridge-mrouter-interface is filled by the snooping device
   dynamically. It is different from static-bridge-mrouter-interface,
   which is configured.
        
   The attributes under the interfaces show the statistics of MLD snooping-related packets.
        
augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol:
  +--rw mld-snooping-instance {mld-snooping}?
  +--rw l2-service-type?                          l2-service-type
     +--rw enabled?                             boolean
     +--rw forwarding-table-type?               enumeration
     +--rw explicit-tracking?                   boolean
     |       {explicit-tracking}?
     +--rw lite-exclude-filter?                 empty
     |       {lite-exclude-filter}?
     +--rw send-query?                          boolean
     +--rw fast-leave?                          empty {fast-leave}?
     +--rw last-member-query-interval?          uint16
     +--rw query-interval?                      uint16
     +--rw query-max-response-time?             uint16
     +--rw require-router-alert?                boolean
     |       {require-router-alert}?
     +--rw robustness-variable?                 uint8
     +--rw static-bridge-mrouter-interface*     if:interface-ref
     |       {static-mrouter-interface}?
     +--rw mld-version?                         uint8
     +--rw querier-source?                      inet:ipv6-address
     +--rw static-l2-multicast-group* [group source-addr]
     |       {static-l2-multicast-group}?
     |  +--rw group
     |  |       rt-types:ipv6-multicast-group-address
     |  +--rw source-addr
     |  |       rt-types:ipv6-multicast-source-address
     |  +--rw bridge-outgoing-interface*   if:interface-ref
     +--ro entries-count?                       yang:gauge32
     +--ro bridge-mrouter-interface*            if:interface-ref
     +--ro group* [address]
     |  +--ro address
     |  |       rt-types:ipv6-multicast-group-address
     |  +--ro mac-address?     yang:phys-address
     |  +--ro expire?          rt-types:timer-value-seconds16
     |  +--ro up-time          uint32
     |  +--ro last-reporter?   inet:ipv6-address
     |  +--ro source* [address]
     |     +--ro address
     |     |       rt-types:ipv6-multicast-source-address
     |     +--ro bridge-outgoing-interface*   if:interface-ref
     |     +--ro up-time                      uint32
     |     +--ro expire?
     |     |       rt-types:timer-value-seconds16
     |     +--ro host-count?                  yang:gauge32
     |     |       {explicit-tracking}?
     |     +--ro last-reporter?               inet:ipv6-address
     |     +--ro host* [address]       {explicit-tracking}?
     |        +--ro address             inet:ipv6-address
     |        +--ro filter-mode    filter-mode-type
     +--ro interfaces
        +--ro interface* [name]
           +--ro name          if:interface-ref
           +--ro statistics
              +--ro discontinuity-time?   yang:date-and-time
              +--ro received
              |  +--ro query-count?       yang:counter64
              |  +--ro report-v1-count?   yang:counter64
              |  +--ro report-v2-count?   yang:counter64
              |  +--ro done-count?        yang:counter64
              |  +--ro pim-hello-count?   yang:counter64
              +--ro sent
                 +--ro query-count?       yang:counter64
                 +--ro report-v1-count?   yang:counter64
                 +--ro report-v2-count?   yang:counter64
                 +--ro done-count?        yang:counter64
                 +--ro pim-hello-count?   yang:counter64

      
      
        Using IGMP and MLD Snooping Instances
        
	The igmp-snooping-instance could be used in the service of bridge  to configure the IGMP snooping.
        
   For the bridge service, this model augments /dot1q:bridges/dot1q:bridge to
   use igmp-snooping-instance. It means IGMP snooping is enabled in the bridge.
        
   It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means IGMP
   snooping is enabled in the specified VLAN on the bridge.
        The mld-snooping-instance could be used in concurrence with igmp-snooping-instance to configure the MLD snooping.
        
        
augment /dot1q:bridges/dot1q:bridge:
  +--rw igmp-snooping-instance?   igmp-mld-snooping-instance-ref
  +--rw mld-snooping-instance?    igmp-mld-snooping-instance-ref

augment /dot1q:bridges/dot1q:bridge/dot1q:component
          /dot1q:bridge-vlan/dot1q:vlan:
  +--rw igmp-snooping-instance?   igmp-mld-snooping-instance-ref
  +--rw mld-snooping-instance?    igmp-mld-snooping-instance-ref

      
      
        IGMP and MLD Snooping Actions
        
   IGMP and MLD snooping actions clear the specified IGMP and MLD snooping
   group tables. If both source X and group Y are specified, only source X
   from group Y in that specific instance will be cleared.
        
augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol:
  +--rw igmp-snooping-instance {igmp-snooping}?
     +---x clear-igmp-snooping-groups {action-clear-groups}?
        +---w input
           +---w group     union
           +---w source    rt-types:ipv4-multicast-source-address

augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol:
  +--rw mld-snooping-instance {mld-snooping}?
     +---x clear-mld-snooping-groups {action-clear-groups}?
        +---w input
           +---w group     union
           +---w source    rt-types:ipv6-multicast-source-address

      
    
    
      IGMP and MLD Snooping YANG Module
      

	
   This module references , , , ,
      , , , , , , , and .
      
module ietf-igmp-mld-snooping {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping";
  prefix ims;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-yang-types {
    prefix yang;
    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 ieee802-dot1q-bridge {
    prefix dot1q;
    reference
      "dot1Qcp: IEEE 802.1Qcp-2018 Standard for Local and
       Metropolitan area networks--Bridges and Bridged Networks
       --Amendment 30: YANG Data Model";
  }

  organization
    "IETF PIM Working Group";
  contact
    "WG Web:   <http://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>

               Anish Peter
               <mailto:anish.ietf@gmail.com>

               Mahesh Sivakumar
               <mailto:sivakumar.mahesh@gmail.com>

    ";
  description
    "The module defines a collection of YANG definitions common for
     all devices that implement Internet Group Management Protocol
     (IGMP) and Multicast Listener Discovery (MLD) snooping, which is
     described in RFC 4541.

     Copyright (c) 2022 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
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9166; see the
     RFC itself for full legal notices.";

  revision 2022-01-31 {
    description
      "Initial revision.";
    reference
      "RFC 9166: A YANG Data Model for Internet Group Management
       Protocol (IGMP) and Multicast Listener Discovery (MLD)
       Snooping";
  }

  /*
   * Features
   */

  feature igmp-snooping {
    description
      "Support IGMP snooping.";
    reference
      "RFC 4541: Considerations for Internet Group Management
       Protocol (IGMP) and Multicast Listener Discovery (MLD)
       Snooping Switches";
  }

  feature mld-snooping {
    description
      "Support MLD snooping.";
    reference
      "RFC 4541: Considerations for Internet Group Management
       Protocol (IGMP) and Multicast Listener Discovery (MLD)
       Snooping Switches";
  }

  feature fast-leave {
    description
      "Support configuration of fast leave.  The fast leave feature
       does not send last member query messages to hosts.";
    reference
      "RFC 3376: Internet Group Management Protocol, Version 3";
  }

  feature static-l2-multicast-group {
    description
      "Support configuration of static L2 multicast group.";
  }

  feature static-mrouter-interface {
    description
      "Support multicast router interface explicitly configured
       by management.";
    reference
      "RFC 4541: Considerations for Internet Group Management
       Protocol (IGMP) and Multicast Listener Discovery (MLD)
       Snooping Switches";
  }

  feature action-clear-groups {
    description
      "Support clearing statistics by action for IGMP and MLD
       snooping.";
  }

  feature require-router-alert {
    description
      "Support configuration of require-router-alert.";
    reference
      "RFC 3376: Internet Group Management Protocol, Version 3";
  }

  feature lite-exclude-filter {
    description
      "Enable the support of the simplified EXCLUDE filter.";
    reference
      "RFC 5790: Lightweight Internet Group Management Protocol
       Version 3 (IGMPv3) and Multicast Listener Discovery Version
       2 (MLDv2) Protocols";
  }

  feature explicit-tracking {
    description
      "Support configuration of per-instance explicit-tracking.";
    reference
      "RFC 6636: Tuning the Behavior of the Internet Group Management
       Protocol (IGMP) and Multicast Listener Discovery (MLD) for
       Routers in Mobile and Wireless Networks";
  }

  /* identities */

  identity l2-service-type {
    description
      "Base identity for L2 service type in IGMP and MLD snooping.";
  }

  identity bridge {
    base l2-service-type;
    description
      "This identity represents bridge service.";
  }

  identity filter-mode {
    description
      "Base identity for filter mode in IGMP and MLD snooping.";
  }

  identity include {
    base filter-mode;
    description
      "This identity represents include mode.";
  }

  identity exclude {
    base filter-mode;
    description
      "This identity represents exclude mode.";
  }

  identity igmp-snooping {
    base rt:control-plane-protocol;
    description
      "IGMP snooping.";
  }

  identity mld-snooping {
    base rt:control-plane-protocol;
    description
      "MLD snooping.";
  }

  /*
   * Typedefs
   */

  typedef l2-service-type {
    type identityref {
      base l2-service-type;
    }
    description
      "The L2 service type used with IGMP and MLD
       snooping.";
  }

  typedef filter-mode-type {
    type identityref {
      base filter-mode;
    }
    description
      "The host filter mode.";
  }

  typedef igmp-mld-snooping-instance-ref {
    type leafref {
      path "/rt:routing/rt:control-plane-protocols"
         + "/rt:control-plane-protocol/rt:name";
    }
    description
      "This type is used by data models that need to
       reference IGMP or MLD snooping instance.";
  }

  /*
   * Groupings
   */

  grouping instance-config-attributes-igmp-mld-snooping {
    description
      "IGMP and MLD snooping configuration of each VLAN.";
    leaf enabled {
      type boolean;
      default "false";
      description
        "Set the value to true to enable IGMP and MLD snooping.";
    }
    leaf forwarding-table-type {
      type enumeration {
        enum mac {
          description
            "MAC-based lookup mode.";
        }
        enum ip {
          description
            "IP-based lookup mode.";
        }
      }
      default "ip";
      description
        "The default forwarding table type is ip.";
    }
    leaf explicit-tracking {
      if-feature "explicit-tracking";
      type boolean;
      default "false";
      description
        "Track the IGMPv3 and MLDv2 snooping membership reports
         from individual hosts.  It contributes to saving network
         resources and shortening leave latency.";
    }
    leaf lite-exclude-filter {
      if-feature "lite-exclude-filter";
      type empty;
      description
        "For IGMP snooping, the presence of this
         leaf enables the support of the simplified EXCLUDE filter
         in the Lightweight IGMPv3 protocol, which simplifies the
         standard versions of IGMPv3.
         For MLD Snooping, the presence of this
         leaf enables the support of the simplified EXCLUDE filter
         in the Lightweight MLDv2 protocol, which simplifies the
         standard versions of MLDv2.";
      reference
        "RFC 5790: Lightweight Internet Group Management Protocol
         Version 3 (IGMPv3) and Multicast Listener Discovery Version
         2 (MLDv2) Protocols";
    }
    leaf send-query {
      type boolean;
      default "false";
      description
        "When it is true, this switch will send out a periodic IGMP
         General Query Message or MLD General Query Message.";
    }
    leaf fast-leave {
      if-feature "fast-leave";
      type empty;
      description
        "When fast leave is enabled, the software assumes
         that no more than one host is present on each VLAN port.";
    }
    leaf last-member-query-interval {
      type uint16 {
        range "10..10230";
      }
      units "deciseconds";
      default "10";
      description
        "Last Member Query Interval, which may be tuned to modify
         the leave latency of the network.
         It is represented in units of 1/10 second.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3,
         Section 8.8";
    }
    leaf query-interval {
      type uint16;
      units "seconds";
      default "125";
      description
        "The Query Interval is the interval between General Queries
         sent by the Querier.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3,
         Sections 4.1.7, 8.2, and 8.14.2";
    }
    leaf query-max-response-time {
      type uint16;
      units "deciseconds";
      default "100";
      description
        "Query maximum response time specifies the maximum time
         allowed before sending a responding report.
         It is represented in units of 1/10 second.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3,
         Sections 4.1.1, 8.3, and 8.14.3";
    }
    leaf require-router-alert {
      if-feature "require-router-alert";
      type boolean;
      default "false";
      description
        "When the value is true, a router alert should exist
         in the IP header of the IGMP or MLD packet.  If it
         doesn't exist, the IGMP or MLD packet will be ignored.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3,
         Sections 9.1, 9.2, and 9.3";
    }
    leaf robustness-variable {
      type uint8 {
        range "1..7";
      }
      default "2";
      description
        "Querier's Robustness Variable allows tuning for the
         expected packet loss on a network.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3,
         Sections 4.1.6, 8.1, and 8.14.1";
    }
    leaf-list static-bridge-mrouter-interface {
      when 'derived-from-or-self(../l2-service-type,"ims:bridge")';
      if-feature "static-mrouter-interface";
      type if:interface-ref;
      description
        "Static mrouter interface in bridge forwarding";
    }
  } // instance-config-attributes-igmp-mld-snooping

  grouping instance-state-group-attributes-igmp-mld-snooping {
    description
      "Attributes for both IGMP and MLD snooping groups.";
    leaf mac-address {
      type yang:phys-address;
      description
        "Destination MAC address for L2 multicast.";
    }
    leaf expire {
      type rt-types:timer-value-seconds16;
      units "seconds";
      description
        "The time left before multicast group timeout.";
    }
    leaf up-time {
      type uint32;
      units "seconds";
      mandatory true;
      description
        "The time elapsed since the L2 multicast record was
         created.";
    }
  } // instance-state-group-attributes-igmp-mld-snooping

  grouping instance-state-attributes-igmp-mld-snooping {
    description
      "State attributes for IGMP or MLD snooping instance.";
    leaf entries-count {
      type yang:gauge32;
      config false;
      description
        "The number of L2 multicast entries in IGMP and MLD
         snooping.";
    }
    leaf-list bridge-mrouter-interface {
      when 'derived-from-or-self(../l2-service-type,"ims:bridge")';
      type if:interface-ref;
      config false;
      description
        "Indicates a list of mrouter interfaces dynamically learned
         in a bridge.  When this switch receives IGMP/MLD queries
         from a multicast router on an interface, the interface will
         become an mrouter interface for IGMP/MLD snooping.";
    }
  } // instance-config-attributes-igmp-mld-snooping

  grouping instance-state-source-attributes-igmp-mld-snooping {
    description
      "State attributes for IGMP or MLD snooping instance.";
    leaf-list bridge-outgoing-interface {
      when 'derived-from-or-self(../../../l2-service-type,
            "ims:bridge")';
      type if:interface-ref;
      description
        "Outgoing interface in bridge forwarding.";
    }
    leaf up-time {
      type uint32;
      units "seconds";
      mandatory true;
      description
        "The time elapsed since L2 multicast record was created.";
    }
    leaf expire {
      type rt-types:timer-value-seconds16;
      units "seconds";
      description
        "The time left before multicast group timeout.";
    }
    leaf host-count {
      if-feature "explicit-tracking";
      type yang:gauge32;
      description
        "The number of host addresses.";
    }
  } // instance-state-source-attributes-igmp-mld-snooping

  grouping igmp-snooping-statistics {
    description
      "The statistics attributes for IGMP snooping.";
    leaf query-count {
      type yang:counter64;
      description
        "The number of Membership Query messages.";
      reference
        "RFC 2236: Internet Group Management Protocol, Version 2";
    }
    leaf membership-report-v1-count {
      type yang:counter64;
      description
        "The number of Version 1 Membership Report messages.";
      reference
        "RFC 1112: Host extensions for IP multicasting";
    }
    leaf membership-report-v2-count {
      type yang:counter64;
      description
        "The number of Version 2 Membership Report messages.";
      reference
        "RFC 2236: Internet Group Management Protocol, Version 2";
    }
    leaf membership-report-v3-count {
      type yang:counter64;
      description
        "The number of Version 3 Membership Report messages.";
      reference
        "RFC 3376: Internet Group Management Protocol, Version 3";
    }
    leaf leave-count {
      type yang:counter64;
      description
        "The number of Leave Group messages.";
      reference
        "RFC 2236: Internet Group Management Protocol, Version 2";
    }
    leaf pim-hello-count {
      type yang:counter64;
      description
        "The number of PIM hello messages.";
      reference
        "RFC 7761: Protocol Independent Multicast - Sparse Mode
         (PIM-SM): Protocol Specification (Revised)";
    }
  } // igmp-snooping-statistics

  grouping mld-snooping-statistics {
    description
      "The statistics attributes for MLD snooping.";
    leaf query-count {
      type yang:counter64;
      description
        "The number of Multicast Listener Query messages.";
      reference
        "RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
         for IPv6";
    }
    leaf report-v1-count {
      type yang:counter64;
      description
        "The number of Version 1 Multicast Listener Report.";
      reference
        "RFC 2710: Multicast Listener Discovery (MLD) for IPv6";
    }
    leaf report-v2-count {
      type yang:counter64;
      description
        "The number of Version 2 Multicast Listener Report.";
      reference
        "RFC 3810: Multicast Listener Discovery Version 2 (MLDv2)
         for IPv6";
    }
    leaf done-count {
      type yang:counter64;
      description
        "The number of Version 1 Multicast Listener Done.";
      reference
        "RFC 2710: Multicast Listener Discovery (MLD) for IPv6";
    }
    leaf pim-hello-count {
      type yang:counter64;
      description
        "The number of PIM hello messages.";
      reference
        "RFC 7761: Protocol Independent Multicast - Sparse Mode
         (PIM-SM): Protocol Specification (Revised)";
    }
  } // mld-snooping-statistics

  augment "/rt:routing/rt:control-plane-protocols"
        + "/rt:control-plane-protocol" {
    when 'derived-from-or-self(rt:type, "ims:igmp-snooping")' {
      description
        "This container is only valid for IGMP snooping.";
    }
    description
      "IGMP snooping augmentation to control-plane protocol
       configuration and state.";
    container igmp-snooping-instance {
      if-feature "igmp-snooping";
      description
        "IGMP snooping instance to configure igmp-snooping.";
      leaf l2-service-type {
        type l2-service-type;
        default "bridge";
        description
          "It indicates bridge or other services.";
      }
      uses instance-config-attributes-igmp-mld-snooping;
      leaf igmp-version {
        type uint8 {
          range "1..3";
        }
        default "2";
        description
          "IGMP version.";
      }
      leaf querier-source {
        type inet:ipv4-address;
        description
          "The source address of the IGMP General Query message,
           which is sent out by this switch.";
      }
      list static-l2-multicast-group {
        if-feature "static-l2-multicast-group";
        key "group source-addr";
        description
          "A static multicast route, (*,G) or (S,G).";
        leaf group {
          type rt-types:ipv4-multicast-group-address;
          description
            "Multicast group IPv4 address.";
        }
        leaf source-addr {
          type rt-types:ipv4-multicast-source-address;
          description
            "Multicast source IPv4 address.";
        }
        leaf-list bridge-outgoing-interface {
          when 'derived-from-or-self(../../l2-service-type,
                "ims:bridge")';
          type if:interface-ref;
          description
            "Outgoing interface in bridge forwarding.";
        }
      } // static-l2-multicast-group
      uses instance-state-attributes-igmp-mld-snooping;
      list group {
        key "address";
        config false;
        description
          "IGMP snooping information.";
        leaf address {
          type rt-types:ipv4-multicast-group-address;
          description
            "Multicast group IPv4 address.";
        }
        uses instance-state-group-attributes-igmp-mld-snooping;
        leaf last-reporter {
          type inet:ipv4-address;
          description
            "Address of the last host that has sent a report to join
             the multicast group.";
        }
        list source {
          key "address";
          description
            "Source IPv4 address for multicast stream.";
          leaf address {
            type rt-types:ipv4-multicast-source-address;
            description
              "Source IPv4 address for multicast stream.";
          }
          uses instance-state-source-attributes-igmp-mld-snooping;
          leaf last-reporter {
            type inet:ipv4-address;
            description
              "Address of the last host that has sent a report
               to join the multicast group.";
          }
          list host {
            if-feature "explicit-tracking";
            key "address";
            description
              "List of multicast membership hosts
               of the specific multicast source group.";
            leaf address {
              type inet:ipv4-address;
              description
                "Multicast membership host address.";
            }
            leaf filter-mode {
              type filter-mode-type;
              mandatory true;
              description
                "Filter mode for a multicast membership
                 host may be either include or exclude.";
            }
          } // list host
        } // list source
      } // list group
      container interfaces {
        config false;
        description
          "Contains the interfaces associated with the IGMP snooping
           instance.";
        list interface {
          key "name";
          description
            "A list of interfaces associated with the IGMP snooping
             instance.";
          leaf name {
            type if:interface-ref;
            description
              "The name of the interface.";
          }
          container statistics {
            description
              "The interface statistics for IGMP snooping.";
            leaf discontinuity-time {
              type yang:date-and-time;
              description
                "The time on the most recent occasion at which any
                 one or more of the statistic counters suffered a
                 discontinuity.  If no such discontinuities have
                 occurred since the last re-initialization of the
                 local management subsystem, then this node contains
                 the time the local management subsystem
                 re-initialized itself.";
            }
            container received {
              description
                "Number of received snooped IGMP packets.";
              uses igmp-snooping-statistics;
            }
            container sent {
              description
                "Number of sent snooped IGMP packets.";
              uses igmp-snooping-statistics;
            }
          }
        }
      }
      action clear-igmp-snooping-groups {
        if-feature "action-clear-groups";
        description
          "Clear IGMP snooping cache tables.";
        input {
          leaf group {
            type union {
              type enumeration {
                enum all-groups {
                  description
                    "All multicast group addresses.";
                }
              }
              type rt-types:ipv4-multicast-group-address;
            }
            mandatory true;
            description
              "Multicast group IPv4 address.  If value
               'all-groups' is specified, all IGMP snooping
               group entries are cleared for the specified source
               address.";
          }
          leaf source {
            type rt-types:ipv4-multicast-source-address;
            mandatory true;
            description
              "Multicast source IPv4 address.  If value '*' is
               specified, all IGMP snooping source-group tables
               are cleared.";
          }
        }
      } // action clear-igmp-snooping-groups
    } // igmp-snooping-instance
  } // augment

  augment "/rt:routing/rt:control-plane-protocols"
        + "/rt:control-plane-protocol" {
    when 'derived-from-or-self(rt:type, "ims:mld-snooping")' {
      description
        "This container is only valid for MLD snooping.";
    }
    description
      "MLD snooping augmentation to control-plane protocol
       configuration and state.";
    container mld-snooping-instance {
      if-feature "mld-snooping";
      description
        "MLD snooping instance to configure mld-snooping.";
      leaf l2-service-type {
        type l2-service-type;
        default "bridge";
        description
          "It indicates bridge or other services.";
      }
      uses instance-config-attributes-igmp-mld-snooping;
      leaf mld-version {
        type uint8 {
          range "1..2";
        }
        default "2";
        description
          "MLD version.";
      }
      leaf querier-source {
        type inet:ipv6-address;
        description
          "The source address of MLD General Query message, which
           is sent out by this switch.";
      }
      list static-l2-multicast-group {
        if-feature "static-l2-multicast-group";
        key "group source-addr";
        description
          "A static multicast route, (*,G) or (S,G).";
        leaf group {
          type rt-types:ipv6-multicast-group-address;
          description
            "Multicast group IPv6 address.";
        }
        leaf source-addr {
          type rt-types:ipv6-multicast-source-address;
          description
            "Multicast source IPv6 address.";
        }
        leaf-list bridge-outgoing-interface {
          when 'derived-from-or-self(../../l2-service-type,
                "ims:bridge")';
          type if:interface-ref;
          description
            "Outgoing interface in bridge forwarding.";
        }
      } // static-l2-multicast-group
      uses instance-state-attributes-igmp-mld-snooping;
      list group {
        key "address";
        config false;
        description
          "MLD snooping statistics information.";
        leaf address {
          type rt-types:ipv6-multicast-group-address;
          description
            "Multicast group IPv6 address.";
        }
        uses instance-state-group-attributes-igmp-mld-snooping;
        leaf last-reporter {
          type inet:ipv6-address;
          description
            "Address of the last host that has sent report
             to join the multicast group.";
        }
        list source {
          key "address";
          description
            "Source IPv6 address for multicast stream.";
          leaf address {
            type rt-types:ipv6-multicast-source-address;
            description
              "Source IPv6 address for multicast stream.";
          }
          uses instance-state-source-attributes-igmp-mld-snooping;
          leaf last-reporter {
            type inet:ipv6-address;
            description
              "Address of the last host that has sent report
               to join the multicast group.";
          }
          list host {
            if-feature "explicit-tracking";
            key "address";
            description
              "List of multicast membership hosts
               of the specific multicast source group.";
            leaf address {
              type inet:ipv6-address;
              description
                "Multicast membership host address.";
            }
            leaf filter-mode {
              type filter-mode-type;
              mandatory true;
              description
                "Filter mode for a multicast membership
                 host may be either include or exclude.";
            }
          } // list host
        } // list source
      } // list group
      container interfaces {
        config false;
        description
          "Contains the interfaces associated with the MLD snooping
           instance.";
        list interface {
          key "name";
          description
            "A list of interfaces associated with the MLD snooping
             instance.";
          leaf name {
            type if:interface-ref;
            description
              "The name of the interface.";
          }
          container statistics {
            description
              "The interface statistics for MLD snooping.";
            leaf discontinuity-time {
              type yang:date-and-time;
              description
                "The time on the most recent occasion at which
                 any one or more of the statistic counters suffered
                 a discontinuity.  If no such discontinuities have
                 occurred since the last re-initialization of the
                 local management subsystem, then this node contains
                 the time the local management subsystem
                 re-initialized itself.";
            }
            container received {
              description
                "Number of received snooped MLD packets.";
              uses mld-snooping-statistics;
            }
            container sent {
              description
                "Number of sent snooped MLD packets.";
              uses mld-snooping-statistics;
            }
          }
        }
      }
      action clear-mld-snooping-groups {
        if-feature "action-clear-groups";
        description
          "Clear MLD snooping cache tables.";
        input {
          leaf group {
            type union {
              type enumeration {
                enum all-groups {
                  description
                    "All multicast group addresses.";
                }
              }
              type rt-types:ipv6-multicast-group-address;
            }
            mandatory true;
            description
              "Multicast group IPv6 address.  If value 'all-groups'
               is specified, all MLD snooping group entries are
               cleared for the specified source address.";
          }
          leaf source {
            type rt-types:ipv6-multicast-source-address;
            mandatory true;
            description
              "Multicast source IPv6 address.  If value '*' is
               specified, all MLD snooping source-group tables
               are cleared.";
          }
        }
      } // action clear-mld-snooping-groups
    } // mld-snooping-instance
  } // augment

  augment "/dot1q:bridges/dot1q:bridge" {
    description
      "Use IGMP or MLD snooping instance in bridge.";
    leaf igmp-snooping-instance {
      type igmp-mld-snooping-instance-ref;
      description
        "Configure IGMP snooping instance under bridge view.";
    }
    leaf mld-snooping-instance {
      type igmp-mld-snooping-instance-ref;
      description
        "Configure MLD snooping instance under bridge view.";
    }
  }

  augment "/dot1q:bridges/dot1q:bridge"
        + "/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" {
    description
      "Use IGMP or MLD snooping instance in a certain VLAN
       of bridge.";
    leaf igmp-snooping-instance {
      type igmp-mld-snooping-instance-ref;
      description
        "Configure IGMP snooping instance under VLAN view.";
    }
    leaf mld-snooping-instance {
      type igmp-mld-snooping-instance-ref;
      description
        "Configure MLD snooping instance under VLAN view.";
    }
  }
}

    
    
      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
    or RESTCONF . The lowest NETCONF layer is the secure
   transport layer, and the mandatory-to-implement secure transport is Secure
   Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the
   mandatory-to-implement secure transport is TLS .
      
   The Network Configuration Access Control Model (NACM)  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:/
      
        ims:igmp-snooping-instance
        ims:mld-snooping-instance
      
      The subtrees under /dot1q:bridges/dot1q:bridge
      
        ims:igmp-snooping-instance
        ims:mld-snooping-instance
      
      The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component/dot1q:bridge-vlan/dot1q:vlan
      
        ims:igmp-snooping-instance
        ims:mld-snooping-instance
      
      
   Unauthorized access to any data node of these subtrees can adversely affect
   the IGMP and MLD snooping subsystem of both the local device and the
   network. This may lead to network malfunctions, delivery of packets to
   inappropriate destinations, and other problems.
      
   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:/
      
         ims:igmp-snooping-instance
        
      ims:mld-snooping-instance
      
      
   Unauthorized access to any data node of these subtrees can disclose the
   operational state information of IGMP and MLD snooping on this device. The
   group/source/host information may expose multicast group memberships and,
   transitively, the associations between the user on the host and the contents
   from the source, which could be privately sensitive. Some of the action
   operations in this YANG module may be considered sensitive or vulnerable in
   some network environments. It is thus important to control access to these
   operations. These are the operations and their sensitivity/vulnerability:
      
   Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/
      
         ims:igmp-snooping-instance/ims:clear-igmp-snooping-groups
         ims:mld-snooping-instance/ims:clear-mld-snooping-groups
      
      
   Some of the actions in this YANG module may be considered sensitive or
   vulnerable in some network environments. The IGMP and MLD snooping YANG
   module supports the "clear-igmp-snooping-groups" and
   "clear-mld-snooping-groups" actions. If unauthorized action is invoked, the
   IGMP and MLD snooping group tables will be cleared unexpectedly. Especially
   when using wildcard, all the multicast traffic will be flooded in the
   broadcast domain. The devices that use this YANG module should heed the
   security considerations in .
    
    
      IANA Considerations
      
        XML Registry
        
   This document registers the following namespace URI in the "IETF XML
   Registry" :
        
          URI:
          urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
          Registrant Contact:
          The IETF.
          XML:
          N/A; the requested URI is an XML namespace.
        
      
      
        YANG Module Names Registry
        
   This document registers the following YANG module in the "YANG Module Names"
   registry :
        
          Name:
           ietf-igmp-mld-snooping
          Namespace:
              urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping
          Prefix:
                 ims
          Reference:
              RFC 9166
        
      
    
  
  
    
      References
      
        Normative References
        
          
            Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model
            
              IEEE
            
            
          
          
          
        
        
          
            Host extensions for IP multicasting
            
              
            
            
            
              This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting.  Recommended procedure for IP multicasting in the Internet.  This RFC obsoletes RFCs 998 and 1054.  [STANDARDS-TRACK]
            
          
          
          
          
        
        
          
            Internet Group Management Protocol, Version 2
            
              
            
            
            
              This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers.  It updates STD 5, RFC 1112.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Multicast Listener Discovery (MLD) for IPv6
            
              
            
            
              
            
            
              
            
            
            
              This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Internet Group Management Protocol, Version 3
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
          
          
          
        
        
          
            The IETF XML Registry
            
              
            
            
            
              This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.
            
          
          
          
          
        
        
          
            Multicast Listener Discovery Version 2 (MLDv2) for IPv6
            
              
            
            
              
            
            
            
              This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2).  MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes.  MLDv2 is designed to be interoperable with MLDv1.  MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Multicast Router Discovery
            
              
            
            
              
            
            
            
              The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers.  Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers.  However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.
              This document introduces a general mechanism that allows for the discovery of multicast routers.  This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
            
              
            
            
              
            
            
              
            
            
            
              This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches.  These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping.  Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered.  This memo provides information for the Internet community.
            
          
          
          
        
        
          
            Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols
            
              
            
            
              
            
            
              
            
            
            
              This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2.  The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account.   [STANDARDS-TRACK]
            
          
          
          
        
        
          
            YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)
            
              
            
            
            
              YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Network Configuration Protocol (NETCONF)
            
              
            
            
              
            
            
              
            
            
              
            
            
            
              The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.  The NETCONF protocol operations are realized as remote procedure calls (RPCs).  This document obsoletes RFC 4741.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Using the NETCONF Protocol over Secure Shell (SSH)
            
              
            
            
            
              This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742.  [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
            
              
            
            
              
            
            
              
            
            
            
              The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.  This  document is not an Internet Standards Track specification; it is published for informational purposes.
            
          
          
          
        
        
          
            Common YANG Data Types
            
              
            
            
            
              This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.
            
          
          
          
        
        
          
            Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
            
              This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM).  PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base.  It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.
              This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.
            
          
          
          
          
        
        
          
            The YANG 1.1 Data Modeling Language
            
              
            
            
            
              YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
            
          
          
          
        
        
          
            RESTCONF Protocol
            
              
            
            
              
            
            
              
            
            
            
              This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).
            
          
          
          
        
        
          
            Common YANG Data Types for the Routing Area
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
            
              This document defines a collection of common data types using the YANG data modeling language.  These derived common types are designed to be imported by other modules defined in the routing area.
            
          
          
          
        
        
          
            YANG Tree Diagrams
            
              
            
            
              
            
            
            
              This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.
            
          
          
          
          
        
        
          
            Network Configuration Access Control Model
            
              
            
            
              
            
            
            
              The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.  This document defines such an access control model.
              This document obsoletes RFC 6536.
            
          
          
          
          
        
        
          
            Network Management Datastore Architecture (NMDA)
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
            
              Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.  This document updates RFC 7950.
            
          
          
          
        
        
          
            A YANG Data Model for Interface Management
            
              
            
            
            
              This document defines a YANG data model for the management of network interfaces.  It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
              The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
              This document obsoletes RFC 7223.
            
          
          
          
        
        
          
            A YANG Data Model for Routing Management (NMDA Version)
            
              
            
            
              
            
            
              
            
            
            
              This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem.  It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions.  The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.
              The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).  This document obsoletes RFC 8022.
            
          
          
          
        
        
          
            The Transport Layer Security (TLS) Protocol Version 1.3
            
              
            
            
            
              This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
              This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.
            
          
          
          
        
      
      
        Informative References
        
          
            JSON Encoding of Data Modeled with YANG
            
              
            
            
            
              This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.
            
          
          
          
        
        
          
            Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
            
              
            
            
            
              This memo provides guidelines for authors and reviewers of specifications containing YANG modules.  Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules.  This document obsoletes RFC 6087.
            
          
          
          
          
        
        
          
            A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
            
              This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices.
            
          
          
          
        
      
    
    
      Data Tree Example
      
   This section contains an example of bridge service in the JSON encoding
   , containing both configuration and state data.
      
           +-----------+
           +  Source   +
           +-----+-----+
                 |
-----------------+----------------------------
                 |eth1/1
             +---+---+
             +  R1   +
             +-+---+-+
        eth1/2 |    \ eth1/3
               |     \
               |      \
               |       \
               |        \
        eth2/1 |         \ eth3/1
           +---+---+   +--+---+
           +  R2   +   +  R3  +
           +---+---+   +--+---+
        eth2/2 |          | eth3/2
               |          |
---------------+----------+-------------------
               |          |
               |          |
      +--------+--+   +---+--------+
      + Receiver1 +   +  Receiver2 +
      +-----------+   +------------+

      The configuration data for R1 in the above figure could be as follows:
      
{
"ietf-interfaces:interfaces":{
  "interface":[
   {
    "name":"eth1/1",
    "type":"iana-if-type:ethernetCsmacd"
   }
  ]
 },
 "ietf-routing:routing":{
  "control-plane-protocols":{
   "control-plane-protocol":[
    {
     "type":"ietf-igmp-mld-snooping:igmp-snooping",
     "name":"bis1",
     "ietf-igmp-mld-snooping:igmp-snooping-instance":{
       "l2-service-type":"ietf-igmp-mld-snooping:bridge",
       "enabled":true
     }
    }
   ]
  }
 },
 "ieee802-dot1q-bridge:bridges":{
  "bridge":[
   {
    "name":"isp1",
    "address":"00-23-ef-a5-77-12",
    "bridge-type":"ieee802-dot1q-bridge:customer-vlan-bridge",
    "component":[
     {
      "name":"comp1",
      "type":"ieee802-dot1q-bridge:c-vlan-component",
      "bridge-vlan":{
       "vlan":[
        {
         "vid":101,
         "ietf-igmp-mld-snooping:igmp-snooping-instance":"bis1"
        }
       ]
      }
     }
    ]
   }
  ]
 }
}

      The corresponding operational state data for R1 could be as follows:
      
{
 "ietf-interfaces:interfaces": {
  "interface": [
   {
    "name": "eth1/1",
    "type": "iana-if-type:ethernetCsmacd",
    "oper-status": "up",
    "statistics": {
     "discontinuity-time": "2018-05-23T12:34:56-05:00"
    }
   }
  ]
 },
 "ietf-routing:routing": {
  "control-plane-protocols": {
   "control-plane-protocol": [
    {
     "type": "ietf-igmp-mld-snooping:igmp-snooping",
     "name": "bis1",
     "ietf-igmp-mld-snooping:igmp-snooping-instance": {
      "l2-service-type": "ietf-igmp-mld-snooping:bridge",
      "enabled": true
     }
    }
   ]
  }
 },
 "ieee802-dot1q-bridge:bridges": {
  "bridge": [
   {
    "name": "isp1",
    "address": "00-23-ef-a5-77-12",
    "bridge-type": "ieee802-dot1q-bridge:customer-vlan-bridge",
    "component": [
     {
      "name": "comp1",
      "type": "ieee802-dot1q-bridge:c-vlan-component",
      "bridge-vlan": {
       "vlan": [
        {
         "vid": 101,
         "ietf-igmp-mld-snooping:igmp-snooping-instance": "bis1"
        }
       ]
      }
     }
    ]
   }
  ]
 }
}

      The following action is to clear all the entries whose group address is
225.1.1.1 for igmp-snooping-instance bis1.
      
POST /restconf/operations/ietf-routing:routing/\
control-plane-protocols/\
control-plane-protocol=ietf-igmp-mld-snooping:igmp-snooping,bis1/\
ietf-igmp-mld-snooping:igmp-snooping-instance/\
clear-igmp-snooping-groups HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-igmp-mld-snooping:input" : {
    "group": "225.1.1.1",
    "source": "*"
  }
}

    
    
      Authors' Addresses
      
        Ericsson (China) Communications Company Ltd.
        
          
            Ericsson Tower, No. 5 Lize East Street
            Beijing
            
            100102
            China
          
          
          hongji.zhao@ericsson.com
          
        
      
      
        IBM Corporation
        
          
            2300 Dulles Station Blvd.
            Herndon
            VA
            20171
            United States of America
          
          
          xufeng.liu.ietf@gmail.com
          
        
      
      
        China Mobile
        
          
            
            
            
            
            China
          
          
          liuyisong@chinamobile.com
          
        

      
      
        Individual
        
          anish.ietf@gmail.com
          
        
      
      
        Juniper Networks
        
          
            1133 Innovation Way
            Sunnyvale
            CA
            
            United States of America
          
          
          sivakumar.mahesh@gmail.com

Prefix	YANG module	Reference
inet	ietf-inet-types
yang	ietf-yang-types
if	ietf-interfaces
rt	ietf-routing
rt-types	ietf-routing-types
dot1q	ieee802-dot1q-bridge