idnits 2.17.1 draft-ietf-mboned-multicast-yang-model-03.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 374 has weird spacing: '...ss-node ine...' == Line 379 has weird spacing: '...ss-node uin...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2020) is 1510 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) == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-17 == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-08) exists of draft-ietf-bier-bier-yang-06 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-02 == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-04 == Outdated reference: A later version (-12) exists of draft-ietf-bier-pim-signaling-08 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-06 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-14 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-04 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED WG Z. Zhang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track C. Wang 5 Expires: September 8, 2020 Individual 6 Y. Cheng 7 China Unicom 8 X. Liu 9 Volta Networks 10 M. Sivakumar 11 Juniper networks 12 March 7, 2020 14 Multicast YANG Data Model 15 draft-ietf-mboned-multicast-yang-model-03 17 Abstract 19 This document provides a general multicast YANG data model, which 20 takes full advantages of existed multicast protocol models to control 21 the multicast network, and guides the deployment of multicast 22 service. 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 8, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 61 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 63 1.5. Usage of Multicast Model . . . . . . . . . . . . . . . . 4 64 2. Design of the multicast model . . . . . . . . . . . . . . . . 6 65 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. UML like Class Diagram for Multicast YANG data Model . . 7 69 3.2. Model Structure . . . . . . . . . . . . . . . . . . . . . 9 70 3.3. Multicast YANG data model Configuration . . . . . . . . . 12 71 3.4. Multicast YANG data model State . . . . . . . . . . . . . 12 72 3.5. Multicast YANG data model Notification . . . . . . . . . 12 73 4. Multicast YANG data Model . . . . . . . . . . . . . . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 79 8.2. Informative References . . . . . . . . . . . . . . . . . 31 80 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 33 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 83 1. Introduction 85 Currently, there are many multicast protocol YANG models, such as 86 PIM, MLD, and BIER and so on. But all these models are distributed 87 in different working groups as separate files and focus on the 88 protocol itself. Furthermore, they cannot describe a high-level 89 multicast service required by network operators. 91 This document provides a general and all-round multicast model, which 92 stands at a high level to take full advantages of these 93 aforementioned models to control the multicast network, and guide the 94 deployment of multicast service. 96 This model is designed to be used along with other multicast YANG 97 models such as PIM [I-D.ietf-pim-yang], which are not covered in this 98 document. 100 1.1. Terminology 102 The terminology for describing YANG data models is found in [RFC6020] 103 and [RFC7950], including: 105 o augment 107 o data model 109 o data node 111 o identity 113 o module 115 The following abbreviations are used in this document and the defined 116 model: 118 BIER: Bit Index Explicit Replication [RFC8279]. 120 MLD: Multicast Listener Discovery [I-D.ietf-bier-mld]. 122 PIM: Protocol Independent Multicast [RFC7761]. 124 BGP: Border Gateway Protocol [RFC4271]. 126 MVPN: Multicast in MPLS/BGP IP VPNs [RFC6513]. 128 MLDP: Label Distribution Protocol Extensions for Point-to-Multipoint 129 and Multipoint-to-Multipoint Label Switched Paths [RFC6388]. 131 OSPF: Open Shortest Path First [RFC2328]. 133 ISIS: Intermediate System to Intermediate System Routeing Exchange 134 Protocol [RFC1195]. 136 BABEL: [I-D.ietf-babel-rfc6126bis]. 138 P2MP-TE: Point-to-Multipoint Traffic Engineering [RFC4875]. 140 BIER-TE: Traffic Engineering for Bit Index Explicit Replication 141 [I-D.ietf-bier-te-arch]. 143 1.2. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 1.3. Tree Diagrams 153 Tree diagrams used in this document follow the notation defined in 154 [RFC8340]. 156 1.4. Prefixes in Data Node Names 158 In this document, names of data nodes, actions, and other data model 159 objects are often used without a prefix, as long as it is clear from 160 the context in which YANG module each name is defined. Otherwise, 161 names are prefixed using the standard prefix associated with the 162 corresponding YANG module, as shown in Table 1. 164 +----------+--------------------+----------------------+ 165 | Prefix | YANG module | Reference | 166 +----------+--------------------+----------------------+ 167 | inet | ietf-inet-types | [RFC6991] | 168 | | | | 169 | rt-types | ietf-routing-types | [RFC8294] | 170 | | | | 171 | rt | ietf-routing | [RFC8349] | 172 | | | | 173 | ospf | ietf-ospf | [I-D.ietf-ospf-yang] | 174 +----------+--------------------+----------------------+ 176 Table 1 178 1.5. Usage of Multicast Model 180 This multicast YANG data model is mainly used by the management tools 181 run by the network operators, in order to manage, monitor and debug 182 the network resources which are used to deliver multicast service. 183 This model is used for gathering data from the network as well. 185 +------------------------+ 186 | Multicast Model | 187 +------------------------+ 188 | | | 189 | | | 190 | +---------+ +----------+ 191 | | EMS/NMS | |Controller| 192 | +---------+ +----------+ 193 | | | 194 | | | 195 +------------------------------------------------+ 196 | Network Element1.....N | 197 +------------------------------------------------+ 199 Figure 1: Usage of Multicast Model 201 Detailly, in figure 1, there is an example of usage of this multicast 202 model. Network operators can use this model in a controller which is 203 responsible to implement specific multicast flows with specific 204 protocols and invoke the corresponding protocols' model to configure 205 the network elements through NETCONF/RESTCONF/CLI. Or network 206 operators can use this model to the EMS/NMS to manage the network 207 elements or configure the network elements directly. 209 +------------+ 210 | +----------------------------+ 211 +--------------+ Controller | | 212 | | +-----------+ | 213 | +------------+ | | 214 | | | 215 | +-----------------------------+ | | 216 | | | | | 217 | | +------+---+--+ | 218 | | |Egress router+--+ Receiver | 219 | | +------+------+ | 220 +---+-----+----+ | | 221 Source +-|Ingress router| BIER domain | | 222 +---------+----+ | | 223 | +------+------+ | 224 | |Egress router+--+ Receiver | 225 | +------+----+-+ | 226 | | | | 227 +-----------------------------+ +---------------+ 229 Figure 2: Example 231 The network administrator can use the multicast model and associated 232 models to deploy the multicast service. For example, suppose that 233 the flow for a multicast service is 233.252.0.0/16, the flow should 234 be forwarded by BIER [RFC8279] with MPLS encapsulation [RFC8296]. 235 Correspoding IGP protocol which is used to build BIER transport layer 236 is OSPF [RFC2328]. 238 In this model, the correspond key is set to 233.252.0.0/16, the 239 transport technology is set to BIER. The BIER underlay protocol is 240 set to OSPF. The model is sent to every egde router from the 241 controller. If the BIER transport layer which depends on OSPF has 242 not been built in the network, the multicast YANG model will invoke 243 the BIER YANG model which is defined in [I-D.ietf-bier-bier-yang] 244 generation in the controller. After the BIER transport layer is 245 built, the ingress router encapsulates the multicast flow with BIER 246 header and sends it into the network. Intermediate routers forward 247 the flows to all the egress nodes by BIER forwarding. 249 On the other hand, when the network elements detect failure or some 250 other changes, the network devices can send the affected multicast 251 flows and the associated overlay/ transport/ underlay information to 252 the controller. Then the controller/ EMS/NMS can response 253 immediately due to the failure and distribute new model for the flows 254 to the network nodes quickly. Such as the changing of the failure 255 overlay protocol to another one, as well as transport and underlay 256 protocol. 258 Specifically, in section 3, it provides a human readability of the 259 whole multicast network through UML like class diagram, which frames 260 different multicast components and correlates them in a readable 261 fashion. Then, based on this UML like class diagram, there is 262 instantiated and detailed YANG model in Section 5. 264 In other words, this document does not define any specific protocol 265 model, instead, it depends on many existed multicast protocol models 266 and relates several multicast information together to fulfill 267 multicast service. 269 2. Design of the multicast model 271 2.1. Scope of Model 273 This model can be used to configure and manage Multicast service. 274 The operational state data can be retrieved by this model. The 275 subscription and push mechanism defined in [RFC8639] and [RFC8641] 276 can be implemented by the user to subscribe to notifications on the 277 data nodes in this model. 279 The model contains all the basic configuration parameters to operate 280 the model. Depending on the implementation choices, some systems may 281 not allow some of the advanced parameters to be configurable. The 282 occasionally implemented parameters are modeled as optional features 283 in this model. This model can be extended, and it has been 284 structured in a way that such extensions can be conveniently made. 286 2.2. Specification 288 The configuration data nodes cover configurations. The container 289 "multicast-model" is the top level container in this data model. The 290 presence of this container is expected to enable Multicast service 291 functionality. The notification includes the error reason and the 292 associated data nodes. 294 3. Module Structure 296 This model imports and augments the ietf-routing YANG model defined 297 in [RFC8349]. Both configuration data nodes and state data nodes of 298 [RFC8349] are augmented. 300 The YANG data model defined in this document conforms to the Network 301 Management Datastore Architecture (NMDA) [RFC8342]. The operational 302 state data is combined with the associated configuration data in the 303 same hierarchy [RFC8407]. 305 3.1. UML like Class Diagram for Multicast YANG data Model 307 The following is a UML like diagram for Multicast YANG data Model. 309 +-----------+ 310 +-----+Multi|keys | 311 | +-----------+ 312 | |Group Addr | 313 | +-----------+ 314 | |Source Addr| +--------+-----------------+ 315 | +-----------+ | | | 316 | |VPN Info | | | +------+-------+ 317 | +-----------+ | +-----+------+ | Ing/Eg Nodes | 318 | |VNI Info | | |Overlay Tech| +--------------+ 319 | +-----------+ | +------------+ |Ingress Nodes | 320 | | | MLD | +--------------+ 321 | | +------------+ |Egress Nodes | 322 | Contain | | MVPN | +-------+------+ 323 | +-----------+ | +------------+ | relate 324 | | Multicast +----+ | BGP | \|/ 325 +-----+ Overlay | +------------+ +----------------+ 326 | | | |MLD|Snooping| | BIER Nodes Info| 327 | +-----------+ +------------+ +----------------+ 328 | | BFR|ID | 329 | +----------------+ 330 | 331 +--------+--+ +---------------+----------+----------+ 332 | Multicast |Contain | | | | 333 | Model | | +--+---+ +---+----+ +--+---+ 334 +--------+--+ | | MPLS | |BIER|TE | | BIER | 335 | +---------+--+ +------+ +--------+ +------+ 336 | | Multicast | 337 +----+ Transport | invoke +-----+ +----------+ 338 | | | | PIM | |Cisco Mode| 339 | +---------+--+ +--+--+ +----+-----+ 340 | | | | 341 | | | | 342 | +---------------+-----------+ 343 | 344 | +--------------+---------+---------+ 345 | | | | | 346 | | +--+---+ +--+---+ +--+--+ 347 | +----------+-- | OSPF | | PIM | |BABEL| 348 | | Multicast | +------+ +------+ +-----+ 349 +----+ Underlay | invoke 350 | | +------+ +------+ 351 +----------+-- | ISIS | | BGP | 352 | +--+---+ +--+---+ 353 | | | 354 +--------------+---------+ 356 Figure 3: UML like Class Diagram for Multicast YANG data Model 358 3.2. Model Structure 360 module: ietf-multicast-model 361 +--rw multicast-model 362 +--rw multicast-keys* [vpn-rd source-address group-address 363 vni-type vni-value] 364 +--rw vpn-rd rt-types:route-distinguisher 365 +--rw source-address ip-multicast-source-address 366 +--rw group-address 367 rt-types:ip-multicast-group-address 368 +--rw vni-type virtual-type 369 +--rw vni-value uint32 370 +--rw multicast-overlay 371 | +--rw ingress-egress 372 | | +--rw ingress-node? inet:ip-address 373 | | +--rw egress-nodes* [egress-node] 374 | | +--rw egress-node inet:ip-address 375 | +--rw bier-ids 376 | | +--rw sub-domain? uint16 377 | | +--rw ingress-node? uint16 378 | | +--rw egress-nodes* [egress-node] 379 | | +--rw egress-node uint16 380 | +--rw (overlay-tech-type)? 381 | +--:(bgp) 382 | +--:(evpn) 383 | +--:(mld) 384 | | +--rw mld-instance-group? 385 rt-types:ip-multicast-group-address 386 | +--:(mld-snooping) 387 | +--:(mvpn) 388 | +--:(pim) 389 +--rw multicast-transport 390 | +--rw (transport)? 391 | +--:(bier) 392 | | +--rw bier 393 | | +--rw sub-domain? uint16 394 | | +--rw bitstringlength? uint16 395 | | +--rw set-identifier? uint16 396 | | +--rw (encap-type)? 397 | | +--:(mpls) 398 | | +--:(eth) 399 | | +--:(ipv6) 400 | +--:(bier-te) 401 | | +--rw bier-te 402 | | +--rw sub-domain? uint16 403 | | +--rw bitstringlength? uint16 404 | | +--rw set-identifier? uint16 405 | | +--rw (encap-type)? 406 | | | +--:(mpls) 407 | | | +--:(eth) 408 | | | +--:(ipv6) 409 | | +--rw bier-te-adj* uint16 410 | +--:(cisco-mode) 411 | | +--rw cisco-mode 412 | | +--rw p-group? 413 rt-types:ip-multicast-group-address 414 | +--:(mpls) 415 | | +--rw mpls 416 | | +--rw (mpls-tunnel-type)? 417 | | +--:(mldp) 418 | | | +--rw mldp-tunnel-id? uint32 419 | | | +--rw mldp-backup-tunnel? boolean 420 | | +--:(p2mp-te) 421 | | +--rw te-tunnel-id? uint32 422 | | +--rw te-backup-tunnel? boolean 423 | +--:(pim) 424 | +--rw pim 425 +--rw multicast-underlay 426 +--rw (underlay)? 427 +--:(bgp) 428 +--:(ospf) 429 | +--rw ospf 430 | +--rw topology? 431 -> /rt:routing/control-plane-protocols 432 /control-plane-protocol/ospf:ospf 433 /topologies/topology/name 434 +--:(isis) 435 +--:(babel) 437 notifications: 438 +---n head-end-event 439 +--ro event-type? enumeration 440 +--ro multicast-key 441 | +--ro vpn-rd? rt-types:route-distinguisher 442 | +--ro source-address? ip-multicast-source-address 443 | +--ro group-address? rt-types:ip-multicast-group-address 444 | +--ro vni-type? virtual-type 445 | +--ro vni-value? uint32 446 +--ro (overlay-tech-type)? 447 | +--:(bgp) 448 | +--:(evpn) 449 | +--:(mld) 450 | | +--ro mld-instance-group? 451 rt-types:ip-multicast-group-address 452 | +--:(mld-snooping) 453 | +--:(mvpn) 454 | +--:(pim) 455 +--ro transport-tech 456 | +--ro (transport)? 457 | +--:(bier) 458 | | +--ro bier 459 | | +--ro sub-domain? uint16 460 | | +--ro bitstringlength? uint16 461 | | +--ro set-identifier? uint16 462 | | +--ro (encap-type)? 463 | | +--:(mpls) 464 | | +--:(eth) 465 | | +--:(ipv6) 466 | +--:(bier-te) 467 | | +--ro bier-te 468 | | +--ro sub-domain? uint16 469 | | +--ro bitstringlength? uint16 470 | | +--ro set-identifier? uint16 471 | | +--ro (encap-type)? 472 | | | +--:(mpls) 473 | | | +--:(eth) 474 | | | +--:(ipv6) 475 | | +--ro bier-te-adj* uint16 476 | +--:(cisco-mode) 477 | | +--ro cisco-mode 478 | | +--ro p-group? rt-types:ip-multicast-group-address 479 | +--:(mpls) 480 | | +--ro mpls 481 | | +--ro (mpls-tunnel-type)? 482 | | +--:(mldp) 483 | | | +--ro mldp-tunnel-id? uint32 484 | | | +--ro mldp-backup-tunnel? boolean 485 | | +--:(p2mp-te) 486 | | +--ro te-tunnel-id? uint32 487 | | +--ro te-backup-tunnel? boolean 488 | +--:(pim) 489 | +--ro pim 490 +--ro underlay-tech 491 +--ro (underlay)? 492 +--:(bgp) 493 +--:(ospf) 494 | +--ro ospf 495 | +--ro topology? 496 -> /rt:routing/control-plane-protocols 497 /control-plane-protocol/ospf:ospf 498 /topologies/topology/name 499 +--:(isis) 500 +--:(babel) 502 3.3. Multicast YANG data model Configuration 504 This model is used with other protocol data model to provide 505 multicast service. 507 This model includes multicast service keys and three layers: the 508 multicast overlay, the transport layer and the multicast underlay 509 information. Multicast keys include the features of multicast flow, 510 such as(vpnid, multicast source and multicast group) information. In 511 data center network, for fine-grained to gather the nodes belonging 512 to the same virtual network, there may need VNI-related information 513 to assist. 515 Multicast overlay defines (ingress-node, egress-nodes) nodes 516 information. If the transport layer is BIER, there may define BIER 517 information including (Subdomain, ingress-node BFR-id, egress-nodes 518 BFR-id). If no (ingress-node, egress-nodes) information are defined 519 directly, there may need overlay multicast signaling technology, such 520 as MLD or MVPN, to collect these nodes information. 522 Multicast transport layer defines the type of transport technologies 523 that can be used to forward multicast flow, including BIER forwarding 524 type, MPLS forwarding type, or PIM forwarding type and so on. One or 525 several transport technologies could be defined at the same time. As 526 for the detailed parameters for each transport technology, this 527 multicast YANG data model can invoke the corresponding protocol model 528 to define them. 530 Multicast underlay defines the type of underlay technologies, such as 531 OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay 532 technologies could be defined at the same time if there is protective 533 requirement. As for the specific parameters for each underlay 534 technology, this multicast YANG data model can depend the 535 corresponding protocol model to configure them as well. 537 The configuration modeling branch is composed of the keys, overlay 538 layer, transport layer and underlay layer. 540 3.4. Multicast YANG data model State 542 Multicast model states are the same with the configuration. 544 3.5. Multicast YANG data model Notification 546 The defined Notifications include the events of head end nodes. Like 547 head node failer, overlay/ transport/ underlay module loading/ 548 unloading. And the potential failer about some multicast flows and 549 associated overlay/ transport/ underlay technologies. 551 4. Multicast YANG data Model 553 This module references [RFC1195], [RFC2328], [RFC4271], [RFC4541], 554 [RFC4875], [RFC5340], [RFC6037], [RFC6388], [RFC6513], [RFC6991], 555 [RFC7348], [RFC7432], [RFC7637], [RFC7716], [RFC7761], [RFC8279], 556 [RFC8294], [RFC8296], [RFC8343], [RFC8344], [RFC8349], [RFC8639], 557 [RFC8641], [I-D.ietf-pim-yang], [I-D.ietf-bier-bier-yang], 558 [I-D.ietf-bier-te-arch], [I-D.ietf-nvo3-geneve], [I-D.ietf-bier-mld], 559 [I-D.ietf-bess-evpn-bum-procedure-updates], [I-D.ietf-bier-evpn], 560 [I-D.zhang-bier-bierin6], [I-D.ietf-babel-rfc6126bis], 561 [I-D.ietf-bier-pim-signaling]. 563 file "ietf-multicast-model@2020-03-06.yang" 564 module ietf-multicast-model { 566 yang-version 1.1; 568 namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model"; 569 prefix multicast-model; 571 import ietf-inet-types { 572 prefix "inet"; 573 reference 574 "RFC 6991: Common YANG Data Types"; 575 } 576 import ietf-routing-types { 577 prefix "rt-types"; 578 reference 579 "RFC 8294: Common YANG Data Types for the Routing Area"; 580 } 581 import ietf-routing { 582 prefix "rt"; 583 reference 584 "RFC 8349: A YANG Data Model for Routing Management 585 (NMDA Version)"; 586 } 587 import ietf-ospf { 588 prefix "ospf"; 589 reference 590 "I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol"; 591 } 593 organization " IETF MBONED (MBONE Deployment) Working Group"; 594 contact 595 "WG List: 597 Editor: Zheng Zhang 598 600 Editor: Cui Wang 601 602 Editor: Ying Cheng 603 604 Editor: Xufeng Liu 605 606 Editor: Mahesh Sivakumar 607 608 "; 610 // RFC Ed.: replace XXXX with actual RFC number and remove 611 // this note 613 description 614 "The module defines the YANG definitions for multicast service 615 management. 617 Copyright (c) 2020 IETF Trust and the persons identified as 618 authors of the code. All rights reserved. 620 Redistribution and use in source and binary forms, with or 621 without modification, is permitted pursuant to, and subject 622 to the license terms contained in, the Simplified BSD 623 License set forth in Section 4.c of the IETF Trust's Legal 624 Provisions Relating to IETF Documents 625 (https://trustee.ietf.org/license-info). 627 This version of this YANG module is part of RFC XXXX 628 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 629 itself for full legal notices. 631 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 632 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 633 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 634 are to be interpreted as described in BCP 14 (RFC 2119) 635 (RFC 8174) when, and only when, they appear in all 636 capitals, as shown here."; 638 revision 2020-03-06 { 639 description 640 "Initial revision."; 641 reference 642 "RFC XXXX: A YANG Data Model for multicast YANG."; 643 } 645 /* 646 *typedef 647 */ 649 typedef ip-multicast-source-address { 650 type union { 651 type rt-types:ipv4-multicast-source-address; 652 type rt-types:ipv6-multicast-source-address; 653 } 654 description 655 "This type represents a version-neutral IP multicast 656 source address. The format of the textual 657 representation implies the IP version."; 658 reference 659 "RFC8294: Common YANG Data Types for the Routing Area."; 660 } 662 typedef virtual-type { 663 type enumeration { 664 enum vxlan { 665 description 666 "The VXLAN encapsulation is used for flow encapsulation."; 667 reference 668 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 669 A Framework for Overlaying Virtualized Layer 2 Networks 670 over Layer 3 Networks."; 671 } 672 enum nvgre { 673 description 674 "The NVGRE encapsulation is used for flow encapsulation."; 675 reference 676 "RFC 7637: NVGRE: Network Virtualization Using Generic 677 Routing Encapsulation."; 678 } 679 enum geneve { 680 description 681 "The GENEVE encapsulation is used for flow encapsulation."; 682 reference 683 "I-D.ietf-nvo3-geneve: Geneve: Generic Network 684 Virtualization Encapsulation."; 685 } 686 } 687 description 688 "The encapsulation type used for the flow. In case the virtual 689 type is set, the associated vni-value should also be defined."; 690 } // virtual-type 692 /* 693 * Identities 694 */ 696 identity multicast-model { 697 base rt:control-plane-protocol; 698 description "Identity for the Multicast model."; 699 } 701 grouping general-multicast-key { 702 description 703 "The general multicast keys. They are used to distinguish 704 different multicast service."; 705 leaf vpn-rd { 706 type rt-types:route-distinguisher; 707 description 708 "A Route Distinguisher used to distinguish 709 routes from different MVPNs."; 710 reference 711 "RFC 8294: Common YANG Data Types for the Routing Area. 712 RFC 6513: Multicast in MPLS/BGP IP VPNs."; 713 } 714 leaf source-address { 715 type ip-multicast-source-address; 716 description 717 "The IPv4/IPv6 source address of the multicast flow. The 718 value set to zero means that the receiver interests 719 in all source that relevant to one given group."; 720 } 721 leaf group-address { 722 type rt-types:ip-multicast-group-address; 723 description 724 "The IPv4/IPv6 group address of multicast flow. This 725 type represents a version-neutral IP multicast group 726 address. The format of the textual representation 727 implies the IP version."; 728 reference 729 "RFC8294: Common YANG Data Types for the Routing Area."; 730 } 731 leaf vni-type { 732 type virtual-type; 733 description 734 "The type of virtual network identifier. Includes the 735 Vxlan, NVGRE and Geneve. This value and vni-value is 736 used to indicate a specific virtual multicast service."; 737 } 738 leaf vni-value { 739 type uint32; 740 description 741 "The value of Vxlan network identifier, virtual subnet ID 742 or virtual net identifier. This value and vni-type is used 743 to indicate a specific virtual multicast service."; 744 } 746 } // general-multicast-key 748 grouping encap-type { 749 description 750 "The encapsulation type used for flow forwarding."; 751 choice encap-type { 752 case mpls { 753 description "The BIER forwarding depends on mpls."; 754 reference 755 "RFC 8296: Encapsulation for Bit Index Explicit 756 Replication (BIER) in MPLS and Non-MPLS Networks."; 757 } 758 case eth { 759 description "The BIER forwarding depends on ethernet."; 760 reference 761 "RFC 8296: Encapsulation for Bit Index Explicit 762 Replication (BIER) in MPLS and Non-MPLS Networks."; 763 } 764 case ipv6 { 765 description "The BIER forwarding depends on IPv6."; 766 reference 767 "I-D.zhang-bier-bierin6: BIER in IPv6 (BIERin6)"; 768 } 769 description "The encapsulation type in BIER."; 770 } 771 } // encap-type 773 grouping bier-key { 774 description 775 "The key parameters set for BIER/BIER TE forwarding."; 776 reference 777 "RFC 8279: Multicast Using Bit Index Explicit Replication 778 (BIER)."; 780 leaf sub-domain { 781 type uint16; 782 description 783 "The subdomain id that the multicast flow belongs to."; 784 } 785 leaf bitstringlength { 786 type uint16; 787 description 788 "The bitstringlength used by BIER forwarding."; 789 } 790 leaf set-identifier { 791 type uint16; 792 description 793 "The set identifier used by the multicast flow."; 795 } 796 uses encap-type; 797 } 799 grouping transport-tech { 800 choice transport { 801 description "The selected transport technology."; 802 container bier { 803 description 804 "The transport technology is BIER. The BIER technology 805 is introduced in RFC8279. The parameter is consistent 806 with the definition in BIER YANG data model."; 807 reference 808 "RFC 8279: Multicast Using Bit Index Explicit 809 Replication (BIER). 810 I-D.ietf-bier-bier-yang: YANG Data Model for BIER 811 Protocol."; 813 uses bier-key; 814 } 816 container bier-te { 817 description 818 "The transport technology is BIER-TE."; 819 reference 820 "I-D.ietf-bier-te-arch: Traffic Engineering for Bit Index 821 Explicit Replication (BIER-TE)"; 823 uses bier-key; 825 leaf-list bier-te-adj { 826 type uint16; 827 description 828 "The adjacencies ID used in BIER TE forwarding 829 encapsulation."; 830 } 831 } 833 container cisco-mode { 834 description 835 "The transport technology is cisco-mode: Cisco MDT."; 836 reference 837 "RFC 6037: Cisco Systems' Solution for Multicast in 838 BGP/MPLS IP VPNs"; 840 leaf p-group { 841 type rt-types:ip-multicast-group-address; 842 description 843 "The address of p-group. It is used to encapsulate 844 and forward flow according to multicast tree from 845 ingress node to egress nodes."; 846 } 847 uses transport-pim; 848 } 850 container mpls { 851 description 852 "The transport technology is mpls. MVPN overlay can use 853 mpls tunnel technologies to build transport layer."; 854 reference 855 "RFC 6513: Multicast in MPLS/BGP IP VPNs."; 857 choice mpls-tunnel-type { 858 case mldp { 859 description "The mldp tunnel."; 860 reference 861 "RFC 6388: Label Distribution Protocol Extensions 862 for Point-to-Multipoint and Multipoint-to-Multipoint 863 Label Switched Paths."; 865 leaf mldp-tunnel-id { 866 type uint32; 867 description 868 "The tunnel id that correspond this flow."; 869 } 870 leaf mldp-backup-tunnel { 871 type boolean; 872 description 873 "If the backup tunnel function should be 874 supported."; 875 } 876 } 877 case p2mp-te { 878 description 879 "The p2mp te tunnel."; 880 reference 881 "RFC 4875: Extensions to Resource Reservation Protocol 882 - Traffic Engineering (RSVP-TE) for Point-to-Multipoint 883 TE Label Switched Paths (LSPs)."; 885 leaf te-tunnel-id { 886 type uint32; 887 description 888 "The tunnel id that correspond this flow."; 889 } 890 leaf te-backup-tunnel { 891 type boolean; 892 description 893 "If the backup tunnel function should be 894 supported."; 895 } 896 } 897 description "The collection types of mpls tunnels"; 898 } 899 } // mpls 901 container pim { 902 description 903 "The transport technology is PIM. PIM is used 904 commonly in traditional network."; 905 reference 906 "RFC 7761: Protocol Independent Multicast - Sparse Mode 907 (PIM-SM): Protocol Specification (Revised)."; 908 uses transport-pim; 909 } 910 } // choice 911 } // transport-tech 913 grouping underlay-tech { 914 choice underlay { 915 case bgp { 916 description 917 "The underlay technology is BGP. BGP protocol 918 should be used to run if BGP is used as 919 underlay protocol."; 920 reference 921 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 922 } 923 container ospf { 924 description 925 "The underlay technology is OSPF. OSPF protocol 926 should be triggered to run if OSPF is used as underlay 927 protocol."; 928 reference 929 "RFC 2328: OSPF Version 2. 930 RFC 5340: OSPF for IPv6. 931 I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol."; 933 leaf topology { 934 type leafref { 935 path "/rt:routing/rt:control-plane-protocols/" 936 + "rt:control-plane-protocol/ospf:ospf/" 937 + "ospf:topologies/ospf:topology/ospf:name"; 938 } 939 description 940 "The designed topology name of ospf protocol."; 941 } 942 } 943 case isis { 944 description 945 "The underlay technology is ISIS. ISIS protocol should 946 be triggered to run if ISIS is used as underlay protocol. 947 And the associated extensions can be used."; 948 reference 949 "RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and 950 Dual Environments"; 951 } 952 case babel { 953 description 954 "The underlay technology is Babel. Babel protocol 955 should be triggered to run if Babel is used as 956 underlay protocol."; 957 reference 958 "I-D.ietf-babel-rfc6126bis: The Babel Routing Protocol."; 959 } 960 } // choice 961 } // underlay-tech 963 /*overlay*/ 965 grouping overlay-tech { 966 choice overlay-tech-type { 967 case bgp { 968 description 969 "BGP technology is used for multicast overlay."; 970 reference 971 "RFC 7716: Global Table Multicast with BGP Multicast 972 VPN (BGP-MVPN) Procedures."; 973 } 974 case evpn { 975 description 976 "EVPN technology is used for multicast overlay."; 977 reference 978 "RFC 7432: BGP MPLS-Based Ethernet VPN. 979 I-D.ietf-bess-evpn-bum-procedure-updates: Updates on 980 EVPN BUM Procedures. 981 I-D.ietf-bier-evpn: EVPN BUM Using BIER."; 982 } 983 case mld { 984 description 985 "MLD technology is used for multicast overlay."; 986 reference 987 "I-D.ietf-bier-mld: BIER Ingress Multicast Flow Overlay 988 using Multicast Listener Discovery Protocols."; 989 leaf mld-instance-group { 990 type rt-types:ip-multicast-group-address; 991 description 992 "The multicast address used for multiple MLD instance 993 support."; 994 } 995 } 996 case mld-snooping { 997 description 998 "MLD snooping technology is used for multicast overlay."; 999 reference 1000 "RFC 4541: Considerations for Internet Group Management 1001 Protocol (IGMP) and Multicast Listener 1002 Discovery (MLD) Snooping Switches."; 1003 } 1004 case mvpn { 1005 description 1006 "MVPN technology is used for multicast overlay."; 1007 reference 1008 "RFC 6513: Multicast in MPLS/BGP IP VPNs."; 1009 } 1010 case pim { 1011 description 1012 "PIM technology is used for multicast overlay."; 1013 reference 1014 "I-D.ietf-bier-pim-signaling: PIM Signaling 1015 Through BIER Core."; 1016 } 1017 description 1018 "The overlay technology used for multicast service."; 1019 } 1020 description "The overlay technology used for multicast service."; 1021 } // overlay-tech 1023 /*transport*/ 1025 grouping transport-pim { 1026 description 1027 "The requirement information of pim transportion."; 1028 reference 1029 "RFC 7761: Protocol Independent Multicast - Sparse Mode 1030 (PIM-SM): Protocol Specification (Revised)."; 1031 } //transport-pim 1033 /*underlay*/ 1034 container multicast-model { 1035 description 1036 "The model of multicast YANG data. Include keys, overlay, 1037 transport and underlay."; 1039 list multicast-keys{ 1040 key "vpn-rd source-address group-address vni-type vni-value"; 1041 uses general-multicast-key; 1043 container multicast-overlay { 1044 description 1045 "The overlay information of multicast service. 1046 Overlay technology is used to exchange multicast 1047 flows information. Overlay technology may not be 1048 used in SDN controlled completely situation, but 1049 it can be used in partial SDN controlled situation 1050 or non-SDN controlled situation. Different overlay 1051 technologies can be choosed according to different 1052 deploy consideration."; 1054 container ingress-egress { 1055 description 1056 "The ingress and egress nodes address collection. 1057 The ingress node may use the egress nodes set 1058 directly to encapsulate the multicast flow by 1059 transport technology."; 1061 leaf ingress-node { 1062 type inet:ip-address; 1063 description 1064 "The ip address of ingress node for one or more 1065 multicast flow. Or the ingress node of MVPN and 1066 BIER. In MVPN, this is the address of ingress 1067 PE; in BIER, this is the BFR-prefix of ingress 1068 nodes."; 1069 } 1070 list egress-nodes { 1071 key "egress-node"; 1072 description 1073 "The egress multicast nodes of the multicast flow. 1074 Or the egress node of MVPN and BIER. In MVPN, this 1075 is the address of egress PE; in BIER, this is the 1076 BFR-prefix of ingress nodes."; 1078 leaf egress-node { 1079 type inet:ip-address; 1080 description 1081 "The ip-address set of egress multicast nodes."; 1083 } 1084 } 1085 } 1087 container bier-ids { 1088 description 1089 "The BFR-ids of ingress and egress BIER nodes for 1090 one or more multicast flows. This overlay is used 1091 with BIER transport technology. The egress nodes 1092 set can be used to encapsulate the multicast flow 1093 directly in the ingress node."; 1094 reference 1095 "RFC 8279: Multicast Using Bit Index Explicit 1096 Replication (BIER)"; 1098 leaf sub-domain { 1099 type uint16; 1100 description 1101 "The sub-domain that this multicast flow belongs to."; 1102 } 1103 leaf ingress-node { 1104 type uint16; 1105 description 1106 "The ingress node of multicast flow. This is the 1107 BFR-id of ingress nodes."; 1108 } 1109 list egress-nodes { 1110 key "egress-node"; 1111 description 1112 "The egress nodes of multicast flow."; 1114 leaf egress-node { 1115 type uint16; 1116 description 1117 "The BFR-ids of egress multicast BIER nodes."; 1118 } 1119 } 1120 } 1121 uses overlay-tech; 1122 } 1124 container multicast-transport { 1125 description 1126 "The transportion of multicast service. Transport 1127 protocol is responsible for delivering multicast 1128 flows from ingress nodes to egress nodes with or 1129 without specific encapsulation. Different transport 1130 technology can be choosed according to different 1131 deploy consideration. Once a transport technology 1132 is choosed, associated protocol should be triggered 1133 to run."; 1135 uses transport-tech; 1136 } 1137 container multicast-underlay { 1138 description 1139 "The underlay of multicast service. Underlay protocol 1140 is used to build transport layer. Underlay protocol 1141 need not be assigned in ordinary network since 1142 existed underlay protocol fits well, but it can be 1143 assigned in particular networks for better 1144 controll. Once a underlay technology is choosed, 1145 associated protocol should be triggered to run."; 1147 uses underlay-tech; 1148 } 1149 description 1150 "The model of multicast YANG data. Include keys, 1151 overlay, transport and underlay."; 1152 } 1153 } 1155 /*Notifications*/ 1157 notification head-end-event { 1158 leaf event-type { 1159 type enumeration { 1160 enum down { 1161 description 1162 "There is something wrong with head end node, 1163 and head end node can't work properlay."; 1164 } 1165 enum module-loaded { 1166 description 1167 "The new modules that can be used by multicast 1168 flows have been loaded."; 1169 } 1170 enum module-unloaded { 1171 description 1172 "The new modules that can be used by multicast 1173 flows have been unloaded."; 1174 } 1175 } 1176 description "Event type."; 1177 } 1178 container multicast-key { 1179 uses general-multicast-key; 1180 description 1181 "The associated multicast keys that are influenced by 1182 head end node failer."; 1183 } 1184 uses overlay-tech; 1186 container transport-tech { 1187 description 1188 "The modules can be used to forward multicast flows."; 1189 uses transport-tech; 1190 } 1192 container underlay-tech { 1193 description 1194 "There is something wrong with the module which is 1195 used to build multicast transport layer."; 1196 uses underlay-tech; 1197 } 1198 description 1199 "Notification events for the head end nodes. Like head 1200 node failer, overlay/ transport/ underlay module 1201 loading/ unloading. And the potential failer about some 1202 multicast flows and associated 1203 overlay/ transport/ underlay technologies."; 1204 } 1205 } 1206 1208 5. Security Considerations 1210 The YANG module specified in this document defines a schema for data 1211 that is designed to be accessed via network management protocols such 1212 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1213 is the secure transport layer, and the mandatory-to-implement secure 1214 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1215 is HTTPS, and the mandatory-to-implement secure transport is TLS 1216 [RFC8446]. 1218 The NETCONF access control model [RFC8341] provides the means to 1219 restrict access for particular NETCONF or RESTCONF users to a 1220 preconfigured subset of all available NETCONF or RESTCONF protocol 1221 operations and content. 1223 There are a number of data nodes defined in this YANG module that are 1224 writable/creatable/deletable (i.e., config true, which is the 1225 default). These data nodes may be considered sensitive or vulnerable 1226 in some network environments. Write operations (e.g., edit-config) 1227 to these data nodes without proper protection can have a negative 1228 effect on network operations. These are data nodes and their 1229 sensitivity/vulnerability: 1231 Under /rt:routing/rt:control-plane-protocols/multicast-model, 1233 multicast-model 1235 These data nodes in this model specifies the configuration for the 1236 multicast service at the top level. Modifying the configuration 1237 can cause multicast service to be deleted or reconstructed. 1239 Some of the readable data nodes in this YANG module may be considered 1240 sensitive or vulnerable in some network environments. It is thus 1241 important to control read access (e.g., via get, get-config, or 1242 notification) to these data nodes. These are the data nodes and 1243 their sensitivity/vulnerability: 1245 /rt:routing/rt:control-plane-protocols/multicast-model, 1247 Unauthorized access to any data node of the above tree can disclose 1248 the operational state information of multicast service on this 1249 device. 1251 6. IANA Considerations 1253 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1254 number (and remove this note). 1256 The IANA is requested to assign one new URI from the IETF XML 1257 registry [RFC3688]. Authors are suggesting the following URI: 1259 URI: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1261 Registrant Contact: The IESG 1263 XML: N/A, the requested URI is an XML namespace 1265 This document also requests one new YANG module name in the YANG 1266 Module Names registry [RFC6020] with the following suggestion: 1268 name: ietf-multicast-model 1270 namespace: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1272 prefix: multicast-model 1274 reference: RFC XXXX 1276 7. Acknowledgements 1278 The authors would like to thank Stig Venaas, Jake Holland, Min Gu for 1279 their valuable comments and suggestions. 1281 8. References 1283 8.1. Normative References 1285 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1286 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1287 December 1990, . 1289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1290 Requirement Levels", BCP 14, RFC 2119, 1291 DOI 10.17487/RFC2119, March 1997, 1292 . 1294 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1295 DOI 10.17487/RFC2328, April 1998, 1296 . 1298 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1299 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1300 DOI 10.17487/RFC4271, January 2006, 1301 . 1303 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1304 Yasukawa, Ed., "Extensions to Resource Reservation 1305 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1306 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1307 DOI 10.17487/RFC4875, May 2007, 1308 . 1310 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1311 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1312 . 1314 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1315 the Network Configuration Protocol (NETCONF)", RFC 6020, 1316 DOI 10.17487/RFC6020, October 2010, 1317 . 1319 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1320 and A. Bierman, Ed., "Network Configuration Protocol 1321 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1322 . 1324 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1325 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1326 . 1328 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1329 Thomas, "Label Distribution Protocol Extensions for Point- 1330 to-Multipoint and Multipoint-to-Multipoint Label Switched 1331 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1332 . 1334 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1335 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1336 2012, . 1338 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1339 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1340 . 1342 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1343 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1344 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1345 2015, . 1347 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 1348 and D. Pacella, "Global Table Multicast with BGP Multicast 1349 VPN (BGP-MVPN) Procedures", RFC 7716, 1350 DOI 10.17487/RFC7716, December 2015, 1351 . 1353 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1354 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1355 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1356 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1357 2016, . 1359 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1360 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1361 . 1363 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1364 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1365 . 1367 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1368 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1369 . 1371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1373 May 2017, . 1375 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1376 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1377 Explicit Replication (BIER)", RFC 8279, 1378 DOI 10.17487/RFC8279, November 2017, 1379 . 1381 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1382 "Common YANG Data Types for the Routing Area", RFC 8294, 1383 DOI 10.17487/RFC8294, December 2017, 1384 . 1386 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1387 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1388 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1389 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1390 2018, . 1392 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1393 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1394 . 1396 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1397 Access Control Model", STD 91, RFC 8341, 1398 DOI 10.17487/RFC8341, March 2018, 1399 . 1401 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1402 and R. Wilton, "Network Management Datastore Architecture 1403 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1404 . 1406 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1407 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1408 . 1410 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1411 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1412 . 1414 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1415 Routing Management (NMDA Version)", RFC 8349, 1416 DOI 10.17487/RFC8349, March 2018, 1417 . 1419 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1420 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1421 . 1423 8.2. Informative References 1425 [I-D.ietf-babel-rfc6126bis] 1426 Chroboczek, J. and D. Schinazi, "The Babel Routing 1427 Protocol", draft-ietf-babel-rfc6126bis-17 (work in 1428 progress), February 2020. 1430 [I-D.ietf-bess-evpn-bum-procedure-updates] 1431 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 1432 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 1433 bess-evpn-bum-procedure-updates-08 (work in progress), 1434 November 2019. 1436 [I-D.ietf-bier-bier-yang] 1437 Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d., 1438 and M. Sivakumar, "YANG Data Model for BIER Protocol", 1439 draft-ietf-bier-bier-yang-06 (work in progress), February 1440 2020. 1442 [I-D.ietf-bier-evpn] 1443 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 1444 "EVPN BUM Using BIER", draft-ietf-bier-evpn-02 (work in 1445 progress), November 2019. 1447 [I-D.ietf-bier-mld] 1448 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 1449 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 1450 using Multicast Listener Discovery Protocols", draft-ietf- 1451 bier-mld-04 (work in progress), March 2020. 1453 [I-D.ietf-bier-pim-signaling] 1454 Bidgoli, H., Kotalwar, J., Xu, F., mishra, m., Zhang, Z., 1455 and A. Dolganow, "PIM Signaling Through BIER Core", draft- 1456 ietf-bier-pim-signaling-08 (work in progress), November 1457 2019. 1459 [I-D.ietf-bier-te-arch] 1460 Eckert, T., Cauchie, G., and M. Menth, "Path Engineering 1461 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 1462 bier-te-arch-06 (work in progress), February 2020. 1464 [I-D.ietf-nvo3-geneve] 1465 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 1466 Network Virtualization Encapsulation", draft-ietf- 1467 nvo3-geneve-14 (work in progress), September 2019. 1469 [I-D.ietf-ospf-yang] 1470 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 1471 "YANG Data Model for OSPF Protocol", draft-ietf-ospf- 1472 yang-29 (work in progress), October 2019. 1474 [I-D.ietf-pim-yang] 1475 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1476 Y., and f. hu, "A YANG Data Model for Protocol Independent 1477 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1478 progress), May 2018. 1480 [I-D.zhang-bier-bierin6] 1481 Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and 1482 M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 1483 bierin6-04 (work in progress), January 2020. 1485 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1486 DOI 10.17487/RFC3688, January 2004, 1487 . 1489 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1490 "Considerations for Internet Group Management Protocol 1491 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1492 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 1493 . 1495 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 1496 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 1497 RFC 6037, DOI 10.17487/RFC6037, October 2010, 1498 . 1500 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1501 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1502 eXtensible Local Area Network (VXLAN): A Framework for 1503 Overlaying Virtualized Layer 2 Networks over Layer 3 1504 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1505 . 1507 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1508 Virtualization Using Generic Routing Encapsulation", 1509 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1510 . 1512 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1513 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1514 DOI 10.17487/RFC8407, October 2018, 1515 . 1517 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1518 E., and A. Tripathy, "Subscription to YANG Notifications", 1519 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1520 . 1522 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1523 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1524 September 2019, . 1526 Appendix A. Data Tree Example 1528 This section contains an example of an instance data tree in JSON 1529 encoding [RFC7951], containing configuration data. 1531 The configuration example: 1533 { 1534 "ietf-multicast-model:multicast-model":{ 1535 "multicast-keys":[ 1536 { 1537 "vpn-rd":"0:65532:4294967292", 1538 "source-address":"*", 1539 "group-address":"234.232.203.84", 1540 "vni-type":"nvgre", 1541 "vni-value":0, 1542 "multicast-overlay":{ 1543 "ingress-egress":{ 1544 "ingress-node":"146.150.100.0", 1545 "egress-nodes":[ 1546 { 1547 "egress-node":"110.141.168.0" 1548 } 1549 ] 1550 }, 1551 }, 1552 "multicast-transport":{ 1553 "bier":{ 1554 "sub-domain":0, 1555 "bitstringlength":256, 1556 "set-identifier":0 1557 } 1558 }, 1559 "multicast-underlay":{ 1560 "ospf":{ 1561 "topology":"2" 1562 } 1563 } 1564 } 1565 ] 1566 } 1567 } 1569 Authors' Addresses 1571 Zheng Zhang 1572 ZTE Corporation 1573 China 1575 Email: zzhang_ietf@hotmail.com 1576 Cui(Linda) Wang 1577 Individual 1578 Australia 1580 Email: lindawangjoy@gmail.com 1582 Ying Cheng 1583 China Unicom 1584 Beijing 1585 China 1587 Email: chengying10@chinaunicom.cn 1589 Xufeng Liu 1590 Volta Networks 1592 Email: xufeng.liu.ietf@gmail.com 1594 Mahesh Sivakumar 1595 Juniper networks 1596 1133 Innovation Way 1597 Sunnyvale, CALIFORNIA 94089 1598 USA 1600 Email: sivakumar.mahesh@gmail.com