idnits 2.17.1 draft-asaeda-pim-multiif-igmpmldproxy-04.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 10, 2020) is 1506 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 503 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Informational LM. Contreras 5 Expires: September 11, 2020 Telefonica 6 March 10, 2020 8 Multiple Upstream Interface Support for IGMP/MLD Proxy 9 draft-asaeda-pim-multiif-igmpmldproxy-04 11 Abstract 13 This document describes the way of supporting multiple upstream 14 interfaces for an IGMP/MLD proxy device. The proposed extension 15 enables an IGMP/MLD proxy device to receive multicast sessions/ 16 channels through the different upstream interfaces. The upstream 17 interface is selected based on the subscriber address prefixes, 18 channel/session IDs, and interface priority values. A mechanism for 19 upstream interface takeover that enables to switch from an inactive 20 upstream interface to an active upstream interface is also described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 11, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Upstream Selection Mechanism . . . . . . . . . . . . . . . . 5 59 3.1. Channel-Based Upstream Selection . . . . . . . . . . . . 5 60 3.2. Subscriber-Based Upstream Selection . . . . . . . . . . . 5 61 3.3. Multiple Upstream Interface Selection for Robust Data 62 Reception . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Candidate Upstream Interface Configuration . . . . . . . . . 6 64 4.1. Address Prefix Record . . . . . . . . . . . . . . . . . . 6 65 4.2. Channel/Session ID . . . . . . . . . . . . . . . . . . . 7 66 4.3. Interface Priority . . . . . . . . . . . . . . . . . . . 7 67 4.4. Default Upstream Interface . . . . . . . . . . . . . . . 8 68 5. Upstream Interface Takeover . . . . . . . . . . . . . . . . . 8 69 5.1. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 8 70 5.2. Active Interval . . . . . . . . . . . . . . . . . . . . . 9 71 6. Automatic Upstream Interface Configuration . . . . . . . . . 9 72 6.1. Signaling-based Upstream Interface Configuration . . . . 10 73 6.2. Controller-based Upstream Interface Configuration . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Consideration for Updating YANG Model . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The Internet Group Management Protocol (IGMP) [2][4] for IPv4 and the 85 Multicast Listener Discovery Protocol (MLD) [3][4] for IPv6 are the 86 standard protocols for hosts to initiate joining or leaving of 87 multicast sessions. A proxy device performing IGMP/MLD-based 88 forwarding (as known as IGMP/MLD proxy) [5] maintains multicast 89 membership information by IGMP/MLD protocols on the downstream 90 interfaces and sends IGMP/MLD membership report messages via the 91 upstream interface to the upstream multicast routers when the 92 membership information changes (e.g., by receiving solicited/ 93 unsolicited report messages). The proxy device forwards appropriate 94 multicast packets received on its upstream interface to each 95 downstream interface based on the downstream interface's 96 subscriptions. 98 According to the specification of [5], an IGMP/MLD proxy has *a 99 single* upstream interface and one or more downstream interfaces. 100 The multicast forwarding tree must be manually configured by 101 designating upstream and downstream interfaces on an IGMP/MLD proxy 102 device, and the root of the tree is expected to be connected to a 103 wider multicast infrastructure. An IGMP/MLD proxy device hence 104 performs the router portion of the IGMP or MLD protocol on its 105 downstream interfaces, and the host portion of IGMP/MLD on its 106 upstream interface. The proxy device must not perform the router 107 portion of IGMP/MLD on its upstream interface. 109 On the other hand, there is a scenario in which an IGMP/MLD proxy 110 device enables multiple upstream interfaces and receives multicast 111 packets through these interfaces. For example, a proxy device having 112 more than one interface may want to access to different networks, 113 such as a global network like the Internet and local-scope networks. 114 Or, a proxy device having wired link (e.g., ethernet) and high-speed 115 wireless link (e.g., WiMAX or LTE) may want to have the capability to 116 connect to the Internet through both links. These proxy devices 117 shall receive multicast packets from the different upstream 118 interfaces and forward to the downstream interface(s). Several other 119 scenarios and subsequent requirements for the support of multiple 120 upstream interfaces on IGMP/MLD proxy are documented in [7]. 122 This document describes the mechanism that enables an IGMP/MLD proxy 123 device to receive multicast sessions/channels through the different 124 upstream interfaces. The mechanism is configured with either 125 "channel-based upstream selection" or "subscriber-based upstream 126 selection", or both of them. By channel-based upstream selection, an 127 IGMP/MLD proxy device selects one or multiple upstream interface(s) 128 from the candidate upstream interfaces "per channel/session". By 129 subscriber-based upstream selection, an IGMP/MLD proxy device selects 130 one or multiple upstream interface(s) from the candidate upstream 131 interfaces "per subscriber/receiver". 133 When a proxy device transmits an IGMP/MLD report message, it examines 134 the source and multicast addresses in the IGMP/MLD records of the 135 report message. It then transmits the appropriate IGMP/MLD report 136 message(s) from the selected upstream interface(s). When a proxy 137 device selects "one" upstream interface from the candidate upstream 138 interfaces per session/channel, it enables "load balancing" per 139 session/channel. When a proxy device selects "more than two" 140 upstream interfaces from the candidate upstream interfaces per 141 session/channel, it potentially receives duplicate (redundant) 142 packets for the session/channel from the different upstream 143 interfaces simultaneously and provides "robust data reception". 145 A mechanism for "upstream interface takeover" is also described in 146 this document; when the selected upstream interface is going down or 147 the state of the link attached to the upstream interface is inactive, 148 one of the other active candidate upstream interfaces takes over the 149 upstream interface (if configured). The potential timer values to 150 switch from an inactive upstream interface to an active upstream 151 interface from a list of candidate upstream interfaces are discussed 152 in this document as well. 154 An "automatic upstream configuration" mechanism that selects an 155 appropriate upstream interface(s) for sessions/channels based on the 156 network and adjacent routers' conditions is also described in this 157 document. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 162 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 163 this document are to be interpreted as described in RFC 2119 [1]. 165 In addition, the following terms are used in this document. 167 Selected upstream interface (or simply, upstream interface): 168 A proxy device's interface in the direction of the root of the 169 multicast forwarding tree. A proxy device performs the host portion 170 of IGMP/MLD on its upstream interfaces. An upstream interface is 171 selected from a list of candidate upstream interfaces. 173 Default upstream interface: 174 A default upstream interface is the upstream interface for multicast 175 sessions/channels for which a proxy device cannot choose other 176 interfaces as the upstream interface. A default upstream interface 177 is configured. 179 Active upstream interface: 180 An active upstream interface is the upstream interface that has been 181 receiving packets for specific multicast sessions/channels during the 182 pre-defined active interval. 184 Inactive upstream interface: 185 An inactive upstream interface is the interface that has not received 186 packets for specific multicast sessions/channels during the pre- 187 defined active interval. 189 Downstream interface: 190 Each of a proxy device's interfaces that is not in the direction of 191 the root of the multicast forwarding tree. A proxy device performs 192 the router portion of IGMP/MLD on its downstream interfaces. 194 Candidate upstream interface: 195 An interface that potentially becomes an upstream interface of the 196 proxy device. A list of candidate upstream interfaces is configured 197 with subscriber address prefixes, channel/session IDs, and priority 198 values on an IGMP/MLD proxy device. 200 Channel/session ID: 201 Channel/session ID consists of source address prefix and multicast 202 address prefix for which a candidate upstream interface supposes to 203 be an upstream interface for specified multicast sessions/channels. 204 Both or either source address prefix and/or multicast address prefix 205 can be "null". 207 3. Upstream Selection Mechanism 209 3.1. Channel-Based Upstream Selection 211 An IGMP/MLD proxy device selects one or multiple upstream 212 interface(s) from the candidate upstream interfaces "per channel/ 213 session" based on the "channel/session ID" configuration. This 214 mechanism is called "channel-based upstream selection" whose 215 configuration is explained in Section 4.1 and Section 4.2). enables 216 an IGMP/MLD proxy device to use one or multiple upstream interface(s) 217 from the candidate upstream interfaces "per channel/session" based on 218 the "channel/session ID" configuration (as will be in Section 4.1 and 219 Section 4.2). 221 3.2. Subscriber-Based Upstream Selection 223 An IGMP/MLD proxy device selects one or multiple upstream 224 interface(s) from the candidate upstream interfaces "per subscriber/ 225 receiver". This is called "subscriber-based upstream selection". It 226 enables a proxy device to use one or multiple upstream interface(s) 227 per session/channel from the "candidate upstream interfaces" based on 228 the "subscriber address prefix" configuration (as will be in 229 Section 4.1). 231 3.3. Multiple Upstream Interface Selection for Robust Data Reception 233 When more than one candidate upstream interface is configured with 234 the same source and multicast addresses for the "channel/session 235 IDs", and "interface priority values" (as will be in Section 4.3) are 236 identical, these candidate upstream interfaces act as the upstream 237 interfaces for the sessions/channels and receive the packets 238 simultaneously. This multiple upstream interface selection 239 implements duplicate packet reception from redundant paths. It may 240 improve data reception quality or robustness for a session/channel, 241 as the same multicast data packets can come from different upstream 242 interfaces simultaneously. However, this robust data reception does 243 not guarantee that the packets come from disjoint paths. It only 244 configures that the adjacent upstream routers are different. 246 4. Candidate Upstream Interface Configuration 248 Candidate upstream interfaces are the interfaces from which an IGMP/ 249 MLD proxy device selects as an upstream interface. The upstream 250 interface selection works with the configurations of "subscriber 251 address prefix", "channel/session ID", and "interface priority 252 value". 254 4.1. Address Prefix Record 256 An IGMP/MLD proxy device can configure the "subscriber address 257 prefix" and "channel/session ID" for each candidate upstream 258 interface. Channel/session ID consists of "source address prefix" 259 and "multicast address prefix". Subscriber address prefix and source 260 address prefix MUST be a valid unicast address prefix, and multicast 261 address prefix MUST be a valid multicast address prefix. A proxy 262 selects an upstream interface from its candidate upstream interfaces 263 based on the configuration of the following address prefix record: 265 (subscriber address prefix, (channel/session ID)) 267 where channel/session ID includes: 269 (source address prefix, multicast address prefix) 271 The default values of these address prefixes are "null". Null source 272 address prefix represents the wildcard source address prefix, which 273 indicates any host. Null multicast address prefix represents the 274 wildcard multicast address prefix, which indicates the entire 275 multicast address range (i.e., '224.0.0.0/4' for IPv4 or 'ff00::/8' 276 for IPv6). 278 The candidate upstream interface having the configuration of 279 subscriber address prefix is prioritized. If network operators want 280 to assign a specific upstream interface for specific subscribers 281 without depending on source and multicast address prefixes, both 282 source and multicast addresses in the address prefix record is 283 configured "null". 285 If network operators want to select specific upstream interface(s) 286 without depending on subscriber address prefix, subscriber address 287 prefix in the address prefix record is configured "null". 289 4.2. Channel/Session ID 291 Channel/session ID configuration consists of source and multicast 292 address prefixes. Both/either source and/or multicast address may be 293 configured "null". A candidate upstream interface having non-null 294 source and multicast address configuration is prioritized for the 295 upstream interface selection. For example, if a proxy device has two 296 candidate upstream interfaces for the same multicast address prefix 297 and one of them has non-null source address configuration, then that 298 candidate upstream interface is selected for the source and multicast 299 address pair. The other candidate upstream interface is selected for 300 the configured multicast address prefix except the source address 301 configured by the prior interface. 303 Source address prefix configuration takes priority over multicast 304 address prefix configuration. For example, consider the case that an 305 IGMP/MLD proxy device has a configuration with source address prefix 306 S_p for the candidate upstream interface A and multicast address 307 prefix G_p for the candidate upstream interface B. When it deals 308 with an IGMP/MLD record whose source address, let's say S, is in the 309 range of S_p, and whose multicast address, let's say G, is in the 310 range of G_p, the proxy device selects the candidate upstream 311 interface A, which supports the source address prefix, as the 312 upstream interface, and transmits the (S,G) record via the interface 313 A. 315 The same address prefix may be configured on different candidate 316 upstream interfaces. When the same address prefix is configured on 317 different candidate upstream interfaces, an upstream interface for 318 that address prefix is selected based on each interface priority 319 value (as will be in Section 4.3). 321 4.3. Interface Priority 323 An IGMP/MLD proxy device can configure the "interface priority" value 324 for each candidate upstream interface. It is an integer value and is 325 part of the configuration. The default value of the interface 326 priority is the lowest value. 328 The interface priority value effects only when either of the 329 following conditions is satisfied. 331 o None of the candidate upstream interfaces configures both the 332 subscriber address prefix and the channel/session ID. 334 o More than one candidate upstream interface configures the same 335 channel/session IDs but does not configure the subscriber address 336 prefix. 338 In these conditions, the candidate upstream interface with the 339 highest priority is chosen as the upstream interface. And as stated 340 in Section 3.3, if the priority values for candidate upstream 341 interfaces are also identical, all of these interfaces act as the 342 upstream interfaces for the configured channel/session ID and may 343 receive duplicate packets. 345 4.4. Default Upstream Interface 347 An IGMP/MLD proxy device SHOULD configure "a default upstream 348 interface" for all incoming sessions/channels. A default upstream 349 interface is selected as the upstream interface, when none of the 350 candidate upstream interfaces configures subscriber address prefix, 351 channel/session ID, or interface priority value, or with either of 352 the following conditions. 354 o None of the candidate upstream interfaces configures both the 355 subscriber address prefix, the channel/session ID, and identical 356 interface priority value. 358 o More than one candidate upstream interface configures the same 359 channel/session IDs and identical interface priority value, but 360 does not configure the subscriber address prefix. 362 If a default upstream interface is not configured on an IGMP/MLD 363 proxy device, the candidate upstream interface whose IPv4/v6 address 364 is the highest of others is configured as the default upstream 365 interface for the proxy device. 367 5. Upstream Interface Takeover 369 5.1. Proxy Behavior 371 If a selected upstream interface is going down or inactive, or an 372 adjacent upstream router is not working, the upstream interface can 373 be disabled and the other active upstream interface listed in the 374 candidate upstream interfaces covering the same channel/session ID 375 can act as a new upstream interface. It recursively examines the 376 list of the candidate upstream interfaces (except the disabled 377 interface) and decides a new upstream interface from them. If no 378 active candidate upstream interfaces exist, the default upstream 379 interface takes its role. 381 This function called "upstream interface takeover" is a default 382 function for a proxy device that enables multiple upstream interface 383 support. If a proxy device simultaneously uses more than two 384 upstream interfaces per session/channel, and one or some of these 385 upstream interface(s) is/are inactive, the proxy device acts either 386 of the following behaviors based on the configuration; (1) it only 387 uses the active upstream interface(s) and does not add (i.e., does 388 not complement) other upstream interfaces, (2) it uses the active 389 upstream interface(s) and another candidate upstream interface whose 390 priority is highest among the configured upstream interfaces, or (3) 391 it uses the active upstream interface(s) and the default upstream 392 interface. 394 The condition whether the upstream adjacent router is active or not 395 can be decided by checking the link/interface condition on the proxy 396 device or detected by monitoring IGMP/MLD Query or PIM [6] Hello 397 message reception on the link. There are the cases that PIM is not 398 running on the link or IGMP/MLD Query messages are not always 399 transmitted by the upstream router (e.g., because of enabling the 400 explicit tracking function [8]). Therefore, network operators MUST 401 configure either; (1) the proxy device disables the upstream 402 interface takeover, (2) the proxy device triggers upstream interface 403 takeover by detecting no IGMP/MLD Query message within the active 404 interval, or (3) the proxy device triggers upstream interface 405 takeover by detecting no PIM Hello message within the active 406 interval, for each candidate upstream interface. 408 Network operators may want to keep out of use for the inactive 409 upstream interface(s). This causes, for example, when subscriber- 410 based upstream selection is configured, according to their accounting 411 policy (because the specific subscribers are planned to use the 412 specific upstream interface and cannot receive packets from other 413 upstream interfaces.) In that case, this upstream interface takeover 414 must be disabled, and the proxy device keeps using that interface as 415 the upstream interface for them (and waits for working the interface 416 later again). 418 5.2. Active Interval 420 Active interval is a period, after which a proxy device recognizes 421 that the selected upstream interface is inactive. Active interval 422 for each candidate upstream interface SHOULD be configured. The 423 active interval values are different in the situation whether the 424 network operators want to trigger by either IGMP/MLD or PIM messages. 425 The default active interval to detect an inactive upstream interface 426 is around twice of IGMP/MLD General Query interval and PIM Hello 427 interval. Further discussion [TBD]. 429 6. Automatic Upstream Interface Configuration 430 6.1. Signaling-based Upstream Interface Configuration 432 There may be the ways for a proxy device to automatically configure 433 the upstream interface for specific multicast channels/sessions. It 434 works for the case in which there are no static configurations for a 435 candidate upstream interface or operators decide. The algorithms are 436 achieved by monitoring existing or newly proposed IGMP/MLD messages, 437 but further discussions are TBD. 439 6.2. Controller-based Upstream Interface Configuration 441 A centralized controller can instruct the proxy what upstream 442 interface is the appropriate one to use based on a certain multicast 443 channel or on the user herself. 445 There are options for selecting the most appropriate upstream 446 interface: 448 o Association of membership requests from a specific user, 449 identified by the source IP of the IGMP/MLD message, to a specific 450 upstream interface, meaning that all the multicast traffic for 451 that end user is received from a certain upstream interface. 453 o Association of (S,G) to a specific upstream interface, meaning 454 that an end user request for specific content delivered from a 455 specific source should be received from a certain upstream 456 interface. 458 o Association of (*,G) to a specific upstream interface, meaning 459 that a user request of given content, independently of the source 460 of that content, should be received from a certain upstream 461 interface. 463 o Association of (S,*) to a specific upstream interface, meaning 464 that all the requests from a certain user, independently of the 465 group identifying the content, should be received from a certain 466 upstream interface. 468 The list above does not show any precedence. Thus precedence should 469 be defined to indicate priority in the selection of the criteria to 470 apply, as a list of ordered actions. 472 The controller should also configure a default upstream interface for 473 those subscription requests that do not match an explicitly 474 configured behavior. In case of upstream interface failure, the 475 default upstream interface could take over the failed upstream to 476 provide redundancy. 478 To enable this manner of configuration, some control and management 479 interface has to be supported by the proxy in order to receive 480 configuration instructions from the controller. 482 The controller could interact with a number of proxies in the 483 network. Being a centralized element, it could take coordinated 484 decisions for managing all the multicast traffic in the network in a 485 coordinated manner. 487 7. IANA Considerations 489 This document has no actions for IANA. 491 8. Security Considerations 493 This document neither provides new functions nor modifies the 494 standard functions defined in [2][3][4]; hence there is no additional 495 security consideration provided for these protocols themselves. On 496 the other hand, it may be possible to encounter DoS attacks to make 497 the function for upstream interface takeover stop if attackers 498 illegally sends IGMP/MLD Query or PIM Hello messages on a LAN within 499 a shorter period (i.e., before expiring the active interval for the 500 upstream interface). To bypass such threats, it is recommended to 501 capture the source addresses of IGMP/MLD Query or PIM Hello message 502 senders and check whether the addresses correspond to the correct 503 adjacent upstream routers. Consideration [TBD]. 505 9. Consideration for Updating YANG Model 507 About the IGMP/MLD YANG model proposed in [9], there is a description 508 of interfaces for IGMP (similar for MLD). When this document is 509 officially approved, it is necessary to update the proposed YANG 510 model to include all the information related to the upstream 511 interfaces defined in this document, and consider the actions related 512 to the selection of the upstream interfaces as mentioned in 513 Section 6. 515 10. References 517 10.1. Normative References 519 [1] Bradner, S., "Key words for use in RFCs to indicate 520 requirement levels", RFC 2119, March 1997. 522 [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 523 Thyagarajan, "Internet Group Management Protocol, Version 524 3", RFC 3376, October 2002. 526 [3] Vida, R. and L. Costa, "Multicast Listener Discovery 527 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 529 [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 530 Group Management Protocol Version 3 (IGMPv3) and Multicast 531 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 532 February 2010. 534 [5] Fenner, B., He, H., Haberman, B., and H. Sandick, 535 "Internet Group Management Protocol (IGMP) / Multicast 536 Listener Discovery (MLD)-Based Multicast Forwarding 537 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 539 [6] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 540 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 541 Multicast - Sparse Mode (PIM-SM): Protocol Specification 542 (Revised)", RFC 7761, March 2016. 544 10.2. Informative References 546 [7] Contreras, LM., Bernardos, CJ., Asaeda, H., and N. 547 Leymann, "Requirements for the extension of the IGMP/MLD 548 proxy functionality to support multiple upstream 549 interfaces", draft-ietf-pim-multiple-upstreams-reqs-08 550 (work-in-progress), November 2018. 552 [8] Asaeda, H., "IGMP/MLD-Based Explicit Membership Tracking 553 Function for Multicast Routers", draft-ietf-pim-explicit- 554 tracking-13 (work-in-progress), November 2015. 556 [9] Liu, X., Guo, F., Sivakumar, M., McAllister, P., and A. 557 Peter, "A YANG Data Model for Internet Group Management 558 Protocol (IGMP) and Multicast Listener Discovery (MLD)", 559 draft-ietf-pim-igmp-mld-yang-15 (work-in-progress), June 560 2019. 562 Authors' Addresses 564 Hitoshi Asaeda 565 National Institute of Information and Communications Technology 566 4-2-1 Nukui-Kitamachi 567 Koganei, Tokyo 184-8795 568 Japan 570 Email: asaeda@nict.go.jp 571 Luis M. Contreras 572 Telefonica 573 Ronda de la Comunicacion, s/n 574 Sur-3 building, 3rd floor 575 Madrid 28050 576 Spain 578 Email: luismiguel.contrerasmurillo@telefonica.com 579 URI: http://lmcontreras.com/