idnits 2.17.1 draft-zhao-pim-igmp-mld-proxy-yang-01.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 153 has weird spacing: '...ce-name if:...' == Line 157 has weird spacing: '...address ine...' == Line 165 has weird spacing: '...ce-name if:...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (February 12, 2019) is 1900 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) == Missing Reference: 'RFC2119' is mentioned on line 92, but not defined == Missing Reference: 'RFC6241' is mentioned on line 409, but not defined == Missing Reference: 'RFC8040' is mentioned on line 409, but not defined == Missing Reference: 'RFC7950' is mentioned on line 466, but not defined == Missing Reference: 'RFC6242' is mentioned on line 411, but not defined == Missing Reference: 'RFC5246' is mentioned on line 413, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC6536' is mentioned on line 415, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 453, but not defined == Unused Reference: 'RFC2236' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 485, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC4604' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC4607' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC8343' is defined on line 518, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 21 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: August 11, 2019 Volta 5 Y. Liu 6 Huawei 8 February 12, 2019 10 A Yang Data Model for IGMP/MLD Proxy 11 draft-zhao-pim-igmp-mld-proxy-yang-01.txt 13 Abstract 15 This document defines a YANG data model that can be used to 16 configure and manage Internet Group Management Protocol (IGMP) or 17 Multicast Listener Discovery (MLD) proxy devices. The YANG module in 18 this document conforms to Network Management Datastore Architecture 19 (NMDA). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on August 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Terminology...............................................3 63 1.2. Tree Diagrams.............................................3 64 2. Design of Data Model...........................................3 65 2.1. Overview..................................................4 66 2.2. Augment /rt:routing/rt:control-plane-protocols/rt:control- 67 plane-protocol.................................................4 68 3. IGMP/MLD Proxy YANG Module.....................................5 69 4. Security Considerations.......................................10 70 5. IANA Considerations...........................................10 71 6. Normative References..........................................11 72 Authors' Addresses...............................................13 74 1. Introduction 76 This document defines a YANG [RFC6020] data model for the management of 77 Internet Group Management Protocol (IGMP) or Multicast Listener 78 Discovery (MLD) proxy devices. 80 The YANG module in this document conforms to the Network Management 81 Datastore Architecture defined in [RFC8342]. The "Network Management 82 Datastore Architecture" (NMDA) adds the ability to inspect the current 83 operational values for configuration, allowing clients to use identical 84 paths for retrieving the configured values and the operational values. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 14 91 [RFC2119]. 93 The terminology for describing YANG data models is found in [RFC6020]. 95 1.2. Tree Diagrams 97 A simplified graphical representation of the data model is used in this 98 document. The meaning of the symbols in these diagrams is as follows: 100 o Brackets "[" and "]" enclose list keys. 102 o Abbreviations before data node names: "rw" means configuration 103 (read-write), and "ro" means state data (read-only). 105 o Symbols after data node names: "?" means an optional node, "!" 106 means a presence container, and "*" denotes a list and leaf-list. 108 o Parentheses enclose choice and case nodes, and case nodes are also 109 marked with a colon (":"). 111 o Ellipsis ("...") stands for contents of subtrees that are not 112 shown. 114 2. Design of Data Model 116 The model covers Considerations for Internet Group Management Protocol 117 (IGMP) / Multicast Listener Discovery (MLD) - Based Multicast Forwarding 118 ("IGMP/MLD Proxying") [RFC4605]. 120 The goal of this document is to define a data model that provides a 121 common user interface to IGMP/MLD proxy. This document provides freedom 122 for vendors to adapt this data model to their product implementations. 124 2.1. Overview 126 The IGMP/MLD proxy YANG module defined in this document has all the 127 common building blocks for the IGMP/MLD proxy protocol. 129 The YANG module augments /rt:routing/rt:control-plane- 130 protocols/rt:control-plane-protocol to enable IGMP/MLD proxy and 131 configure other related parameters. 133 This YANG module follows the Guidelines for YANG Module Authors (NMDA) 134 [draft-dsdt-nmda-guidelines-01]. This NMDA ("Network Management 135 Datastore Architecture") architecture provides an architectural 136 framework for datastores as they are used by network management 137 protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG 138 [RFC7950] data modeling language. 140 2.2. Augment /rt:routing/rt:control-plane-protocols/rt:control-plane- 141 protocol 143 The YANG module augments /rt:routing/rt:control-plane- 144 protocols/rt:control-plane-protocol to configure source lifetime 145 globally and retrieve the IGMP proxy group information for (S,G) or 146 (*,G). 148 module: ietf-igmp-mld-proxy 149 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol: 150 +--rw igmp-proxy 151 +--rw interfaces 152 +--rw interface* [interface-name] 153 +--rw interface-name if:interface-ref 154 +--rw version? uint8 155 +--rw enable? boolean 156 +--ro group* [group-address] 157 +--ro group-address inet:ipv4-address 158 +--ro up-time? uint32 159 +--ro filter-mode? enumeration 160 +--ro source* [source-address] 161 +--ro source-address inet:ipv4-address 162 +--ro up-time? uint32 163 +--ro filter-mode? enumeration 164 +--ro downstream-interface* [interface-name] 165 +--ro interface-name if:interface-ref 166 +--ro filter-mode? enumeration 168 3. IGMP/MLD Proxy YANG Module 170 file ietf-igmp-mld-proxy@2019-01-23.yang 171 module ietf-igmp-mld-proxy { 172 yang-version 1.1; 173 namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy"; 174 // replace with IANA namespace when assigned 175 prefix imp; 177 import ietf-inet-types { 178 prefix inet; 179 } 181 import ietf-interfaces { 182 prefix if; 183 } 185 import ietf-routing { 186 prefix rt; 187 } 189 import ietf-pim-base { 190 prefix pim-base; 191 } 193 organization 194 "IETF PIM Working Group"; 196 contact 197 "WG Web: 198 WG List: 200 Editors: Hongji Zhao 201 203 Xufeng Liu 204 206 Yisong Liu 207 209 "; 211 description 212 "The module defines a collection of YANG definitions common for 213 all Internet Group Management Protocol (IGMP) and Multicast 214 Listener Discovery (MLD) Proxy devices. 216 Copyright (c) 2019 IETF Trust and the persons identified as 217 authors of the code. All rights reserved. 219 Redistribution and use in source and binary forms, with or 220 without modification, is permitted pursuant to, and subject to 221 the license terms contained in, the Simplified BSD License set 222 forth in Section 4.c of the IETF Trust's Legal Provisions 223 Relating to IETF Documents 224 (http://trustee.ietf.org/license-info). 226 This version of this YANG module is part of RFC XXXX; see the 227 RFC itself for full legal notices."; 229 revision 2019-01-23 { 230 description 231 "Initial revision."; 232 reference 233 "RFC XXXX: A YANG Data Model for IGMP and MLD Proxy"; 234 } 236 /* 237 * Features 238 */ 240 /* 241 * Typedefs 242 */ 244 /* 245 * Groupings 246 */ 248 grouping per-interface-config-attributes { 250 description "Config attributes under interface view"; 252 leaf enable { 253 type boolean; 254 default false; 255 description 256 "Set the value to true to enable IGMP/MLD proxy"; 257 } 259 } // per-interface-config-attributes 261 grouping state-group-attributes { 262 description 263 "State group attributes"; 265 leaf up-time { 266 type uint32; 267 units seconds; 268 description 269 "The elapsed time for (S,G) or (*,G)."; 270 } 272 leaf filter-mode { 273 type enumeration { 274 enum "include" { 275 description 276 "In include mode, reception of packets sent 277 to the specified multicast address is requested 278 only from those IP source addresses listed in the 279 source-list parameter"; 280 } 281 enum "exclude" { 282 description 283 "In exclude mode, reception of packets sent 284 to the given multicast address is requested 285 from all IP source addresses except those 286 listed in the source-list parameter."; 287 } 288 } 289 description 290 "Filter mode for a multicast group, 291 may be either include or exclude."; 292 } 293 } // state-group-attributes 295 /* augments */ 297 augment "/rt:routing/rt:control-plane-protocols"+ 298 "/rt:control-plane-protocol" { 300 description 301 "IGMP proxy augmentation to routing control plane protocol 302 configuration and state."; 304 container igmp-proxy { 305 description "IGMP proxy"; 306 container interfaces { 307 description 308 "Containing a list of upstream interfaces."; 310 list interface { 311 key "interface-name"; 312 description 313 "List of upstream interfaces."; 315 leaf interface-name { 316 type if:interface-ref; 317 must "current() != /rt:routing/rt:control-plane- 318 protocols/pim-base:pim/pim-base:interfaces/pim-base:interface/pim- 319 base:name" { 320 description 321 "The upstream interface for IGMP/MLD proxy 322 should not be configured PIM."; 323 } 324 } 326 leaf version { 327 type uint8 { 328 range "1..3"; 329 } 330 default 2; 331 description "IGMP version."; 332 } 334 uses per-interface-config-attributes; 336 list group { 337 key "group-address"; 338 config false; 339 description 340 "Multicast group membership information 341 that joined on the interface."; 343 leaf group-address { 344 type inet:ipv4-address; 345 description 346 "Multicast group address."; 347 } 349 uses state-group-attributes; 351 list source { 352 key "source-address"; 353 description 354 "List of multicast source information 355 of the multicast group."; 356 leaf source-address { 357 type inet:ipv4-address; 358 description 359 "Multicast source address"; 361 } 363 uses state-group-attributes; 365 list downstream-interface { 366 key "interface-name"; 367 leaf interface-name { 368 type if:interface-ref; 369 description 370 "Downstream interfaces for each upstream-interface"; 371 } 372 leaf filter-mode { 373 type enumeration { 374 enum "include" { 375 description 376 "In include mode, reception of packets sent 377 to the specified multicast address is requested 378 only from those IP source addresses listed in 379 the source-list parameter"; 380 } 381 enum "exclude" { 382 description 383 "In exclude mode, reception of packets sent 384 to the given multicast address is requested 385 from all IP source addresses except those 386 listed in the source-list parameter."; 387 } 388 } 389 description 390 "Filter mode for a multicast group, 391 may be either include or exclude."; 392 } 393 } 394 } // list source 395 } // list group 396 } // interface 397 } // interfaces 398 } 399 } 401 /* RPCs */ 403 } 404 405 4. Security Considerations 407 The YANG module specified in this document defines a schema for data 408 that is designed to be accessed via network management protocols such 409 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 410 is the secure transport layer, and the mandatory-to-implement secure 411 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 412 is HTTPS, and the mandatory-to-implement secure transport is TLS 413 [RFC5246]. 415 The NETCONF access control model [RFC6536] provides the means to 416 restrict access for particular NETCONF or RESTCONF users to a 417 preconfigured subset of all available NETCONF or RESTCONF protocol 418 operations and content. 420 There are a number of data nodes defined in this YANG module that are 421 writable/creatable/deletable (i.e., config true, which is the 422 default). These data nodes may be considered sensitive or vulnerable 423 in some network environments. Write operations (e.g., edit-config) to 424 these data nodes without proper protection can have a negative effect 425 on network operations. These are the subtrees and data nodes and 426 their sensitivity/vulnerability: 428 /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 430 Unauthorized access to any data node of these subtrees can adversely 431 affect the IGMP/MLD proxy subsystem of both the local device and the 432 network. This may lead to network malfunctions, delivery of packets 433 to inappropriate destinations, and other problems. 435 Some of the readable data nodes in this YANG module may be considered 436 sensitive or vulnerable in some network environments. It is thus 437 important to control read access (e.g., via get, get-config, or 438 notification) to these data nodes. These are the subtrees and data 439 nodes and their sensitivity/vulnerability: 441 /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 443 Unauthorized access to any data node of these subtrees can disclose 444 the operational state information of IGMP/MLD proxy on this device. 446 5. IANA Considerations 448 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 449 actual RFC number (and remove this note). 451 This document registers the following namespace URIs in the IETF XML 453 registry [RFC3688]: 455 -------------------------------------------------------------------- 457 URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 459 Registrant Contact: The IESG. 461 XML: N/A, the requested URI is an XML namespace. 463 -------------------------------------------------------------------- 465 This document registers the following YANG modules in the YANG 466 Module Names registry [RFC7950]: 468 -------------------------------------------------------------------- 470 name: ietf-igmp-mld-proxy 472 namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 474 prefix: imp 476 reference: RFC XXXX 478 -------------------------------------------------------------------- 480 6. Normative References 482 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 483 2", RFC 2236, November 1997. 485 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 486 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 488 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 489 Thyagarajan, "Internet Group Management Protocol, Version 490 3", RFC 3376, October 2002. 492 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 493 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 495 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 496 Group Management Protocol Version 3 (IGMPv3) and Multicast 497 Listener Discovery Protocol Version 2 (MLDv2) for Source- 498 Specific Multicast", RFC 4604, August 2006. 500 [RFC4605] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet 501 Group Management Protocol (IGMP) / Multicast Listener 502 Discovery (MLD) - Based Multicast Forwarding ("IGMP/MLD 503 Proxying")", RFC 4605, August 2006. 505 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 506 IP", RFC 4607, August 2006. 508 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 509 the Network Configuration Protocol (NETCONF)", RFC 6020, 510 October 2010. 512 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 513 July 2013. 515 [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management 516 Datastore Architecture (NMDA)", RFC 8342, March 2018. 518 [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", 519 RFC 8343, March 2018. 521 [draft-ietf-pim-igmp-mld-yang-06] X. Liu, F. Guo, M. Sivakumar, P. 522 McAllister, A. Peter, "A YANG data model for Internet Group 523 Management Protocol (IGMP) and Multicast Listener Discovery 524 (MLD)", draft-ietf-pim-igmp-mld-yang-06, Oct 20, 2017. 526 [draft-dsdt-nmda-guidelines-01] M. Bjorklund, J. Schoenwaelder, P. 527 Shafer, K. Watsen, R. Wilton, "Guidelines for YANG Module 528 Authors (NMDA)", draft-dsdt-nmda-guidelines-01, May 2017 530 [draft-ietf-netmod-revised-datastores-03] M. Bjorklund, J. 531 Schoenwaelder, P. Shafer, K. Watsen, R. Wilton, "Network 532 Management Datastore Architecture", draft-ietf-netmod- 533 revised-datastores-03, July 3, 2017 535 Authors' Addresses 537 Hongji Zhao 538 Ericsson (China) Communications Company Ltd. 539 Ericsson Tower, No. 5 Lize East Street, 540 Chaoyang District Beijing 100102, P.R. China 542 Email: hongji.zhao@ericsson.com 544 Xufeng Liu 545 Volta Networks 546 USA 548 EMail: Xufeng.liu.ietf@gmail.com 550 Yisong Liu 551 Huawei Technologies 552 Huawei Bld., No.156 Beiqing Rd. 553 Beijing 100095 554 China 556 Email: liuyisong@huawei.com