idnits 2.17.1 draft-ietf-pim-igmp-mld-proxy-yang-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 284 has weird spacing: '...ce-name if:...' == Line 325 has weird spacing: '...ce-name if:...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 30, 2021) is 969 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group H. Zhao 2 Internet Draft Ericsson 3 Intended status: Standards Track X. Liu 4 Expires: February 28, 2022 Volta 5 Y. Liu 6 China Mobile 7 M. Panchanathan 8 Cisco 9 M. Sivakumar 10 Juniper 12 August 30, 2021 14 A Yang Data Model for IGMP/MLD Proxy 15 draft-ietf-pim-igmp-mld-proxy-yang-06.txt 17 Abstract 19 This document defines a YANG data model that can be used to 20 configure and manage Internet Group Management Protocol (IGMP) or 21 Multicast Listener Discovery (MLD) proxy devices. The YANG module in 22 this document conforms to Network Management Datastore Architecture 23 (NMDA). 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on February 28, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction...................................................3 65 1.1. Terminology...............................................3 66 1.2. Conventions Used in This Document.........................3 67 1.3. Tree Diagrams.............................................4 68 1.4. Prefixes in Data Node Names...............................4 69 2. Design of Data Model...........................................4 70 2.1. Overview..................................................5 71 2.2. Optional Capabilities.....................................5 72 2.3. Position of Address Family in Hierarchy...................5 73 3. Module Structure...............................................6 74 3.1. IGMP Proxy Configuration and Operational State............6 75 3.2. MLD Proxy Configuration and Operational State.............7 76 4. IGMP/MLD Proxy YANG Module.....................................8 77 5. Security Considerations.......................................15 78 6. IANA Considerations...........................................16 79 6.1. XML Registry.............................................16 80 6.2. YANG Module Names Registry...............................16 81 7. References....................................................17 82 7.1. Normative References.....................................17 83 7.2. Informative References...................................18 84 Appendix. Data Tree Example......................................19 85 Authors' Addresses...............................................22 87 1. Introduction 89 This document defines a YANG [RFC7950] data model for the management of 90 Internet Group Management Protocol (IGMP) or Multicast Listener 91 Discovery (MLD) Proxy [RFC4605] devices. 93 The YANG module in this document conforms to the Network Management 94 Datastore Architecture defined in [RFC8342]. The "Network Management 95 Datastore Architecture" (NMDA) adds the ability to inspect the current 96 operational values for configuration, allowing clients to use identical 97 paths for retrieving the configured values and the operational values. 99 1.1. Terminology 101 The terminology for describing YANG data models is found in [RFC6020] 103 and [RFC7950], including: 105 * augment 107 * data model 109 * data node 111 * identity 113 * module 115 The following abbreviations are used in this document and defined model: 117 IGMP: Internet Group Management Protocol [RFC3376]. 119 MLD: Multicast Listener Discovery [RFC3810]. 121 PIM: Protocol Independent Multicast [RFC7761]. 123 1.2. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in BCP 14 128 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as 129 shown here. 131 1.3. Tree Diagrams 133 Tree diagrams used in this document follow the notation defined in 135 [RFC8340]. 137 1.4. Prefixes in Data Node Names 139 In this document, names of data nodes, and other data model objects are 140 often used without a prefix, as long as it is clear from the context in 141 which YANG module each name is defined. Otherwise, names are prefixed 142 using the standard prefix associated with the corresponding YANG module, 143 as shown in Table 1. 145 +----------+-----------------------+---------------------------------+ 146 | Prefix | YANG module | Reference | 147 +==========+=======================+=================================+ 148 | inet | ietf-inet-types | [RFC6991] | 149 +----------+-----------------------+---------------------------------+ 150 | if | ietf-interfaces | [RFC8343] | 151 +----------+-----------------------+---------------------------------+ 152 | rt | ietf-routing | [RFC8349] | 153 +----------+-----------------------+---------------------------------+ 154 | rt-types | ietf-routing-types | [RFC8294] | 155 +----------+-----------------------+---------------------------------+ 156 | pim-base | ietf-pim-base | [draft-ietf-pim-yang] | 157 +----------+-----------------------+---------------------------------+ 158 Table 1: Prefixes and Corresponding YANG Modules 160 2. Design of Data Model 162 The model covers Considerations for Internet Group Management Protocol 163 (IGMP) / Multicast Listener Discovery (MLD) - Based Multicast Forwarding 164 ("IGMP/MLD Proxying") [RFC4605]. 166 The goal of this document is to define a data model that provides a 167 common user interface to IGMP/MLD Proxy. This document provides freedom 168 for vendors to adapt the data model to their product implementations. 170 2.1. Overview 172 The model defined in this document has all the common building blocks 173 for the IGMP/MLD Proxy devices. It can be used to configure IGMP/MLD 174 Proxy. The operational state data and statistics can also be retrieved 175 by it. 177 The model contains all the basic configuration parameters. The 178 occasionally implemented parameters are modeled as optional features in 179 this model, while the rarely implemented parameters are not included in 180 this model and left for augmentation. 182 2.2. Optional Capabilities 184 This model is designed to represent the basic capability subsets of IGMP 185 / MLD Proxy. The main design goals of this document are that the basic 186 capabilities described in the model are supported by any major now- 187 existing implementation, and that the configuration of all 188 implementations meeting the specifications is easy to express through 189 some combination of the optional features in the model and simple vendor 190 augmentations. 192 There is also value in widely supported features being standardized, to 193 provide a standardized way to access these features, to save work for 194 individual vendors, and so that mapping between different vendors' 195 configuration is not needlessly complicated. Therefore, this model 196 declares a number of features representing capabilities that not all 197 deployed devices support. 199 The extensive use of feature declarations should also substantially 200 simplify the capability negotiation process for a vendor's IGMP / MLD 201 Proxy implementations. 203 2.3. Position of Address Family in Hierarchy 205 IGMP Proxy only supports IPv4, while MLD Proxy only supports IPv6. The 206 data model defined in this document can be used for both IPv4 and IPv6 207 address families. 209 This document defines IGMP Proxy and MLD Proxy as separate schema 210 branches in the structure. The benefits are: 212 * The model can support IGMP Proxy (IPv4), MLD Proxy (IPv6), or both 213 optionally and independently. Such flexibility cannot be achieved 214 cleanly with a combined branch. 216 * The structure is consistent with other YANG data models such as 217 [RFC8652], which uses separate branches for IPv4 and IPv6. 219 * Having separate branches for IGMP Proxy and MLD Proxy allows minor 220 differences in their behavior to be modelled more simply and cleanly. 221 The two branches can better support different features and node types. 223 3. Module Structure 225 This model augments the core routing data model specified in [RFC8349]. 227 +--rw routing 228 +--rw router-id? 229 +--rw control-plane-protocols 230 | +--rw control-plane-protocol* [type name] 231 | +--rw type 232 | +--rw name 233 | +--rw igmp-proxy <= Augmented by this Model 234 ... 235 | +--rw mld-proxy <= Augmented by this Model 237 The "igmp-proxy" container instantiates IGMP Proxy. The "mld-proxy" 238 container instantiates MLD Proxy. 240 The YANG data model defined in this document conforms to the Network 241 Management Datastore Architecture (NMDA) [RFC8342]. The operational 242 state data is combined with the associated configuration data in the 243 same hierarchy [RFC8407]. 245 3.1. IGMP Proxy Configuration and Operational State 247 The YANG module augments /rt:routing/rt:control-plane- 248 protocols/rt:control-plane-protocol to add the igmp-proxy container. 250 All the IGMP Proxy related attributes are defined in the igmp-proxy 251 container. The read-write attributes represent configurable data. The 252 read-only attributes represent state data. 254 The igmp-version represents version of IGMP protocol, and default value 255 is 2. If the value of enable is true, it means IGMP Proxy is enabled. 257 The interface list under igmp-proxy contains upstream interfaces for 258 IGMP proxy. There is also a constraint to make sure the upstream 259 interface for IGMP proxy should not be configured PIM. 261 To configure a downstream interface for IGMP proxy, it is needed to 262 enable IGMP on that interface. This is defined in the YANG Data Model 263 for Internet Group Management Protocol (IGMP) and Multicast Listener 264 Discovery (MLD) [RFC8652]. 266 augment /rt:routing/rt:control-plane-protocols 267 /rt:control-plane-protocol: 268 +--rw igmp-proxy {igmp-proxy}? 269 +--rw interfaces 270 +--rw interface* [interface-name] 271 +--rw interface-name if:interface-ref 272 +--rw igmp-version? uint8 273 +--rw enable? boolean 274 +--rw sender-source-address? inet:ipv4-address 275 +--ro group* [group-address] 276 +--ro group-address 277 | rt-types:ipv4-multicast-group-address 278 +--ro up-time? uint32 279 +--ro filter-mode enumeration 280 +--ro source* [source-address] 281 +--ro source-address inet:ipv4-address 282 +--ro up-time? uint32 283 +--ro downstream-interface* [interface-name] 284 +--ro interface-name if:interface-ref 286 3.2. MLD Proxy Configuration and Operational State 288 The YANG module augments /rt:routing/rt:control-plane- 289 protocols/rt:control-plane-protocol to add the mld-proxy container. 291 All the MLD Proxy related attributes are defined in the mld-proxy 292 container. The read-write attributes represent configurable data. The 293 read-only attributes represent state data. 295 The mld-version represents version of MLD protocol, and default value is 296 2. If the value of enable is true, it means MLD Proxy is enabled. 298 The interface list under mld-proxy contains upstream interfaces for MLD 299 proxy. There is also a constraint to make sure the upstream interface 300 for MLD proxy should not be configured PIM. 302 To configure a downstream interface for MLD proxy, enable MLD on that 303 interface. This is defined in the YANG Data Model for Internet Group 304 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 305 [RFC8652]. 307 augment /rt:routing/rt:control-plane-protocols 308 /rt:control-plane-protocol: 309 +--rw mld-proxy {mld-proxy}? 310 +--rw interfaces 311 +--rw interface* [interface-name] 312 +--rw interface-name if:interface-ref 313 +--rw mld-version? uint8 314 +--rw enable? boolean 315 +--rw sender-source-address? inet:ipv6-address 316 +--ro group* [group-address] 317 +--ro group-address 318 | rt-types:ipv6-multicast-group-address 319 +--ro up-time? uint32 320 +--ro filter-mode enumeration 321 +--ro source* [source-address] 322 +--ro source-address inet:ipv6-address 323 +--ro up-time? uint32 324 +--ro downstream-interface* [interface-name] 325 +--ro interface-name if:interface-ref 327 4. IGMP/MLD Proxy YANG Module 329 This module references [RFC4605], [RFC6991], [RFC8294], [RFC8343], 330 [RFC8349] and [draft-ietf-pim-yang]. 332 file ietf-igmp-mld-proxy@2021-04-21.yang 333 module ietf-igmp-mld-proxy { 334 yang-version 1.1; 335 namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy"; 336 // replace with IANA namespace when assigned 337 prefix igmp-mld-proxy; 339 import ietf-inet-types { 340 prefix inet; 341 } 342 import ietf-interfaces { 343 prefix if; 344 } 345 import ietf-routing { 346 prefix rt; 347 } 348 import ietf-routing-types { 349 prefix rt-types; 350 } 351 import ietf-pim-base { 352 prefix pim-base; 353 } 355 organization 356 "IETF PIM Working Group"; 358 contact 359 "WG Web: 360 WG List: 361 Editors: Hongji Zhao 362 364 Xufeng Liu 365 367 Yisong Liu 368 370 Mani Panchanathan 371 373 Mahesh Sivakumar 374 376 "; 378 description 379 "The module defines a collection of YANG definitions common for 380 all Internet Group Management Protocol (IGMP) and Multicast 381 Listener Discovery (MLD) Proxy devices. 383 Copyright (c) 2021 IETF Trust and the persons identified as 384 authors of the code. All rights reserved. 386 Redistribution and use in source and binary forms, with or 387 without modification, is permitted pursuant to, and subject to 388 the license terms contained in, the Simplified BSD License set 389 forth in Section 4.c of the IETF Trust's Legal Provisions 390 Relating to IETF Documents 391 (http://trustee.ietf.org/license-info). 393 This version of this YANG module is part of RFC XXXX; see the 394 RFC itself for full legal notices."; 396 revision 2021-04-21 { 397 description 398 "Initial revision."; 399 reference 400 "RFC XXXX: A YANG Data Model for IGMP and MLD Proxy"; 401 } 403 /* 404 * Features 405 */ 407 feature igmp-proxy { 408 description 409 "Support IGMP Proxy protocol."; 410 reference 411 "RFC 4605"; 413 } 415 feature mld-proxy { 416 description 417 "Support MLD Proxy protocol."; 418 reference 419 "RFC 4605"; 420 } 422 /* 423 * Identities 424 */ 426 identity igmp-proxy { 427 base rt:control-plane-protocol; 428 description 429 "IGMP Proxy protocol"; 430 } 432 identity mld-proxy { 433 base rt:control-plane-protocol; 434 description 435 "MLD Proxy protocol"; 436 } 438 /* 439 * Groupings 440 */ 442 grouping per-interface-config-attributes { 443 description "Config attributes under interface view"; 444 leaf enable { 445 type boolean; 446 default false; 447 description 448 "Set the value to true to enable IGMP/MLD proxy"; 449 } 450 } // per-interface-config-attributes 452 grouping state-group-attributes { 453 description 454 "State group attributes"; 455 leaf up-time { 456 type uint32; 457 units seconds; 458 description 459 "The elapsed time for (S,G) or (*,G)."; 460 } 461 leaf filter-mode { 462 type enumeration { 463 enum "include" { 464 description 465 "In include mode, reception of packets sent 466 to the specified multicast address is requested 467 only from those IP source addresses listed in the 468 source-list parameter"; 469 } 470 enum "exclude" { 471 description 472 "In exclude mode, reception of packets sent 473 to the given multicast address is requested 474 from all IP source addresses except those 475 listed in the source-list parameter."; 476 } 477 } 478 mandatory true; 479 description 480 "Filter mode for a multicast group, 481 may be either include or exclude."; 482 } 483 } // state-group-attributes 485 /* augments */ 487 augment "/rt:routing/rt:control-plane-protocols"+ 488 "/rt:control-plane-protocol" { 489 when 490 "derived-from-or-self(rt:type, 'igmp-mld-proxy:igmp-proxy')" { 491 description 492 "This augmentation is only valid for IGMP Proxy."; 493 } 494 description 495 "IGMP Proxy augmentation to routing control plane protocol 496 configuration and state."; 497 container igmp-proxy { 498 if-feature "igmp-proxy"; 499 description "IGMP proxy"; 500 container interfaces { 501 description 502 "Containing a list of upstream interfaces."; 503 list interface { 504 key "interface-name"; 505 description 506 "List of upstream interfaces."; 507 leaf interface-name { 508 type if:interface-ref; 509 must "not( current() = /rt:routing"+ 510 "/rt:control-plane-protocols/pim-base:pim"+ 511 "/pim-base:interfaces/pim-base:interface"+ 512 "/pim-base:name )" { 513 description 514 "The upstream interface for IGMP proxy 515 should not be configured PIM."; 516 } 517 description "The upstream interface name."; 518 } 519 leaf igmp-version { 520 type uint8 { 521 range "1..3"; 522 } 523 default 2; 524 description "IGMP version."; 525 } 526 uses per-interface-config-attributes; 527 leaf sender-source-address { 528 type inet:ipv4-address; 529 description 530 "The sender source address of 531 IGMP memembership report or leave."; 532 } 533 list group { 534 key "group-address"; 535 config false; 536 description 537 "Multicast group membership information 538 that joined on the interface."; 539 leaf group-address { 540 type rt-types:ipv4-multicast-group-address; 541 description 542 "Multicast group address."; 543 } 544 uses state-group-attributes; 545 list source { 546 key "source-address"; 547 description 548 "List of multicast source information 549 of the multicast group."; 550 leaf source-address { 551 type inet:ipv4-address; 552 description 553 "Multicast source address"; 554 } 555 leaf up-time { 556 type uint32; 557 units seconds; 558 description 559 "The elapsed time for (S,G) or (*,G)."; 560 } 561 list downstream-interface { 562 key "interface-name"; 563 description "The downstream interfaces list."; 564 leaf interface-name { 565 type if:interface-ref; 566 description 567 "Downstream interfaces 568 for each upstream-interface"; 569 } 570 } 571 } // list source 572 } // list group 573 } // interface 574 } // interfaces 575 } 576 } 578 augment "/rt:routing/rt:control-plane-protocols"+ 579 "/rt:control-plane-protocol" { 580 when 581 "derived-from-or-self(rt:type, 'igmp-mld-proxy:mld-proxy')" { 582 description 583 "This augmentation is only valid for MLD Proxy."; 584 } 585 description 586 "MLD Proxy augmentation to routing control plane protocol 587 configuration and state."; 588 container mld-proxy { 589 if-feature "mld-proxy"; 590 description "MLD proxy"; 591 container interfaces { 592 description 593 "Containing a list of upstream interfaces."; 594 list interface { 595 key "interface-name"; 596 description 597 "List of upstream interfaces."; 598 leaf interface-name { 599 type if:interface-ref; 600 must "not( current() = /rt:routing"+ 601 "/rt:control-plane-protocols/pim-base:pim"+ 602 "/pim-base:interfaces/pim-base:interface"+ 603 "/pim-base:name )" { 604 description 605 "The upstream interface for MLD proxy 606 should not be configured PIM."; 607 } 608 description "The upstream interface name."; 609 } 610 leaf mld-version { 611 type uint8 { 612 range "1..2"; 613 } 614 default 2; 615 description "MLD version."; 617 } 618 uses per-interface-config-attributes; 619 leaf sender-source-address { 620 type inet:ipv6-address; 621 description 622 "The sender source address of 623 MLD memembership report or leave."; 624 } 625 list group { 626 key "group-address"; 627 config false; 628 description 629 "Multicast group membership information 630 that joined on the interface."; 631 leaf group-address { 632 type rt-types:ipv6-multicast-group-address; 633 description 634 "Multicast group address."; 635 } 636 uses state-group-attributes; 637 list source { 638 key "source-address"; 639 description 640 "List of multicast source information 641 of the multicast group."; 642 leaf source-address { 643 type inet:ipv6-address; 644 description 645 "Multicast source address"; 646 } 647 leaf up-time { 648 type uint32; 649 units seconds; 650 description 651 "The elapsed time for (S,G) or (*,G)."; 652 } 653 list downstream-interface { 654 key "interface-name"; 655 description "The downstream interfaces list."; 656 leaf interface-name { 657 type if:interface-ref; 658 description 659 "Downstream interfaces 660 for each upstream-interface"; 661 } 662 } 663 } // list source 664 } // list group 665 } // interface 666 } // interfaces 667 } 669 } 670 } 671 673 5. Security Considerations 675 The YANG module specified in this document defines a schema for data 676 that is designed to be accessed via network management protocols such as 677 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the 678 secure transport layer, and the mandatory-to-implement secure transport 679 is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and 680 the mandatory-to-implement secure transport is TLS [RFC8446]. 682 The Network Configuration Access Control Model (NACM) [RFC8341] provides 683 the means to restrict access for particular NETCONF or RESTCONF users to 684 a preconfigured subset of all available NETCONF or RESTCONF protocol 685 operations and content. 687 There are a number of data nodes defined in this YANG module that are 688 writable/creatable/deletable (i.e., config true, which is the default). 689 These data nodes may be considered sensitive or vulnerable in some 690 network environments. Write operations (e.g., edit-config) to these data 691 nodes without proper protection can have a negative effect on network 692 operations. These are the subtrees and data nodes and their 693 sensitivity/vulnerability: 695 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 697 igmp-mld-proxy:igmp-proxy 699 igmp-mld-proxy:mld-proxy 701 Unauthorized access to any data node of these subtrees can adversely 702 affect the IGMP / MLD Proxy subsystem of both the local device and the 703 network. This may lead to network malfunctions, delivery of packets to 704 inappropriate destinations, and other problems. 706 Some of the readable data nodes in this YANG module may be considered 707 sensitive or vulnerable in some network environments. It is thus 708 important to control read access (e.g., via get, get-config, or 709 notification) to these data nodes. These are the subtrees and data nodes 710 and their sensitivity/vulnerability: 712 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 714 igmp-mld-proxy:igmp-proxy 716 igmp-mld-proxy:mld-proxy 717 Unauthorized access to any data node of these subtrees can disclose the 718 operational state information of IGMP / MLD Proxy on this device. The 719 group/source information may expose multicast group memberships. 721 6. IANA Considerations 723 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 724 actual RFC number (and remove this note). 726 6.1. XML Registry 728 This document registers the following namespace URIs in the IETF XML 730 registry [RFC3688]: 732 -------------------------------------------------------------------- 733 URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 734 Registrant Contact: The IETF. 735 XML: N/A, the requested URI is an XML namespace. 736 -------------------------------------------------------------------- 738 6.2. YANG Module Names Registry 740 This document registers the following YANG modules in the YANG Module 741 Names registry [RFC7950]: 742 -------------------------------------------------------------------- 743 name: ietf-igmp-mld-proxy 744 namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 745 prefix: igmp-mld-proxy 746 reference: RFC XXXX 747 -------------------------------------------------------------------- 748 7. References 750 7.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", RFC 2119, March 1997. 755 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 756 Thyagarajan, "Internet Group Management Protocol, Version 757 3", RFC 3376, October 2002. 759 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 760 2004. 762 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 763 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 765 [RFC4605] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet 766 Group Management Protocol (IGMP) / Multicast Listener 767 Discovery (MLD) - Based Multicast Forwarding ("IGMP/MLD 768 Proxying")", RFC 4605, August 2006. 770 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 771 the Network Configuration Protocol (NETCONF)", RFC 6020, 772 October 2010. 774 [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. 775 Bierman, Ed., "Network Configuration Protocol (NETCONF)", 776 RFC 6241, June 2011. 778 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 779 Shell (SSH)", RFC 6242, June 2011. 781 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 782 July 2013. 784 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", 785 RFC 7950, August 2016. 787 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", 788 RFC 8040, January 2017. 790 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 791 Key Words", RFC 8174, May 2017. 793 [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG 794 Data Types for the Routing Area", RFC 8294, December 2017. 796 [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC 797 8340, March 2018. 799 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access 800 Control Model", RFC 8341, March 2018. 802 [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management 803 Datastore Architecture (NMDA)", RFC 8342, March 2018. 805 [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", 806 RFC 8343, March 2018. 808 [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing 809 Management (NMDA Version)", RFC 8349, March 2018. 811 [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of 812 Documents Containing YANG Data Models", RFC 8407, October 813 2018. 815 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 816 Version 1.3", RFC 8446, August 2018. 818 [RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A 819 YANG Data Model for the Internet Group Management Protocol 820 (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, 821 November 2019. 823 [draft-ietf-pim-yang] X. Liu, P. McAllister, A. Peter, M. Sivakumar, 824 Y. Liu, F. Hu, "A YANG Data Model for Protocol Independent 825 Multicast (PIM)", draft-ietf-pim-yang-17 (RFC Editor state 826 is MISSREF), May 2018. 828 7.2. Informative References 830 [RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, 831 Z. Zhang, L. Zheng, "Protocol Independent Multicast - 832 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 833 RFC 7761, March 2016. 835 [RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC 836 7951, August 2016. 838 Appendix. Data Tree Example 840 This section contains an example for IGMP Proxy in the JSON encoding 841 [RFC7951], containing both configuration and state data. In the example 842 IGMP Proxy is enabled on interface eth1/1. 844 It is also needed to enable IGMP on eth1/2 and eth1/3. The configuration 845 details are omitted here because this document is focused on IGMP/MLD 846 Proxy. 848 +-----------+ 849 + Source + 850 +-----+-----+ 851 | 852 -----------------+---------------------------- 853 |eth1/1 854 +---+----+ 855 + R1 + 856 +-+----+-+ 857 eth1/2 | \ eth1/3 858 | \ 859 | \ 860 | \ 861 ---------------+---------+------------------- 862 | \ 863 | \ 864 +--------+--+ +---+--------+ 865 + Receiver1 + + Receiver2 + 866 +-----------+ +------------+ 868 The configuration data for R1 in the above figure could be as follows: 870 { 871 "ietf-interfaces:interfaces": { 872 "interface": [ 873 { 874 "name": "eth1/1", 875 "type": "iana-if-type:ipForward", 876 "ietf-ip:ipv4": { 877 "address": [ 878 { 879 "ip": "11.0.0.1", 880 "prefix-length": 24 881 } 882 ] 883 } 884 } 886 ] 887 }, 888 "ietf-routing:routing": { 889 "control-plane-protocols": { 890 "control-plane-protocol": [ 891 { 892 "type": "ietf-igmp-mld-proxy:igmp-proxy", 893 "name": "proxy1", 894 "ietf-igmp-mld-proxy:igmp-proxy": { 895 "interfaces": { 896 "interface": [ 897 { 898 "interface-name": "eth1/1", 899 "igmp-version": 3, 900 "enable": true 901 } 902 ] 903 } 904 } 905 } 906 ] 907 } 908 } 909 } 911 The corresponding operational state data for R1 could be as follows: 913 { 914 "ietf-interfaces:interfaces": { 915 "interface": [ 916 { 917 "name": "eth1/1", 918 "type": "iana-if-type:ipForward", 919 "admin-status": "up", 920 "oper-status": "up", 921 "if-index": 25678136, 922 "statistics": { 923 "discontinuity-time": "2021-05-23T10:34:56-06:00" 924 }, 925 "ietf-ip:ipv4": { 926 "address": [ 927 { 928 "ip": "11.0.0.1", 929 "prefix-length": 24 930 } 931 ] 932 } 933 } 934 ] 935 }, 937 "ietf-routing:routing": { 938 "control-plane-protocols": { 939 "control-plane-protocol": [ 940 { 941 "type": "ietf-igmp-mld-proxy:igmp-proxy", 942 "name": "proxy1", 943 "ietf-igmp-mld-proxy:igmp-proxy": { 944 "interfaces": { 945 "interface": [ 946 { 947 "interface-name": "eth1/1", 948 "igmp-version": 3, 949 "enable": true, 950 "group": [ 951 { 952 "group-address": "225.0.0.1", 953 "filter-mode": "include", 954 "source": [ 955 { 956 "source-address": "1.1.1.1", 957 "downstream-interface": [ 958 { 959 "interface-name": "eth1/2" 960 }, 961 { 962 "interface-name": "eth1/3" 963 } 964 ] 965 } 966 ] 967 } 968 ] 969 } 970 ] 971 } 972 } 973 } 974 ] 975 } 976 } 977 } 979 Authors' Addresses 981 Hongji Zhao 982 Ericsson (China) Communications Company Ltd. 983 Ericsson Tower, No. 5 Lize East Street, 984 Chaoyang District Beijing 100102, China 985 Email: hongji.zhao@ericsson.com 987 Xufeng Liu 988 Volta Networks 989 USA 990 EMail: Xufeng.liu.ietf@gmail.com 992 Yisong Liu 993 China Mobile 994 China 995 Email: liuyisong@chinamobile.com 997 Mani Panchanathan 998 Cisco 999 India 1000 Email: mapancha@cisco.com 1002 Mahesh Sivakumar 1003 Juniper Networks 1004 1133 Innovation Way 1005 Sunnyvale, California 1006 USA 1007 EMail: sivakumar.mahesh@gmail.com