idnits 2.17.1 draft-ietf-pim-igmp-mld-snooping-yang-14.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 382 has weird spacing: '...er-mode fil...' == Line 495 has weird spacing: '...er-mode fil...' == Line 561 has weird spacing: '... source rt-...' == Line 569 has weird spacing: '... source rt-...' -- The document date (June 23, 2020) is 1396 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) ** Downref: Normative reference to an Informational RFC: RFC 4541 Summary: 1 error (**), 0 flaws (~~), 5 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: December 22, 2020 Volta Networks 5 Y. Liu 6 China Mobile 7 M. Sivakumar 8 Juniper 9 A. Peter 10 Individual 12 June 23, 2020 14 A Yang Data Model for IGMP and MLD Snooping 15 draft-ietf-pim-igmp-mld-snooping-yang-14.txt 17 Abstract 19 This document defines a YANG data model that can be used to configure 20 and manage Internet Group Management Protocol (IGMP) and Multicast 21 Listener Discovery (MLD) Snooping devices. The YANG module in this 22 document conforms to Network Management Datastore Architecture (NMDA). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 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 December 22, 2020. 47 Copyright Notice 49 Copyright (c) 2020 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. Tree Diagrams.............................................3 67 1.3. Prefixes in Data Node Names...............................4 68 2. Design of Data Model...........................................4 69 2.1. Overview..................................................5 70 2.2. Optional Capabilities.....................................5 71 2.3. Position of Address Family in Hierarchy...................6 72 3. Module Structure...............................................6 73 3.1. IGMP Snooping Instances...................................7 74 3.2. MLD Snooping Instances....................................9 75 3.3. Using IGMP and MLD Snooping Instances....................11 76 3.4. IGMP and MLD Snooping Actions............................12 77 4. IGMP and MLD Snooping YANG Module.............................12 78 5. Security Considerations.......................................34 79 6. IANA Considerations...........................................35 80 7. References....................................................36 81 7.1. Normative References.....................................36 82 7.2. Informative References...................................38 83 Appendix A. Data Tree Example...................................39 84 A.1 Bridge scenario...........................................39 85 A.2 L2VPN scenario............................................42 86 Authors' Addresses...............................................46 88 1. Introduction 90 This document defines a YANG [RFC7950] data model for the management of 91 Internet Group Management Protocol (IGMP) and Multicast Listener 92 Discovery (MLD) Snooping [RFC4541] devices. 94 The YANG module in this document conforms to the Network Management 95 Datastore Architecture defined in [RFC8342]. The "Network Management 96 Datastore Architecture" (NMDA) adds the ability to inspect the current 97 operational values for configuration, allowing clients to use identical 98 paths for retrieving the configured values and the operational values. 100 1.1. Terminology 102 The terminology for describing YANG data models is found in [RFC6020] 104 and [RFC7950], including: 106 * augment 108 * data model 110 * data node 112 * identity 114 * module 116 The following terminologies are used in this document: 118 * mrouter: multicast router, which means nodes attached to a switch 119 have multicast routing enabled [RFC4286]. 121 * mrouter interfaces: snooping switch ports where multicast routers 122 are attached [RFC4541]. 124 The following abbreviations are used in this document and defined model: 126 IGMP: Internet Group Management Protocol [RFC3376]. 128 MLD: Multicast Listener Discovery [RFC3810]. 130 AC: Attachment Circuit [RFC3916]. 132 PW: Pseudo Wire [RFC3916]. 134 1.2. Tree Diagrams 136 Tree diagrams used in this document follow the notation defined in 138 [RFC8340]. 140 1.3. Prefixes in Data Node Names 142 In this document, names of data nodes, actions, and other data model 143 objects are often used without a prefix, as long as it is clear from the 144 context in which YANG module each name is defined. Otherwise, names are 145 prefixed using the standard prefix associated with the corresponding 146 YANG module, as shown in Table 1. 148 +----------+-----------------------+---------------------------------+ 149 | Prefix | YANG module | Reference | 150 +==========+=======================+=================================+ 151 | inet | ietf-inet-types | [RFC6991] | 152 +----------+-----------------------+---------------------------------+ 153 | yang | ietf-yang-types | [RFC6991] | 154 +----------+-----------------------+---------------------------------+ 155 | if | ietf-interfaces | [RFC8343] | 156 +----------+-----------------------+---------------------------------+ 157 | rt | ietf-routing | [RFC8349] | 158 +----------+-----------------------+---------------------------------+ 159 | rt-types | ietf-routing-types | [RFC8294] | 160 +----------+-----------------------+---------------------------------+ 161 | ni | ietf-network-instance | [RFC8529] | 162 +----------+-----------------------+---------------------------------+ 163 | pw | ietf-pseudowires | [draft-ietf-bess-l2vpn-yang] | 164 +----------+-----------------------+---------------------------------+ 165 | l2vpn | ietf-l2vpn | [draft-ietf-bess-l2vpn-yang] | 166 +----------+-----------------------+---------------------------------+ 167 | dot1q | ieee802-dot1q-bridge | [dot1Qcp] | 168 +----------+-----------------------+---------------------------------+ 169 Table 1: Prefixes and Corresponding YANG Modules 171 2. Design of Data Model 173 An IGMP/MLD snooping switch [RFC4541] analyzes IGMP/MLD packets and sets 174 up forwarding tables for multicast traffic. If a switch does not run 175 IGMP/MLD snooping, multicast traffic will be flooded in the broadcast 176 domain. If a switch runs IGMP/MLD snooping, multicast traffic will be 177 forwarded based on the forwarding tables to avoid bandwidth waste. The 178 IGMP/MLD snooping switch does not need to run any of the IGMP/MLD 179 protocols. Because the IGMP/MLD snooping is independent of the IGMP/MLD 180 protocols, the data model defined in this document does not augment, or 181 even require, the IGMP/MLD data model defined in [RFC8652]. 182 The model covers considerations for Internet Group Management Protocol 183 (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches 184 [RFC4541]. 186 IGMP and MLD snooping switches do not adhere to the conceptual model 187 that provides the strict separation of functionality between different 188 communications layers in the ISO model, and instead utilize information 189 in the upper level protocol headers as factors to be considered in 190 processing at the lower levels [RFC4541]. 192 IGMP Snooping switches utilize IGMP, and could support IGMPv1 [RFC1112], 193 IGMPv2 [RFC2236], and IGMPv3 [RFC3376]. MLD Snooping switches utilize 194 MLD, and could support MLDv1 [RFC2710] and MLDv2 [RFC3810]. The goal of 195 this document is to define a data model that provides a common user 196 interface to IGMP and MLD Snooping. 198 2.1. Overview 200 The IGMP and MLD Snooping YANG module defined in this document has all 201 the common building blocks for the IGMP and MLD Snooping switches. 203 The YANG module includes IGMP and MLD Snooping instance definition, 204 using instance in the scenario of BRIDGE [dot1Qcp] and L2VPN [draft- 205 ietf-bess-l2vpn-yang]. The module also includes the RPC methods for 206 clearing IGMP and MLD Snooping group tables. 208 This YANG module conforms to Network Management Datastore Architecture 209 (NMDA)[RFC8342]. This NMDA architecture provides an architectural 210 framework for datastores as they are used by network management 211 protocols such as NETCONF [RFC6241], RESTCONF [RFC8040] and the YANG 212 [RFC7950] data modeling language. 214 2.2. Optional Capabilities 216 This model is designed to represent the basic capability subsets of IGMP 217 and MLD Snooping. The main design goals of this document are that the 218 basic capabilities described in the model are supported by any major 219 now-existing implementation, and that the configuration of all 220 implementations meeting the specifications is easy to express through 221 some combination of the optional features in the model and simple vendor 222 augmentations. 224 There is also value in widely supported features being standardized, to 225 provide a standardized way to access these features, to save work for 226 individual vendors, and so that mapping between different vendors' 227 configuration is not needlessly complicated. Therefore, this model 228 declares a number of features representing capabilities that not all 229 deployed devices support. 231 The extensive use of feature declarations should also substantially 232 simplify the capability negotiation process for a vendor's IGMP and MLD 233 Snooping implementations. 235 On the other hand, operational state parameters are not so widely 236 designated as features, as there are many cases where the defaulting 237 of an operational state parameter would not cause any harm to the 238 system, and it is much more likely that an implementation without 239 native support for a piece of operational state would be able to derive 240 a suitable value for a state variable that is not natively supported. 242 2.3. Position of Address Family in Hierarchy 244 IGMP Snooping only supports IPv4, while MLD Snooping only supports IPv6. 245 The data model defined in this document can be used for both IPv4 and 246 IPv6 address families. 248 This document defines IGMP Snooping and MLD Snooping as separate schema 249 branches in the structure. The benefits are: 251 * The model can support IGMP Snooping (IPv4), MLD Snooping (IPv6), or 252 both optionally and independently. Such flexibility cannot be achieved 253 cleanly with a combined branch. 255 * The structure is consistent with other YANG data models such as 256 [RFC8652], which uses separate branches for IPv4 and IPv6. 258 * The separate branches for IGMP Snooping and MLD Snooping can 259 accommodate their differences better and cleaner. The two branches can 260 better support different features and node types. 262 3. Module Structure 264 This model augments the core routing data model specified in [RFC8349]. 266 +--rw routing 267 +--rw router-id? 268 +--rw control-plane-protocols 269 | +--rw control-plane-protocol* [type name] 270 | +--rw type 271 | +--rw name 272 | +--rw igmp-snooping-instance <= Augmented by this Model 273 ... 274 | +--rw mld-snooping-instance <= Augmented by this Model 275 ... 276 The "igmp-snooping-instance" container instantiates an IGMP Snooping 277 Instance. The "mld-snooping-instance" container instantiates an MLD 278 Snooping Instance. 280 The YANG data model defined in this document conforms to the Network 281 Management Datastore Architecture (NMDA) [RFC8342]. The operational 282 state data is combined with the associated configuration data in the 283 same hierarchy [RFC8407]. 285 A configuration data node is marked as mandatory only when its value 286 must be provided by the user. Where nodes are not essential to protocol 287 operation, they are marked as optional. Some other nodes are essential 288 but have a default specified, so that they are also optional and need 289 not be configured explicitly. 291 3.1. IGMP Snooping Instances 293 The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control- 294 plane-protocols/rt:control-plane-protocol to add the igmp-snooping- 295 instance container. 297 All the IGMP Snooping related attributes have been defined in the igmp- 298 snooping-instance. The read-write attributes represent configurable 299 data. The read-only attributes represent state data. 301 One igmp-snooping-instance could be used in one BRIDGE [dot1Qcp] 302 instance or L2VPN [draft-ietf-bess-l2vpn-yang] instance. One igmp- 303 snooping-instance corresponds to one BRIDGE instance or one L2VPN 304 instance. 306 The value of scenario in igmp-snooping-instance is bridge or l2vpn. When 307 it is bridge, igmp-snooping-instance will be used in the BRIDGE 308 scenario. When it is l2vpn, igmp-snooping-instance will be used in the 309 L2VPN scenario. 311 The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, 312 l2vpn-mrouter-interface-pw are filled by the snooping device 313 dynamically. They are different from static-bridge-mrouter-interface, 314 static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw 315 which are configured. 317 The attributes under the interfaces show the statistics of IGMP Snooping 318 related packets. 320 augment /rt:routing/rt:control-plane-protocols 321 /rt:control-plane-protocol: 322 +--rw igmp-snooping-instance {igmp-snooping}? 323 +--rw scenario? 324 | snooping-scenario-type 325 +--rw enable? boolean 326 +--rw forwarding-table-type? enumeration 327 +--rw explicit-tracking? boolean 328 | {explicit-tracking}? 329 +--rw exclude-lite? boolean 330 | {exclude-lite}? 331 +--rw send-query? boolean 332 +--rw immediate-leave? empty 333 | {immediate-leave}? 334 +--rw last-member-query-interval? uint16 335 +--rw query-interval? uint16 336 +--rw query-max-response-time? uint16 337 +--rw require-router-alert? boolean 338 | {require-router-alert}? 339 +--rw robustness-variable? uint8 340 +--rw static-bridge-mrouter-interface* if:interface-ref 341 | {static-mrouter-interface}? 342 +--rw static-l2vpn-mrouter-interface-ac* if:interface-ref 343 | {static-mrouter-interface}? 344 +--rw static-l2vpn-mrouter-interface-pw* pw:pseudowire-ref 345 | {static-mrouter-interface}? 346 +--rw igmp-version? uint8 347 +--rw querier-source? inet:ipv4-address 348 +--rw static-l2-multicast-group* [group source-addr] 349 | {static-l2-multicast-group}? 350 | +--rw group 351 | | rt-types:ipv4-multicast-group-address 352 | +--rw source-addr 353 | | rt-types:ipv4-multicast-source-address 354 | +--rw bridge-outgoing-interface* if:interface-ref 355 | +--rw l2vpn-outgoing-ac* if:interface-ref 356 | +--rw l2vpn-outgoing-pw* pw:pseudowire-ref 357 +--ro entries-count? uint32 358 +--ro bridge-mrouter-interface* if:interface-ref 359 +--ro l2vpn-mrouter-interface-ac* if:interface-ref 360 +--ro l2vpn-mrouter-interface-pw* pw:pseudowire-ref 361 +--ro group* [address] 362 | +--ro address 363 | | rt-types:ipv4-multicast-group-address 364 | +--ro mac-address? yang:phys-address 365 | +--ro expire? rt-types:timer-value-seconds16 366 | +--ro up-time uint32 367 | +--ro last-reporter? inet:ipv4-address 368 | +--ro source* [address] 369 | +--ro address 370 | | rt-types:ipv4-multicast-source-address 371 | +--ro bridge-outgoing-interface* if:interface-ref 372 | +--ro l2vpn-outgoing-ac* if:interface-ref 373 | +--ro l2vpn-outgoing-pw* pw:pseudowire-ref 374 | +--ro up-time uint32 375 | +--ro expire? 376 | | rt-types:timer-value-seconds16 377 | +--ro host-count? uint32 378 | | {explicit-tracking}? 379 | +--ro last-reporter? inet:ipv4-address 380 | +--ro host* [host-address] {explicit-tracking}? 381 | +--ro host-address inet:ipv4-address 382 | +--ro host-filter-mode filter-mode-type 383 +--ro interfaces 384 +--ro interface* [name] 385 +--ro name if:interface-ref 386 +--ro statistics 387 +--ro received 388 | +--ro num-query? yang:counter64 389 | +--ro num-membership-report-v1? yang:counter64 390 | +--ro num-membership-report-v2? yang:counter64 391 | +--ro num-membership-report-v3? yang:counter64 392 | +--ro num-leave? yang:counter64 393 | +--ro num-pim-hello? yang:counter64 394 +--ro sent 395 +--ro num-query? yang:counter64 396 +--ro num-membership-report-v1? yang:counter64 397 +--ro num-membership-report-v2? yang:counter64 398 +--ro num-membership-report-v3? yang:counter64 399 +--ro num-leave? yang:counter64 400 +--ro num-pim-hello? yang:counter64 402 3.2. MLD Snooping Instances 404 The YANG module ietf-igmp-mld-snooping augments /rt:routing/rt:control- 405 plane-protocols/rt:control-plane-protocol to add the mld-snooping- 406 instance container. The mld-snooping-instance could be used in the 407 BRIDGE [dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] scenario to 408 enable MLD Snooping. 410 All the MLD Snooping related attributes have been defined in the mld- 411 snooping-instance. The read-write attributes represent configurable 412 data. The read-only attributes represent state data. 414 The mld-snooping-instance is the same as IGMP snooping except changing 415 IPv4 addresses to IPv6 addresses. One mld-snooping-instance could be 416 used in one BRIDGE instance or L2VPN instance. One mld-snooping-instance 417 corresponds to one BRIDGE instance or L2VPN instance. 419 The value of scenario in mld-snooping-instance is bridge or l2vpn. When 420 it is bridge, mld-snooping-instance will be used in the BRIDGE scenario. 421 When it is l2vpn, mld-snooping-instance will be used in the L2VPN 422 scenario. 424 The values of bridge-mrouter-interface, l2vpn-mrouter-interface-ac, 425 l2vpn-mrouter-interface-pw are filled by the snooping device 426 dynamically. They are different from static-bridge-mrouter-interface, 427 static-l2vpn-mrouter-interface-ac, and static-l2vpn-mrouter-interface-pw 428 which are configured. 430 The attributes under the interfaces show the statistics of MLD Snooping 431 related packets. 433 augment /rt:routing/rt:control-plane-protocols 434 /rt:control-plane-protocol: 435 +--rw mld-snooping-instance {mld-snooping}? 436 +--rw scenario? 437 | snooping-scenario-type 438 +--rw enable? boolean 439 +--rw forwarding-table-type? enumeration 440 +--rw explicit-tracking? boolean 441 | {explicit-tracking}? 442 +--rw exclude-lite? boolean 443 | {exclude-lite}? 444 +--rw send-query? boolean 445 +--rw immediate-leave? empty 446 | {immediate-leave}? 447 +--rw last-member-query-interval? uint16 448 +--rw query-interval? uint16 449 +--rw query-max-response-time? uint16 450 +--rw require-router-alert? boolean 451 | {require-router-alert}? 452 +--rw robustness-variable? uint8 453 +--rw static-bridge-mrouter-interface* if:interface-ref 454 | {static-mrouter-interface}? 455 +--rw static-l2vpn-mrouter-interface-ac* if:interface-ref 456 | {static-mrouter-interface}? 457 +--rw static-l2vpn-mrouter-interface-pw* pw:pseudowire-ref 458 | {static-mrouter-interface}? 459 +--rw mld-version? uint8 460 +--rw querier-source? inet:ipv6-address 461 +--rw static-l2-multicast-group* [group source-addr] 462 | {static-l2-multicast-group}? 463 | +--rw group 464 | | rt-types:ipv6-multicast-group-address 465 | +--rw source-addr 466 | | rt-types:ipv6-multicast-source-address 467 | +--rw bridge-outgoing-interface* if:interface-ref 468 | +--rw l2vpn-outgoing-ac* if:interface-ref 469 | +--rw l2vpn-outgoing-pw* pw:pseudowire-ref 470 +--ro entries-count? uint32 471 +--ro bridge-mrouter-interface* if:interface-ref 472 +--ro l2vpn-mrouter-interface-ac* if:interface-ref 473 +--ro l2vpn-mrouter-interface-pw* pw:pseudowire-ref 474 +--ro group* [address] 475 | +--ro address 476 | | rt-types:ipv6-multicast-group-address 477 | +--ro mac-address? yang:phys-address 478 | +--ro expire? rt-types:timer-value-seconds16 479 | +--ro up-time uint32 480 | +--ro last-reporter? inet:ipv6-address 481 | +--ro source* [address] 482 | +--ro address 483 | | rt-types:ipv6-multicast-source-address 484 | +--ro bridge-outgoing-interface* if:interface-ref 485 | +--ro l2vpn-outgoing-ac* if:interface-ref 486 | +--ro l2vpn-outgoing-pw* pw:pseudowire-ref 487 | +--ro up-time uint32 488 | +--ro expire? 489 | | rt-types:timer-value-seconds16 490 | +--ro host-count? uint32 491 | | {explicit-tracking}? 492 | +--ro last-reporter? inet:ipv6-address 493 | +--ro host* [host-address] {explicit-tracking}? 494 | +--ro host-address inet:ipv6-address 495 | +--ro host-filter-mode filter-mode-type 496 +--ro interfaces 497 +--ro interface* [name] 498 +--ro name if:interface-ref 499 +--ro statistics 500 +--ro received 501 | +--ro num-query? yang:counter64 502 | +--ro num-report-v1? yang:counter64 503 | +--ro num-report-v2? yang:counter64 504 | +--ro num-done? yang:counter64 505 | +--ro num-pim-hello? yang:counter64 506 +--ro sent 507 +--ro num-query? yang:counter64 508 +--ro num-report-v1? yang:counter64 509 +--ro num-report-v2? yang:counter64 510 +--ro num-done? yang:counter64 511 +--ro num-pim-hello? yang:counter64 513 3.3. Using IGMP and MLD Snooping Instances 515 The igmp-snooping-instance could be used in the scenario of BRIDGE 516 [dot1Qcp] or L2VPN [draft-ietf-bess-l2vpn-yang] to configure the IGMP 517 Snooping. 519 For the BRIDGE scenario this model augments /dot1q:bridges/dot1q:bridge 520 to use igmp-snooping-instance. It means IGMP Snooping is enabled in the 521 whole bridge. 523 It also augments /dot1q:bridges/dot1q:bridge/dot1q:component/ 524 dot1q:bridge-vlan/dot1q:vlan to use igmp-snooping-instance. It means 525 IGMP Snooping is enabled in the specified VLAN on the bridge. 527 augment /dot1q:bridges/dot1q:bridge: 528 +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref 529 +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref 531 augment /dot1q:bridges/dot1q:bridge/dot1q:component 532 /dot1q:bridge-vlan/dot1q:vlan: 533 +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref 534 +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref 536 For the L2VPN scenario this model augments /ni:network-instances/ 537 ni:network-instance/ni:ni-type/l2vpn:l2vpn [RFC8529] to use igmp- 538 snooping-instance. It means IGMP Snooping is enabled in the specified 539 l2vpn instance. 541 augment /ni:network-instances/ni:network-instance/ni:ni-type 542 /l2vpn:l2vpn: 543 +--rw igmp-snooping-instance? igmp-mld-snooping-instance-ref 544 +--rw mld-snooping-instance? igmp-mld-snooping-instance-ref 546 The mld-snooping-instance could be used in concurrence with igmp- 547 snooping-instance to configure the MLD Snooping. 549 3.4. IGMP and MLD Snooping Actions 551 IGMP and MLD Snooping actions clear the specified IGMP and MLD Snooping 552 group tables. If both source X and group Y are specified, only source X 553 from group Y in that specific instance will be cleared. 555 augment /rt:routing/rt:control-plane-protocols 556 /rt:control-plane-protocol: 557 +--rw igmp-snooping-instance {igmp-snooping}? 558 +---x clear-igmp-snooping-groups {action-clear-groups}? 559 +---w input 560 +---w group union 561 +---w source rt-types:ipv4-multicast-source-address 563 augment /rt:routing/rt:control-plane-protocols 564 /rt:control-plane-protocol: 565 +--rw mld-snooping-instance {mld-snooping}? 566 +---x clear-mld-snooping-groups {action-clear-groups}? 567 +---w input 568 +---w group union 569 +---w source rt-types:ipv6-multicast-source-address 571 4. IGMP and MLD Snooping YANG Module 573 This module references [RFC1112],[RFC2236],[RFC2710],[RFC3376], 574 [RFC3810],[RFC4541],[RFC5790],[RFC6636],[RFC6991],[RFC7761], 575 [RFC8343],[RFC8529],[dot1Qcp], and [draft-ietf-bess-l2vpn-yang]. 577 file ietf-igmp-mld-snooping@2020-06-19.yang 578 module ietf-igmp-mld-snooping { 579 yang-version 1.1; 580 namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping"; 582 prefix ims; 584 import ietf-inet-types { 585 prefix "inet"; 586 reference 587 "RFC 6991: Common YANG Data Types"; 588 } 590 import ietf-yang-types { 591 prefix "yang"; 592 reference 593 "RFC 6991: Common YANG Data Types"; 594 } 596 import ietf-interfaces { 597 prefix "if"; 598 reference 599 "RFC 8343: A YANG Data Model for Interface Management"; 600 } 602 import ietf-routing { 603 prefix "rt"; 604 reference 605 "RFC 8349: A YANG Data Model for Routing Management (NMDA 606 Version)"; 607 } 609 import ietf-routing-types { 610 prefix "rt-types"; 611 reference 612 "RFC 8294: Common YANG Data Types for the Routing Area"; 613 } 615 import ietf-l2vpn { 616 prefix "l2vpn"; 617 reference 618 "draft-ietf-bess-l2vpn-yang: YANG Data Model for MPLS-based 619 L2VPN"; 620 } 622 import ietf-network-instance { 623 prefix "ni"; 624 reference 625 "RFC 8529: YANG Data Model for Network Instances"; 626 } 628 import ietf-pseudowires { 629 prefix "pw"; 630 reference 631 "draft-ietf-bess-l2vpn-yang: YANG Data Model for MPLS-based 632 L2VPN"; 633 } 635 import ieee802-dot1q-bridge { 636 prefix "dot1q"; 637 reference 638 "dot1Qcp: IEEE 802.1Qcp-2018 Bridges and Bridged Networks 639 - Amendment: YANG Data Model"; 640 } 642 organization 643 "IETF PIM Working Group"; 645 contact 646 "WG Web: 647 WG List: 649 Editors: Hongji Zhao 650 652 Xufeng Liu 653 655 Yisong Liu 656 658 Anish Peter 659 661 Mahesh Sivakumar 662 664 "; 666 description 667 "The module defines a collection of YANG definitions common for 668 all devices that implement Internet Group Management Protocol 669 (IGMP) and Multicast Listener Discovery (MLD) Snooping which is 670 described in RFC 4541. 672 Copyright (c) 2020 IETF Trust and the persons identified as 673 authors of the code. All rights reserved. 675 Redistribution and use in source and binary forms, with or 676 without modification, is permitted pursuant to, and subject to 677 the license terms contained in, the Simplified BSD License set 678 forth in Section 4.c of the IETF Trust's Legal Provisions 679 Relating to IETF Documents 680 (http://trustee.ietf.org/license-info). 682 This version of this YANG module is part of RFC XXXX; see the 683 RFC itself for full legal notices."; 685 revision 2020-06-19 { 686 description 687 "Initial revision."; 688 reference 689 "RFC XXXX: A YANG Data Model for IGMP and MLD Snooping"; 691 } 693 /* 694 * Features 695 */ 697 feature igmp-snooping { 698 description 699 "Support IGMP snooping."; 700 reference 701 "RFC 4541"; 702 } 704 feature mld-snooping { 705 description 706 "Support MLD snooping."; 707 reference 708 "RFC 4541"; 709 } 711 feature immediate-leave { 712 description 713 "Support configuration of fast leave. The fast leave feature 714 does not send last member query messages to hosts."; 715 reference 716 "RFC 3376"; 717 } 719 feature static-l2-multicast-group { 720 description 721 "Support configuration of L2 multicast static-group."; 722 } 724 feature static-mrouter-interface { 725 description 726 "Support multicast router interface explicitly configured 727 by management"; 728 reference 729 "RFC 4541"; 730 } 732 feature action-clear-groups { 733 description 734 "Support clearing statistics by action for IGMP & MLD snooping."; 735 } 737 feature require-router-alert { 738 description 739 "Support configuration of require-router-alert."; 740 reference 741 "RFC 3376"; 743 } 745 feature exclude-lite { 746 description 747 "Support configuration of per instance exclude-lite."; 748 reference 749 "RFC 5790"; 750 } 752 feature explicit-tracking { 753 description 754 "Support configuration of per instance explicit-tracking."; 755 reference 756 "RFC 6636"; 757 } 759 /* identities */ 761 identity scenario-type { 762 description 763 "Base identity for scenario type in IGMP & MLD snooping"; 764 } 766 identity bridge { 767 base scenario-type; 768 description 769 "This identity represents BRIDGE scenario."; 770 } 772 identity l2vpn { 773 base scenario-type; 774 description 775 "This identity represents L2VPN scenario."; 776 } 778 identity filter-mode { 779 description 780 "Base identity for filter mode in IGMP & MLD snooping"; 781 } 783 identity include { 784 base filter-mode; 785 description 786 "This identity represents include mode."; 787 } 789 identity exclude { 790 base filter-mode; 791 description 792 "This identity represents exclude mode."; 793 } 794 identity igmp-snooping { 795 base rt:control-plane-protocol; 796 description 797 "IGMP snooping"; 798 } 800 identity mld-snooping { 801 base rt:control-plane-protocol; 802 description 803 "MLD snooping"; 804 } 806 /* 807 * Typedefs 808 */ 810 typedef snooping-scenario-type { 811 type identityref { 812 base "scenario-type"; 813 } 814 description "The IGMP & MLD snooping scenario type"; 815 } 817 typedef filter-mode-type { 818 type identityref { 819 base "filter-mode"; 820 } 821 description "The host filter mode"; 822 } 824 typedef igmp-mld-snooping-instance-ref { 825 type leafref { 826 path "/rt:routing/rt:control-plane-protocols"+ 827 "/rt:control-plane-protocol/rt:name"; 828 } 829 description 830 "This type is used by data models which need to 831 reference IGMP & MLD snooping instance."; 832 } 834 /* 835 * Groupings 836 */ 838 grouping instance-config-attributes-igmp-mld-snooping { 839 description 840 "IGMP and MLD snooping configuration of each VLAN."; 842 leaf enable { 843 type boolean; 844 default false; 845 description 846 "Set the value to true to enable IGMP & MLD snooping."; 847 } 849 leaf forwarding-table-type { 850 type enumeration { 851 enum "mac" { 852 description 853 "MAC-based lookup mode"; 854 } 855 enum "ip" { 856 description 857 "IP-based lookup mode"; 858 } 859 } 860 default "ip"; 861 description "The default forwarding table type is ip"; 862 } 864 leaf explicit-tracking { 865 if-feature explicit-tracking; 866 type boolean; 867 default false; 868 description 869 "Track the IGMPv3 and MLDv2 snooping membership reports 870 from individual hosts. It contributes to saving network 871 resources and shortening leave latency."; 872 } 874 leaf exclude-lite { 875 if-feature exclude-lite; 876 type boolean; 877 default false; 878 description 879 "Track the Lightweight IGMPv3 and MLDv2 protocol report"; 880 reference "RFC 5790"; 881 } 883 leaf send-query { 884 type boolean; 885 default false; 886 description 887 "Enable quick response for topology changes. 888 To support IGMP snooping in a VLAN where PIM and IGMP are 889 not configured. It cooperates with parameter querier-source."; 890 } 892 leaf immediate-leave { 893 if-feature immediate-leave; 894 type empty; 895 description 896 "When immediate leave is enabled, the IGMP software assumes 897 that no more than one host is present on each VLAN port."; 898 } 900 leaf last-member-query-interval { 901 type uint16 { 902 range "10..10230"; 903 } 904 units one-tenth-second; 905 default 10; 906 description 907 "Last Member Query Interval, which may be tuned to modify 908 the leave latency of the network. 909 It is represented in units of 1/10 second."; 910 reference "RFC 3376. Sec. 8.8."; 911 } 913 leaf query-interval { 914 type uint16; 915 units seconds; 916 default 125; 917 description 918 "The Query Interval is the interval between General Queries 919 sent by the Querier."; 920 reference "RFC 3376. Sec. 4.1.7, 8.2, 8.14.2."; 921 } 923 leaf query-max-response-time { 924 type uint16; 925 units one-tenth-second; 926 default 100; 927 description 928 "Query maximum response time specifies the maximum time 929 allowed before sending a responding report. 930 It is represented in units of 1/10 second."; 931 reference "RFC 3376. Sec. 4.1.1, 8.3, 8.14.3."; 932 } 934 leaf require-router-alert { 935 if-feature require-router-alert; 936 type boolean; 937 default false; 938 description 939 "When the value is true, router alert should exist 940 in the IP header of IGMP or MLD packet."; 941 } 943 leaf robustness-variable { 944 type uint8 { 945 range "1..7"; 946 } 947 default 2; 948 description 949 "Querier's Robustness Variable allows tuning for the 950 expected packet loss on a network."; 951 reference "RFC 3376. Sec. 4.1.6, 8.1, 8.14.1."; 952 } 954 leaf-list static-bridge-mrouter-interface { 955 when 'derived-from-or-self(../scenario,"ims:bridge")'; 956 if-feature static-mrouter-interface; 957 type if:interface-ref; 958 description "static mrouter interface in BRIDGE forwarding"; 959 } 961 leaf-list static-l2vpn-mrouter-interface-ac { 962 when 'derived-from-or-self(../scenario,"ims:l2vpn")'; 963 if-feature static-mrouter-interface; 964 type if:interface-ref; 965 description 966 "static mrouter interface whose type is interface 967 in L2VPN forwarding"; 968 } 970 leaf-list static-l2vpn-mrouter-interface-pw { 971 when 'derived-from-or-self(../scenario,"ims:l2vpn")'; 972 if-feature static-mrouter-interface; 973 type pw:pseudowire-ref; 974 description 975 "static mrouter interface whose type is PW 976 in L2VPN forwarding"; 977 } 978 } // instance-config-attributes-igmp-mld-snooping 980 grouping instance-state-group-attributes-igmp-mld-snooping { 981 description 982 "Attributes for both IGMP and MLD snooping groups."; 984 leaf mac-address { 985 type yang:phys-address; 986 description "Destination MAC address for L2 multicast."; 987 } 989 leaf expire { 990 type rt-types:timer-value-seconds16; 991 units seconds; 992 description 993 "The time left before multicast group timeout."; 994 } 996 leaf up-time { 997 type uint32; 998 units seconds; 999 mandatory true; 1000 description 1001 "The time elapsed since L2 multicast record created."; 1002 } 1003 } // instance-state-group-attributes-igmp-mld-snooping 1005 grouping instance-state-attributes-igmp-mld-snooping { 1007 description 1008 "State attributes for IGMP & MLD snooping instance."; 1010 leaf entries-count { 1011 type uint32; 1012 config false; 1013 description 1014 "The number of L2 multicast entries in IGMP & MLD snooping"; 1015 } 1017 leaf-list bridge-mrouter-interface { 1018 when 'derived-from-or-self(../scenario,"ims:bridge")'; 1019 type if:interface-ref; 1020 config false; 1021 description 1022 "The mrouter interface in BRIDGE forwarding. When switch 1023 receives IGMP/MLD queries from multicast router on an 1024 interface, this interface will become mrouter interface 1025 for IGMP/MLD snooping."; 1026 } 1028 leaf-list l2vpn-mrouter-interface-ac { 1029 when 'derived-from-or-self(../scenario,"ims:l2vpn")'; 1030 type if:interface-ref; 1031 config false; 1032 description 1033 "The mrouter interface whose type is interface in L2VPN 1034 forwarding. When switch receives IGMP/MLD queries from 1035 multicast router on an interface, this interface will 1036 become mrouter interface for IGMP/MLD snooping."; 1037 } 1039 leaf-list l2vpn-mrouter-interface-pw { 1040 when 'derived-from-or-self(../scenario,"ims:l2vpn")'; 1041 type pw:pseudowire-ref; 1042 config false; 1043 description 1044 "The mrouter interface whose type is PW in L2VPN forwarding. 1045 When switch receives IGMP/MLD queries from multicast router 1046 on a PW, this PW will become mrouter interface for IGMP/MLD 1047 snooping."; 1048 } 1049 } // instance-config-attributes-igmp-mld-snooping 1051 grouping instance-state-source-attributes-igmp-mld-snooping { 1052 description 1053 "State attributes for IGMP & MLD snooping instance."; 1055 leaf-list bridge-outgoing-interface { 1056 when 'derived-from-or-self(../../../scenario,"ims:bridge")'; 1057 type if:interface-ref; 1058 description "Outgoing interface in BRIDGE forwarding"; 1059 } 1061 leaf-list l2vpn-outgoing-ac { 1062 when 'derived-from-or-self(../../../scenario,"ims:l2vpn")'; 1063 type if:interface-ref; 1064 description "Outgoing Attachment Circuit (AC) in L2VPN"; 1065 } 1067 leaf-list l2vpn-outgoing-pw { 1068 when 'derived-from-or-self(../../../scenario,"ims:l2vpn")'; 1069 type pw:pseudowire-ref; 1070 description "Outgoing Pseudo Wire (PW) in L2VPN"; 1071 } 1073 leaf up-time { 1074 type uint32; 1075 units seconds; 1076 mandatory true; 1077 description 1078 "The time elapsed since L2 multicast record created"; 1079 } 1081 leaf expire { 1082 type rt-types:timer-value-seconds16; 1083 units seconds; 1084 description 1085 "The time left before multicast group timeout."; 1086 } 1088 leaf host-count { 1089 if-feature explicit-tracking; 1090 type uint32; 1091 description 1092 "The number of host addresses."; 1093 } 1094 } // instance-state-source-attributes-igmp-mld-snooping 1096 grouping igmp-snooping-statistics { 1097 description 1098 "The statistics attributes for IGMP snooping."; 1100 leaf num-query { 1101 type yang:counter64; 1102 description 1103 "The number of Membership Query messages."; 1105 reference 1106 "RFC 2236"; 1107 } 1108 leaf num-membership-report-v1 { 1109 type yang:counter64; 1110 description 1111 "The number of Version 1 Membership Report messages."; 1112 reference 1113 "RFC 1112"; 1114 } 1115 leaf num-membership-report-v2 { 1116 type yang:counter64; 1117 description 1118 "The number of Version 2 Membership Report messages."; 1119 reference 1120 "RFC 2236"; 1121 } 1122 leaf num-membership-report-v3 { 1123 type yang:counter64; 1124 description 1125 "The number of Version 3 Membership Report messages."; 1126 reference 1127 "RFC 3376"; 1128 } 1129 leaf num-leave { 1130 type yang:counter64; 1131 description 1132 "The number of Leave Group messages."; 1133 reference 1134 "RFC 2236"; 1135 } 1136 leaf num-pim-hello { 1137 type yang:counter64; 1138 description 1139 "The number of PIM hello messages."; 1140 reference 1141 "RFC 7761"; 1142 } 1143 } // igmp-snooping-statistics 1145 grouping mld-snooping-statistics { 1146 description 1147 "The statistics attributes for MLD snooping."; 1149 leaf num-query { 1150 type yang:counter64; 1151 description 1152 "The number of Multicast Listener Query messages."; 1153 reference 1154 "RFC 3810"; 1155 } 1156 leaf num-report-v1 { 1157 type yang:counter64; 1158 description 1159 "The number of Version 1 Multicast Listener Report."; 1160 reference 1161 "RFC 2710"; 1162 } 1163 leaf num-report-v2 { 1164 type yang:counter64; 1165 description 1166 "The number of Version 2 Multicast Listener Report."; 1167 reference 1168 "RFC 3810"; 1169 } 1170 leaf num-done { 1171 type yang:counter64; 1172 description 1173 "The number of Version 1 Multicast Listener Done."; 1174 reference 1175 "RFC 2710"; 1176 } 1177 leaf num-pim-hello { 1178 type yang:counter64; 1179 description 1180 "The number of PIM hello messages."; 1181 reference 1182 "RFC 7761"; 1183 } 1184 } // mld-snooping-statistics 1186 augment "/rt:routing/rt:control-plane-protocols"+ 1187 "/rt:control-plane-protocol" { 1188 when 'derived-from-or-self(../rt:type, "ims:igmp-snooping")' { 1189 description 1190 "This container is only valid for IGMP snooping."; 1191 } 1192 description 1193 "IGMP snooping augmentation to control plane protocol 1194 configuration and state."; 1196 container igmp-snooping-instance { 1197 if-feature igmp-snooping; 1198 description 1199 "IGMP snooping instance to configure igmp-snooping."; 1201 leaf scenario { 1202 type snooping-scenario-type; 1203 default bridge; 1204 description 1205 "The scenario indicates BRIDGE or L2VPN."; 1206 } 1208 uses instance-config-attributes-igmp-mld-snooping; 1209 leaf igmp-version { 1210 type uint8 { 1211 range "1..3"; 1212 } 1213 default 2; 1214 description "IGMP version."; 1215 } 1217 leaf querier-source { 1218 type inet:ipv4-address; 1219 description 1220 "Use the IGMP snooping querier to support IGMP 1221 snooping in a VLAN where PIM and IGMP are not configured. 1222 The IPv4 address is used as source address in messages."; 1223 } 1225 list static-l2-multicast-group { 1226 if-feature static-l2-multicast-group; 1227 key "group source-addr"; 1228 description 1229 "A static multicast route, (*,G) or (S,G)."; 1231 leaf group { 1232 type rt-types:ipv4-multicast-group-address; 1233 description 1234 "Multicast group IPv4 address"; 1235 } 1237 leaf source-addr { 1238 type rt-types:ipv4-multicast-source-address; 1239 description 1240 "Multicast source IPv4 address."; 1241 } 1243 leaf-list bridge-outgoing-interface { 1244 when 'derived-from-or-self(../../scenario,"ims:bridge")'; 1245 type if:interface-ref; 1246 description "Outgoing interface in BRIDGE forwarding"; 1247 } 1249 leaf-list l2vpn-outgoing-ac { 1250 when 'derived-from-or-self(../../scenario,"ims:l2vpn")'; 1251 type if:interface-ref; 1252 description "Outgoing Attachment Circuit (AC) in L2VPN"; 1253 } 1255 leaf-list l2vpn-outgoing-pw { 1256 when 'derived-from-or-self(../../scenario,"ims:l2vpn")'; 1257 type pw:pseudowire-ref; 1258 description "Outgoing Pseudo Wire (PW) in L2VPN"; 1259 } 1261 } // static-l2-multicast-group 1263 uses instance-state-attributes-igmp-mld-snooping; 1265 list group { 1267 key "address"; 1269 config false; 1271 description "IGMP snooping information"; 1273 leaf address { 1274 type rt-types:ipv4-multicast-group-address; 1275 description 1276 "Multicast group IPv4 address"; 1277 } 1279 uses instance-state-group-attributes-igmp-mld-snooping; 1281 leaf last-reporter { 1282 type inet:ipv4-address; 1283 description 1284 "Address of the last host which has sent report to join 1285 the multicast group."; 1286 } 1288 list source { 1289 key "address"; 1290 description "Source IPv4 address for multicast stream"; 1292 leaf address { 1293 type rt-types:ipv4-multicast-source-address; 1294 description "Source IPv4 address for multicast stream"; 1295 } 1297 uses instance-state-source-attributes-igmp-mld-snooping; 1299 leaf last-reporter { 1300 type inet:ipv4-address; 1301 description 1302 "Address of the last host which has sent report 1303 to join the multicast group."; 1304 } 1306 list host { 1307 if-feature explicit-tracking; 1308 key "host-address"; 1309 description 1310 "List of multicast membership hosts 1311 of the specific multicast source-group."; 1313 leaf host-address { 1314 type inet:ipv4-address; 1315 description 1316 "Multicast membership host address."; 1317 } 1318 leaf host-filter-mode { 1319 type filter-mode-type; 1320 mandatory true; 1321 description 1322 "Filter mode for a multicast membership 1323 host may be either include or exclude."; 1324 } 1325 }// list host 1327 } // list source 1328 } // list group 1330 container interfaces { 1331 config false; 1333 description 1334 "Interfaces associated with the IGMP snooping instance"; 1336 list interface { 1337 key "name"; 1339 description 1340 "Interfaces associated with the IGMP snooping instance"; 1342 leaf name { 1343 type if:interface-ref; 1344 description 1345 "The name of interface"; 1347 } 1349 container statistics { 1350 description 1351 "The interface statistics for IGMP snooping"; 1353 container received { 1354 description 1355 "Statistics of received IGMP snooping packets."; 1357 uses igmp-snooping-statistics; 1358 } 1359 container sent { 1360 description 1361 "Statistics of sent IGMP snooping packets."; 1363 uses igmp-snooping-statistics; 1364 } 1366 } 1367 } 1368 } 1370 action clear-igmp-snooping-groups { 1371 if-feature action-clear-groups; 1372 description 1373 "Clear IGMP snooping cache tables."; 1375 input { 1376 leaf group { 1377 type union { 1378 type enumeration { 1379 enum 'all-groups' { 1380 description 1381 "All multicast group addresses."; 1382 } 1383 } 1384 type rt-types:ipv4-multicast-group-address; 1385 } 1386 mandatory true; 1387 description 1388 "Multicast group IPv4 address. If value 'all-groups' is 1389 specified, all IGMP snooping group entries are cleared 1390 for specified source address."; 1391 } 1392 leaf source { 1393 type rt-types:ipv4-multicast-source-address; 1394 mandatory true; 1395 description 1396 "Multicast source IPv4 address. If value '*' is specified, 1397 all IGMP snooping source-group tables are cleared."; 1398 } 1399 } 1400 } // action clear-igmp-snooping-groups 1401 } // igmp-snooping-instance 1402 } // augment 1404 augment "/rt:routing/rt:control-plane-protocols"+ 1405 "/rt:control-plane-protocol" { 1406 when 'derived-from-or-self(../rt:type, "ims:mld-snooping")' { 1407 description 1408 "This container is only valid for MLD snooping."; 1409 } 1410 description 1411 "MLD snooping augmentation to control plane protocol 1412 configuration and state."; 1414 container mld-snooping-instance { 1415 if-feature mld-snooping; 1416 description 1417 "MLD snooping instance to configure mld-snooping."; 1419 leaf scenario { 1420 type snooping-scenario-type; 1421 default bridge; 1422 description 1423 "The scenario indicates BRIDGE or L2VPN."; 1424 } 1426 uses instance-config-attributes-igmp-mld-snooping; 1428 leaf mld-version { 1429 type uint8 { 1430 range "1..2"; 1431 } 1432 default 2; 1433 description "MLD version."; 1434 } 1436 leaf querier-source { 1437 type inet:ipv6-address; 1438 description 1439 "Use the MLD snooping querier to support MLD snooping where 1440 PIM and MLD are not configured. The IPv6 address is used as 1441 the source address in messages."; 1442 } 1444 list static-l2-multicast-group { 1445 if-feature static-l2-multicast-group; 1446 key "group source-addr"; 1447 description 1448 "A static multicast route, (*,G) or (S,G)."; 1450 leaf group { 1451 type rt-types:ipv6-multicast-group-address; 1452 description 1453 "Multicast group IPv6 address"; 1454 } 1456 leaf source-addr { 1457 type rt-types:ipv6-multicast-source-address; 1458 description 1459 "Multicast source IPv6 address."; 1460 } 1462 leaf-list bridge-outgoing-interface { 1463 when 'derived-from-or-self(../../scenario,"ims:bridge")'; 1464 type if:interface-ref; 1465 description "Outgoing interface in BRIDGE forwarding"; 1466 } 1468 leaf-list l2vpn-outgoing-ac { 1469 when 'derived-from-or-self(../../scenario,"ims:l2vpn")'; 1470 type if:interface-ref; 1471 description "Outgoing Attachment Circuit (AC) in L2VPN"; 1472 } 1474 leaf-list l2vpn-outgoing-pw { 1475 when 'derived-from-or-self(../../scenario,"ims:l2vpn")'; 1476 type pw:pseudowire-ref; 1477 description "Outgoing Pseudo Wire (PW) in L2VPN"; 1478 } 1479 } // static-l2-multicast-group 1481 uses instance-state-attributes-igmp-mld-snooping; 1483 list group { 1484 key "address"; 1485 config false; 1486 description "MLD snooping statistics information"; 1488 leaf address { 1489 type rt-types:ipv6-multicast-group-address; 1490 description 1491 "Multicast group IPv6 address"; 1492 } 1494 uses instance-state-group-attributes-igmp-mld-snooping; 1496 leaf last-reporter { 1497 type inet:ipv6-address; 1498 description 1499 "Address of the last host which has sent report 1500 to join the multicast group."; 1501 } 1503 list source { 1504 key "address"; 1505 description "Source IPv6 address for multicast stream"; 1507 leaf address { 1508 type rt-types:ipv6-multicast-source-address; 1509 description "Source IPv6 address for multicast stream"; 1510 } 1512 uses instance-state-source-attributes-igmp-mld-snooping; 1514 leaf last-reporter { 1515 type inet:ipv6-address; 1516 description 1517 "Address of the last host which has sent report 1518 to join the multicast group."; 1519 } 1521 list host { 1522 if-feature explicit-tracking; 1523 key "host-address"; 1524 description 1525 "List of multicast membership hosts 1526 of the specific multicast source-group."; 1528 leaf host-address { 1529 type inet:ipv6-address; 1530 description 1531 "Multicast membership host address."; 1532 } 1533 leaf host-filter-mode { 1534 type filter-mode-type; 1535 mandatory true; 1536 description 1537 "Filter mode for a multicast membership 1538 host may be either include or exclude."; 1539 } 1540 }// list host 1541 } // list source 1542 } // list group 1544 container interfaces { 1545 config false; 1547 description 1548 "Interfaces associated with the MLD snooping instance"; 1550 list interface { 1551 key "name"; 1553 description 1554 "Interfaces associated with the MLD snooping instance"; 1556 leaf name { 1557 type if:interface-ref; 1558 description 1559 "The name of interface"; 1561 } 1563 container statistics { 1564 description 1565 "The interface statistics for MLD snooping"; 1567 container received { 1568 description 1569 "Statistics of received MLD snooping packets."; 1571 uses mld-snooping-statistics; 1572 } 1573 container sent { 1574 description 1575 "Statistics of sent MLD snooping packets."; 1577 uses mld-snooping-statistics; 1578 } 1579 } 1580 } 1581 } 1583 action clear-mld-snooping-groups { 1584 if-feature action-clear-groups; 1585 description 1586 "Clear MLD snooping cache tables."; 1588 input { 1589 leaf group { 1590 type union { 1591 type enumeration { 1592 enum 'all-groups' { 1593 description 1594 "All multicast group addresses."; 1595 } 1596 } 1597 type rt-types:ipv6-multicast-group-address; 1598 } 1599 mandatory true; 1600 description 1601 "Multicast group IPv6 address. If value 'all-groups' is 1602 specified, all MLD snooping group entries are cleared 1603 for specified source address."; 1604 } 1605 leaf source { 1606 type rt-types:ipv6-multicast-source-address; 1607 mandatory true; 1608 description 1609 "Multicast source IPv6 address. If value '*' is specified, 1610 all MLD snooping source-group tables are cleared."; 1611 } 1612 } 1613 } // action clear-mld-snooping-groups 1614 }// mld-snooping-instance 1615 } // augment 1617 augment "/dot1q:bridges/dot1q:bridge" { 1618 description 1619 "Use IGMP & MLD snooping instance in BRIDGE scenario"; 1621 leaf igmp-snooping-instance { 1622 type igmp-mld-snooping-instance-ref; 1624 description 1625 "Configure IGMP snooping instance under bridge view"; 1627 } 1628 leaf mld-snooping-instance { 1629 type igmp-mld-snooping-instance-ref; 1631 description 1632 "Configure MLD snooping instance under bridge view"; 1633 } 1634 } 1636 augment "/dot1q:bridges/dot1q:bridge"+ 1637 "/dot1q:component/dot1q:bridge-vlan/dot1q:vlan" { 1638 description 1639 "Use IGMP & MLD snooping instance in certain VLAN of BRIDGE"; 1641 leaf igmp-snooping-instance { 1642 type igmp-mld-snooping-instance-ref; 1644 description 1645 "Configure IGMP snooping instance under VLAN view"; 1646 } 1648 leaf mld-snooping-instance { 1649 type igmp-mld-snooping-instance-ref; 1651 description 1652 "Configure MLD snooping instance under VLAN view"; 1653 } 1654 } 1656 augment "/ni:network-instances/ni:network-instance"+ 1657 "/ni:ni-type/l2vpn:l2vpn" { 1659 description 1660 "Use IGMP & MLD snooping instance in L2VPN scenario"; 1662 leaf igmp-snooping-instance { 1663 type igmp-mld-snooping-instance-ref; 1665 description 1666 "Configure IGMP snooping instance in L2VPN scenario"; 1667 } 1668 leaf mld-snooping-instance { 1669 type igmp-mld-snooping-instance-ref; 1671 description 1672 "Configure MLD snooping instance in L2VPN scenario"; 1673 } 1674 } 1675 } 1676 1677 5. Security Considerations 1679 The YANG module specified in this document defines a schema for data 1680 that is designed to be accessed via network management protocols such as 1681 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the 1682 secure transport layer, and the mandatory-to-implement secure transport 1683 is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and 1684 the mandatory-to-implement secure transport is TLS [RFC8446]. 1686 The Network Configuration Access Control Model (NACM) [RFC8341] provides 1687 the means to restrict access for particular NETCONF or RESTCONF users to 1688 a preconfigured subset of all available NETCONF or RESTCONF protocol 1689 operations and content. 1691 There are a number of data nodes defined in this YANG module that are 1692 writable/creatable/deletable (i.e., config true, which is the default). 1693 These data nodes may be considered sensitive or vulnerable in some 1694 network environments. Write operations (e.g., edit-config) to these data 1695 nodes without proper protection can have a negative effect on network 1696 operations. These are the subtrees and data nodes and their 1697 sensitivity/vulnerability: 1699 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 1701 ims:igmp-snooping-instance 1703 ims:mld-snooping-instance 1705 The subtrees under /dot1q:bridges/dot1q:bridge 1707 ims:igmp-snooping-instance 1709 ims:mld-snooping-instance 1711 The subtrees under /dot1q:bridges/dot1q:bridge/dot1q:component 1712 /dot1q:bridge-vlan/dot1q:vlan 1714 ims:igmp-snooping-instance 1716 ims:mld-snooping-instance 1718 Unauthorized access to any data node of these subtrees can adversely 1719 affect the IGMP & MLD Snooping subsystem of both the local device and 1720 the network. This may lead to network malfunctions, delivery of packets 1721 to inappropriate destinations, and other problems. 1723 Some of the readable data nodes in this YANG module may be considered 1724 sensitive or vulnerable in some network environments. It is thus 1725 important to control read access (e.g., via get, get-config, or 1726 notification) to these data nodes. These are the subtrees and data nodes 1727 and their sensitivity/vulnerability: 1729 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 1731 ims:igmp-snooping-instance 1733 ims:mld-snooping-instance 1735 Unauthorized access to any data node of these subtrees can disclose the 1736 operational state information of IGMP & MLD Snooping on this device. 1738 Some of the action operations in this YANG module may be considered 1739 sensitive or vulnerable in some network environments. It is thus 1740 important to control access to these operations. These are the 1741 operations and their sensitivity/vulnerability: 1743 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 1745 ims:igmp-snooping-instance/ims:clear-igmp-snooping-groups 1747 ims:mld-snooping-instance/ims:clear-mld-snooping-groups 1749 Some of the actions in this YANG module may be considered sensitive or 1750 vulnerable in some network environments. The IGMP & MLD Snooping YANG 1751 module supports the "clear-igmp-snooping-groups" and "clear-mld- 1752 snooping-groups" actions. If unauthorized action is invoked, the IGMP 1753 and MLD Snooping group tables will be cleared unexpectedly. Especially 1754 when using wildcard on group and source, the impact will be dramatic. 1756 6. IANA Considerations 1758 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1759 actual RFC number (and remove this note). 1761 This document registers the following namespace URIs in the IETF XML 1763 registry [RFC3688]: 1765 -------------------------------------------------------------------- 1766 URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping 1767 Registrant Contact: The IETF. 1768 XML: N/A, the requested URI is an XML namespace. 1769 -------------------------------------------------------------------- 1770 This document registers the following YANG modules in the YANG Module 1771 Names registry [RFC7950]: 1772 -------------------------------------------------------------------- 1773 name: ietf-igmp-mld-snooping 1774 namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-snooping 1775 prefix: ims 1776 reference: RFC XXXX 1777 -------------------------------------------------------------------- 1778 7. References 1780 7.1. Normative References 1782 [dot1Qcp] IEEE, "Standard for Local and metropolitan area networks-- 1783 Bridges and Bridged Networks--Amendment 30: YANG Data 1784 Model", IEEE Std 802.1Qcp-2018 (Revision of IEEE Std 1785 802.1Q-2014), September 2018, 1786 1788 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1789 RFC 1112, August 1989. 1791 [RFC2236] W. Fenner, "Internet Group Management Protocol, Version 2", 1792 RFC 2236, November 1997. 1794 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1795 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 1797 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1798 Thyagarajan, "Internet Group Management Protocol, Version 1799 3", RFC 3376, October 2002. 1801 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 1802 2004. 1804 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1805 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1807 [RFC4286] B. Haberman and J. Martin, "Multicast Router Discovery", 1808 RFC 4286, December 2005. 1810 [RFC4541] M. Christensen, K. Kimball, F. Solensky, "Considerations 1811 for Internet Group Management Protocol (IGMP) and Multicast 1812 Listener Discovery (MLD) Snooping Switches", RFC 4541, May 1813 2006. 1815 [RFC5790] H. Liu, W. Cao, H. Asaeda, "Lightweight Internet Group 1816 Management Protocol Version 3 (IGMPv3) and Multicast 1817 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 1818 February 2010. 1820 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1821 the Network Configuration Protocol (NETCONF)", RFC 6020, 1822 October 2010. 1824 [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. 1825 Bierman, Ed., "Network Configuration Protocol (NETCONF)", 1826 RFC 6241, June 2011. 1828 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1829 Shell (SSH)", RFC 6242, June 2011. 1831 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 1832 July 2013. 1834 [RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, 1835 Z. Zhang, L. Zheng, "Protocol Independent Multicast - 1836 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 1837 RFC 7761, March 2016. 1839 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", 1840 RFC 7950, August 2016. 1842 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", 1843 RFC 8040, January 2017. 1845 [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG 1846 Data Types for the Routing Area", RFC 8294, December 2017. 1848 [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC 1849 8340, March 2018. 1851 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access 1852 Control Model", RFC 8341, March 2018. 1854 [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management 1855 Datastore Architecture (NMDA)", RFC 8342, March 2018. 1857 [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", 1858 RFC 8343, March 2018. 1860 [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing 1861 Management (NMDA Version)", RFC 8349, March 2018. 1863 [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of 1864 Documents Containing YANG Data Models", RFC 8407, October 1865 2018. 1867 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1868 Version 1.3", RFC 8446, August 2018. 1870 [RFC8529] L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu, 1871 "YANG Data Model for Network Instances", RFC 8529, March 1872 2019. 1874 [RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A 1875 YANG Data Model for the Internet Group Management Protocol 1876 (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, 1877 November 2019. 1879 [draft-ietf-bess-l2vpn-yang] Shah, H., Brissette, P., Chen, I., 1880 Hussain, I., Wen, B., and K. Tiruveedhula, "YANG Data Model 1881 for MPLS-basedL2VPN", draft-ietf-bess-l2vpn-yang-10 (work 1882 in progress), July 2019. 1884 7.2. Informative References 1886 [RFC3916] X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed., 1887 "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1888 (PWE3)", RFC 3916, September 2004. 1890 [RFC6636] H. Asaeda, H. Liu, Q. Wu, "Tuning the Behavior of the 1891 Internet Group Management Protocol (IGMP) and Multicast 1892 Listener Discovery (MLD) for Routers in Mobile and Wireless 1893 Networks", RFC 6636, May 2012. 1895 [RFC7951] L. Lhotka, "JSON Encoding of Data Modeled with YANG", RFC 1896 7951, August 2016. 1898 Appendix A. Data Tree Example 1900 A.1 Bridge scenario 1902 This section contains an example for bridge scenario in the JSON 1903 encoding [RFC7951], containing both configuration and state data. 1905 +-----------+ 1906 + Source + 1907 +-----+-----+ 1908 | 1909 -----------------+---------------------------- 1910 |eth1/1 1911 +---+---+ 1912 + R1 + 1913 +-+---+-+ 1914 eth1/2 | \ eth1/3 1915 | \ 1916 | \ 1917 | \ 1918 | \ 1919 eth2/1 | \ eth3/1 1920 +---+---+ +--+---+ 1921 + R2 + + R3 + 1922 +---+---+ +--+---+ 1923 eth2/2 | | eth3/2 1924 | | 1925 ---------------+----------+------------------- 1926 | | 1927 | | 1928 +--------+--+ +---+--------+ 1929 + Receiver1 + + Receiver2 + 1930 +-----------+ +------------+ 1932 The configuration data for R1 in the above figure could be as follows: 1934 { 1935 "ietf-interfaces:interfaces":{ 1936 "interface":[ 1937 { 1938 "name":"eth1/1", 1939 "type":"iana-if-type:ethernetCsmacd" 1940 } 1941 ] 1942 }, 1943 "ietf-routing:routing":{ 1944 "control-plane-protocols":{ 1945 "control-plane-protocol":[ 1946 { 1947 "type":"ietf-igmp-mld-snooping:igmp-snooping", 1948 "name":"bis1", 1949 "ietf-igmp-mld-snooping:igmp-snooping-instance":{ 1950 "scenario":"ietf-igmp-mld-snooping:bridge", 1951 "enable":true 1952 } 1953 } 1954 ] 1955 } 1956 }, 1957 "ieee802-dot1q-bridge:bridges":{ 1958 "bridge":[ 1959 { 1960 "name":"isp1", 1961 "address":"00-23-ef-a5-77-12", 1962 "bridge-type":"ieee802-dot1q-bridge:customer-vlan-bridge", 1963 "component":[ 1964 { 1965 "name":"comp1", 1966 "type":"ieee802-dot1q-bridge:c-vlan-component", 1967 "bridge-vlan":{ 1968 "vlan":[ 1969 { 1970 "vid":101, 1971 "ietf-igmp-mld-snooping:igmp-snooping-instance":"bis1" 1972 } 1973 ] 1974 } 1975 } 1976 ] 1977 } 1978 ] 1979 } 1980 } 1982 The corresponding operational state data for R1 could be as follows: 1984 { 1985 "ietf-interfaces:interfaces": { 1986 "interface": [ 1987 { 1988 "name": "eth1/1", 1989 "type": "iana-if-type:ethernetCsmacd", 1990 "oper-status": "up", 1991 "statistics": { 1992 "discontinuity-time": "2018-05-23T12:34:56-05:00" 1993 } 1994 } 1995 ] 1996 }, 1997 "ietf-routing:routing": { 1998 "control-plane-protocols": { 1999 "control-plane-protocol": [ 2000 { 2001 "type": "ietf-igmp-mld-snooping:igmp-snooping", 2002 "name": "bis1", 2003 "ietf-igmp-mld-snooping:igmp-snooping-instance": { 2004 "scenario": "ietf-igmp-mld-snooping:bridge", 2005 "enable": true 2006 } 2007 } 2008 ] 2009 } 2010 }, 2011 "ieee802-dot1q-bridge:bridges": { 2012 "bridge": [ 2013 { 2014 "name": "isp1", 2015 "address": "00-23-ef-a5-77-12", 2016 "bridge-type": "ieee802-dot1q-bridge:customer-vlan-bridge", 2017 "component": [ 2018 { 2019 "name": "comp1", 2020 "type": "ieee802-dot1q-bridge:c-vlan-component", 2021 "bridge-vlan": { 2022 "vlan": [ 2023 { 2024 "vid": 101, 2025 "ietf-igmp-mld-snooping:igmp-snooping-instance": "bis1" 2026 } 2027 ] 2028 } 2029 } 2030 ] 2031 } 2032 ] 2033 } 2034 } 2035 The following action is to clear all the entries whose group address is 2036 225.1.1.1 for igmp-snooping-instance bis1. 2038 POST /restconf/operations/ietf-routing:routing/\ 2039 control-plane-protocols/control-plane-protocol=igmp-snooping,bis1/\ 2040 ietf-igmp-mld-snooping:igmp-snooping/igmp-snooping-instance\ 2041 /clear-igmp-snooping-groups HTTP/1.1 2042 Host: example.com 2043 Content-Type: application/yang-data+json 2045 { 2046 "ietf-igmp-mld-snooping:input" : { 2047 "group": "225.1.1.1", 2048 "source": "*" 2049 } 2050 } 2051 A.2 L2VPN scenario 2053 This section contains an example for L2VPN scenario in the JSON encoding 2054 [RFC7951], containing both configuration and state data. 2056 +-----------+ 2057 + Source + 2058 +-----+-----+ 2059 | 2060 -----------------+---------------------------- 2061 |eth1/1 2062 +---+---+ 2063 + R1 + 2064 +-+---+-+ 2065 eth1/2 | \ eth1/3 2066 | \ 2067 | \ 2068 | \ 2069 | \ 2070 eth2/1 | \ eth3/1 2071 +---+---+ +-+---+ 2072 + R2 +----+ R3 + 2073 +---+---+ +-+---+ 2074 eth2/2 | | eth3/2 2075 | | 2076 ---------------+----------+------------------- 2077 | | 2078 | | 2079 +--------+--+ +---+--------+ 2080 + Receiver1 + + Receiver2 + 2081 +-----------+ +------------+ 2083 The configuration data for R1 in the above figure could be as follows: 2084 { 2085 "ietf-interfaces:interfaces":{ 2086 "interface":[ 2087 { 2088 "name":"eth1/1", 2089 "type":"iana-if-type:ethernetCsmacd" 2090 } 2091 ] 2092 }, 2093 "ietf-pseudowires:pseudowires": { 2094 "pseudowire": [ 2095 { 2096 "name": "pw2" 2097 }, 2098 { 2099 "name": "pw3" 2101 } 2102 ] 2103 }, 2104 "ietf-network-instance:network-instances": { 2105 "network-instance": [ 2106 { 2107 "name": "vpls1", 2108 "ietf-igmp-mld-snooping:igmp-snooping-instance": "vis1", 2109 "ietf-l2vpn:type": "ietf-l2vpn:vpls-instance-type", 2110 "ietf-l2vpn:signaling-type": "ietf-l2vpn:ldp-signaling", 2111 "ietf-l2vpn:endpoint": [ 2112 { 2113 "name": "acs", 2114 "ac": [ 2115 { 2116 "name": "eth1/1" 2117 } 2118 ] 2119 }, 2120 { 2121 "name": "pws", 2122 "pw": [ 2123 { 2124 "name": "pw2" 2125 }, 2126 { 2127 "name": "pw3" 2128 } 2129 ] 2130 } 2131 ] 2132 } 2133 ] 2134 }, 2135 "ietf-routing:routing": { 2136 "control-plane-protocols": { 2137 "control-plane-protocol": [ 2138 { 2139 "type": "ietf-igmp-mld-snooping:igmp-snooping", 2140 "name": "vis1", 2141 "ietf-igmp-mld-snooping:igmp-snooping-instance": { 2142 "scenario": "ietf-igmp-mld-snooping:l2vpn", 2143 "enable": true 2144 } 2145 } 2146 ] 2147 } 2148 } 2149 } 2150 The corresponding operational state data for R1 could be as follows: 2152 { 2153 "ietf-interfaces:interfaces":{ 2154 "interface":[ 2155 { 2156 "name":"eth1/1", 2157 "type":"iana-if-type:ethernetCsmacd", 2158 "oper-status": "up", 2159 "statistics": { 2160 "discontinuity-time": "2018-05-23T12:34:56-05:00" 2161 } 2162 } 2163 ] 2164 }, 2165 "ietf-pseudowires:pseudowires": { 2166 "pseudowire": [ 2167 { 2168 "name": "pw2" 2169 }, 2170 { 2171 "name": "pw3" 2172 } 2173 ] 2174 }, 2175 "ietf-network-instance:network-instances": { 2176 "network-instance": [ 2177 { 2178 "name": "vpls1", 2179 "ietf-igmp-mld-snooping:igmp-snooping-instance": "vis1", 2180 "ietf-l2vpn:type": "ietf-l2vpn:vpls-instance-type", 2181 "ietf-l2vpn:signaling-type": "ietf-l2vpn:ldp-signaling", 2182 "ietf-l2vpn:endpoint": [ 2183 { 2184 "name": "acs", 2185 "ac": [ 2186 { 2187 "name": "eth1/1" 2188 } 2189 ] 2190 }, 2191 { 2192 "name": "pws", 2193 "pw": [ 2194 { 2195 "name": "pw2" 2196 }, 2197 { 2198 "name": "pw3" 2199 } 2200 ] 2201 } 2203 ] 2204 } 2205 ] 2206 }, 2207 "ietf-routing:routing": { 2208 "control-plane-protocols": { 2209 "control-plane-protocol": [ 2210 { 2211 "type": "ietf-igmp-mld-snooping:igmp-snooping", 2212 "name": "vis1", 2213 "ietf-igmp-mld-snooping:igmp-snooping-instance": { 2214 "scenario": "ietf-igmp-mld-snooping:l2vpn", 2215 "enable": true 2216 } 2217 } 2218 ] 2219 } 2220 } 2221 } 2222 Authors' Addresses 2224 Hongji Zhao 2225 Ericsson (China) Communications Company Ltd. 2226 Ericsson Tower, No. 5 Lize East Street, 2227 Chaoyang District Beijing 100102, P.R. China 2229 Email: hongji.zhao@ericsson.com 2231 Xufeng Liu 2232 Volta Networks 2233 USA 2235 EMail: xufeng.liu.ietf@gmail.com 2237 Yisong Liu 2238 China Mobile 2239 China 2241 Email: liuyisong@chinamobile.com 2243 Anish Peter 2244 Individual 2246 EMail: anish.ietf@gmail.com 2248 Mahesh Sivakumar 2249 Juniper Networks 2250 1133 Innovation Way 2251 Sunnyvale, California 2252 USA 2254 EMail: sivakumar.mahesh@gmail.com