idnits 2.17.1 draft-ietf-mboned-multicast-yang-model-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 == 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 (October 29, 2020) is 1275 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 (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-08) exists of draft-ietf-bier-bier-yang-07 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-03 == 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-10 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-08 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-07 Summary: 0 errors (**), 0 flaws (~~), 11 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: May 2, 2021 Individual 6 Y. Cheng 7 China Unicom 8 X. Liu 9 Volta Networks 10 M. Sivakumar 11 Juniper networks 12 October 29, 2020 14 Multicast YANG Data Model 15 draft-ietf-mboned-multicast-yang-model-04 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 May 2, 2021. 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 . . . . . . . . . . . . . 13 72 3.5. Multicast YANG data model Notification . . . . . . . . . 13 73 4. Multicast YANG data Model . . . . . . . . . . . . . . . . . . 13 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 34 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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* 363 [vpn-rd source-address group-address 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-lsp-type)? 417 | | +--:(mldp) 418 | | | +--rw mldp-lsp 419 | | | +--rw root-address? 420 ip-multicast-source-address 421 | | | +--rw lsp-id? uint32 422 | | | +--rw backup-lsp-id? uint32 423 | | +--:(p2mp-te) 424 | | +--rw p2mp-te-lsp 425 | | +--rw root-address? 426 ip-multicast-source-address 427 | | +--rw lsp-id? uint32 428 | | +--rw backup-lsp-id? uint32 429 | +--:(pim) 430 | +--rw pim 431 +--rw multicast-underlay 432 +--rw (underlay)? 433 +--:(bgp) 434 +--:(ospf) 435 | +--rw ospf 436 | +--rw topology? 437 -> /rt:routing/control-plane-protocols 438 /control-plane-protocol/ospf:ospf 439 /topologies/topology/name 440 +--:(isis) 441 +--:(babel) 443 notifications: 444 +---n head-end-event 445 +--ro event-type? enumeration 446 +--ro multicast-key 447 | +--ro vpn-rd? rt-types:route-distinguisher 448 | +--ro source-address? ip-multicast-source-address 449 | +--ro group-address? rt-types:ip-multicast-group-address 450 | +--ro vni-type? virtual-type 451 | +--ro vni-value? uint32 452 +--ro (overlay-tech-type)? 453 | +--:(bgp) 454 | +--:(evpn) 455 | +--:(mld) 456 | | +--ro mld-instance-group? 457 rt-types:ip-multicast-group-address 458 | +--:(mld-snooping) 459 | +--:(mvpn) 460 | +--:(pim) 461 +--ro transport-tech 462 | +--ro (transport)? 463 | +--:(bier) 464 | | +--ro bier 465 | | +--ro sub-domain? uint16 466 | | +--ro bitstringlength? uint16 467 | | +--ro set-identifier? uint16 468 | | +--ro (encap-type)? 469 | | +--:(mpls) 470 | | +--:(eth) 471 | | +--:(ipv6) 472 | +--:(bier-te) 473 | | +--ro bier-te 474 | | +--ro sub-domain? uint16 475 | | +--ro bitstringlength? uint16 476 | | +--ro set-identifier? uint16 477 | | +--ro (encap-type)? 478 | | | +--:(mpls) 479 | | | +--:(eth) 480 | | | +--:(ipv6) 481 | | +--ro bier-te-adj* uint16 482 | +--:(cisco-mode) 483 | | +--ro cisco-mode 484 | | +--ro p-group? 485 rt-types:ip-multicast-group-address 486 | +--:(mpls) 487 | | +--ro mpls 488 | | +--ro (mpls-lsp-type)? 489 | | +--:(mldp) 490 | | | +--ro mldp-lsp 491 | | | +--ro root-address? 492 ip-multicast-source-address 493 | | | +--ro lsp-id? uint32 494 | | | +--ro backup-lsp-id? uint32 495 | | +--:(p2mp-te) 496 | | +--ro p2mp-te-lsp 497 | | +--ro root-address? 498 ip-multicast-source-address 499 | | +--ro lsp-id? uint32 500 | | +--ro backup-lsp-id? uint32 501 | +--:(pim) 502 | +--ro pim 503 +--ro underlay-tech 504 +--ro (underlay)? 505 +--:(bgp) 506 +--:(ospf) 507 | +--ro ospf 508 | +--ro topology? 509 -> /rt:routing/control-plane-protocols 510 /control-plane-protocol/ospf:ospf 511 /topologies/topology/name 512 +--:(isis) 513 +--:(babel) 515 3.3. Multicast YANG data model Configuration 517 This model is used with other protocol data model to provide 518 multicast service. 520 This model includes multicast service keys and three layers: the 521 multicast overlay, the transport layer and the multicast underlay 522 information. Multicast keys include the features of multicast flow, 523 such as(vpnid, multicast source and multicast group) information. In 524 data center network, for fine-grained to gather the nodes belonging 525 to the same virtual network, there may need VNI-related information 526 to assist. 528 Multicast overlay defines (ingress-node, egress-nodes) nodes 529 information. If the transport layer is BIER, there may define BIER 530 information including (Subdomain, ingress-node BFR-id, egress-nodes 531 BFR-id). If no (ingress-node, egress-nodes) information are defined 532 directly, there may need overlay multicast signaling technology, such 533 as MLD or MVPN, to collect these nodes information. 535 Multicast transport layer defines the type of transport technologies 536 that can be used to forward multicast flow, including BIER forwarding 537 type, MPLS forwarding type, or PIM forwarding type and so on. One or 538 several transport technologies could be defined at the same time. As 539 for the detailed parameters for each transport technology, this 540 multicast YANG data model can invoke the corresponding protocol model 541 to define them. 543 Multicast underlay defines the type of underlay technologies, such as 544 OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay 545 technologies could be defined at the same time if there is protective 546 requirement. As for the specific parameters for each underlay 547 technology, this multicast YANG data model can depend the 548 corresponding protocol model to configure them as well. 550 The configuration modeling branch is composed of the keys, overlay 551 layer, transport layer and underlay layer. 553 3.4. Multicast YANG data model State 555 Multicast model states are the same with the configuration. 557 3.5. Multicast YANG data model Notification 559 The defined Notifications include the events of head end nodes. Like 560 head node failer, overlay/ transport/ underlay module loading/ 561 unloading. And the potential failer about some multicast flows and 562 associated overlay/ transport/ underlay technologies. 564 4. Multicast YANG data Model 566 This module references [RFC1195], [RFC2328], [RFC4271], [RFC4541], 567 [RFC4875], [RFC5340], [RFC6037], [RFC6388], [RFC6513], [RFC6991], 568 [RFC7348], [RFC7432], [RFC7637], [RFC7716], [RFC7761], [RFC8279], 569 [RFC8294], [RFC8296], [RFC8343], [RFC8344], [RFC8349], [RFC8639], 570 [RFC8641], [I-D.ietf-pim-yang], [I-D.ietf-bier-bier-yang], 571 [I-D.ietf-bier-te-arch], [I-D.ietf-nvo3-geneve], [I-D.ietf-bier-mld], 572 [I-D.ietf-bess-evpn-bum-procedure-updates], [I-D.ietf-bier-evpn], 573 [I-D.zhang-bier-bierin6], [I-D.ietf-babel-rfc6126bis], 574 [I-D.ietf-bier-pim-signaling]. 576 file "ietf-multicast-model@2020-10-28.yang" 577 module ietf-multicast-model { 579 yang-version 1.1; 581 namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model"; 582 prefix multicast-model; 584 import ietf-inet-types { 585 prefix "inet"; 586 reference 587 "RFC 6991: Common YANG Data Types"; 588 } 589 import ietf-routing-types { 590 prefix "rt-types"; 591 reference 592 "RFC 8294: Common YANG Data Types for the Routing Area"; 593 } 594 import ietf-routing { 595 prefix "rt"; 596 reference 597 "RFC 8349: A YANG Data Model for Routing Management 598 (NMDA Version)"; 599 } 600 import ietf-ospf { 601 prefix "ospf"; 602 reference 603 "I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol"; 604 } 606 organization " IETF MBONED (MBONE Deployment) Working Group"; 607 contact 608 "WG List: 610 Editor: Zheng Zhang 611 612 Editor: Cui Wang 613 614 Editor: Ying Cheng 615 616 Editor: Xufeng Liu 617 618 Editor: Mahesh Sivakumar 619 620 "; 622 // RFC Ed.: replace XXXX with actual RFC number and remove 623 // this note 625 description 626 "The module defines the YANG definitions for multicast service 627 management. 629 Copyright (c) 2020 IETF Trust and the persons identified as 630 authors of the code. All rights reserved. 632 Redistribution and use in source and binary forms, with or 633 without modification, is permitted pursuant to, and subject 634 to the license terms contained in, the Simplified BSD 635 License set forth in Section 4.c of the IETF Trust's Legal 636 Provisions Relating to IETF Documents 637 (https://trustee.ietf.org/license-info). 639 This version of this YANG module is part of RFC XXXX 640 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 641 itself for full legal notices. 643 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 644 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 645 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 646 are to be interpreted as described in BCP 14 (RFC 2119) 647 (RFC 8174) when, and only when, they appear in all 648 capitals, as shown here."; 650 revision 2020-09-30 { 651 description 652 "Initial revision."; 653 reference 654 "RFC XXXX: A YANG Data Model for multicast YANG."; 655 } 657 /* 658 *typedef 659 */ 661 typedef ip-multicast-source-address { 662 type union { 663 type rt-types:ipv4-multicast-source-address; 664 type rt-types:ipv6-multicast-source-address; 665 } 666 description 667 "This type represents a version-neutral IP multicast 668 source address. The format of the textual 669 representation implies the IP version."; 670 reference 671 "RFC8294: Common YANG Data Types for the Routing Area."; 672 } 674 typedef virtual-type { 675 type enumeration { 676 enum vxlan { 677 description 678 "The VXLAN encapsulation is used for flow encapsulation."; 679 reference 680 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 681 A Framework for Overlaying Virtualized Layer 2 Networks 682 over Layer 3 Networks."; 683 } 684 enum nvgre { 685 description 686 "The NVGRE encapsulation is used for flow encapsulation."; 687 reference 688 "RFC 7637: NVGRE: Network Virtualization Using Generic 689 Routing Encapsulation."; 690 } 691 enum geneve { 692 description 693 "The GENEVE encapsulation is used for flow encapsulation."; 695 reference 696 "I-D.ietf-nvo3-geneve: Geneve: Generic Network 697 Virtualization Encapsulation."; 698 } 699 } 700 description 701 "The encapsulation type used for the flow. In case the virtual 702 type is set, the associated vni-value should also be defined."; 703 } // virtual-type 705 /* 706 * Identities 707 */ 709 identity multicast-model { 710 base rt:control-plane-protocol; 711 description "Identity for the Multicast model."; 712 } 714 grouping general-multicast-key { 715 description 716 "The general multicast keys. They are used to distinguish 717 different multicast service."; 718 leaf vpn-rd { 719 type rt-types:route-distinguisher; 720 description 721 "A Route Distinguisher used to distinguish 722 routes from different MVPNs."; 723 reference 724 "RFC 8294: Common YANG Data Types for the Routing Area. 725 RFC 6513: Multicast in MPLS/BGP IP VPNs."; 726 } 727 leaf source-address { 728 type ip-multicast-source-address; 729 description 730 "The IPv4/IPv6 source address of the multicast flow. The 731 value set to zero means that the receiver interests 732 in all source that relevant to one given group."; 733 } 734 leaf group-address { 735 type rt-types:ip-multicast-group-address; 736 description 737 "The IPv4/IPv6 group address of multicast flow. This 738 type represents a version-neutral IP multicast group 739 address. The format of the textual representation 740 implies the IP version."; 741 reference 742 "RFC8294: Common YANG Data Types for the Routing Area."; 744 } 745 leaf vni-type { 746 type virtual-type; 747 description 748 "The type of virtual network identifier. Includes the 749 Vxlan, NVGRE and Geneve. This value and vni-value is 750 used to indicate a specific virtual multicast service."; 751 } 752 leaf vni-value { 753 type uint32; 754 description 755 "The value of Vxlan network identifier, virtual subnet ID 756 or virtual net identifier. This value and vni-type is used 757 to indicate a specific virtual multicast service."; 758 } 759 } // general-multicast-key 761 grouping encap-type { 762 description 763 "The encapsulation type used for flow forwarding."; 764 choice encap-type { 765 case mpls { 766 description "The BIER forwarding depends on mpls."; 767 reference 768 "RFC 8296: Encapsulation for Bit Index Explicit 769 Replication (BIER) in MPLS and Non-MPLS Networks."; 770 } 771 case eth { 772 description "The BIER forwarding depends on ethernet."; 773 reference 774 "RFC 8296: Encapsulation for Bit Index Explicit 775 Replication (BIER) in MPLS and Non-MPLS Networks."; 776 } 777 case ipv6 { 778 description "The BIER forwarding depends on IPv6."; 779 reference 780 "I-D.zhang-bier-bierin6: BIER in IPv6 (BIERin6)"; 781 } 782 description "The encapsulation type in BIER."; 783 } 784 } // encap-type 786 grouping bier-key { 787 description 788 "The key parameters set for BIER/BIER TE forwarding."; 789 reference 790 "RFC 8279: Multicast Using Bit Index Explicit Replication 791 (BIER)."; 793 leaf sub-domain { 794 type uint16; 795 description 796 "The subdomain id that the multicast flow belongs to."; 797 } 798 leaf bitstringlength { 799 type uint16; 800 description 801 "The bitstringlength used by BIER forwarding."; 802 } 803 leaf set-identifier { 804 type uint16; 805 description 806 "The set identifier used by the multicast flow."; 807 } 808 uses encap-type; 809 } 811 grouping lsp { 812 description "The lsp information."; 813 leaf root-address { 814 type ip-multicast-source-address; 815 description 816 "Root address of the mldp fec."; 817 } 818 leaf lsp-id { 819 type uint32; 820 description 821 "The lsp id that corresponding this flow."; 822 } 823 leaf backup-lsp-id { 824 type uint32; 825 description 826 "The backup lsp id that corresponding this flow. 827 In case the lsp fails, the backup lsp can be used."; 828 } 829 } // lsp 831 grouping transport-tech { 832 choice transport { 833 description "The selected transport technology."; 834 container bier { 835 description 836 "The transport technology is BIER. The BIER technology 837 is introduced in RFC8279. The parameter is consistent 838 with the definition in BIER YANG data model."; 839 reference 840 "RFC 8279: Multicast Using Bit Index Explicit 841 Replication (BIER). 842 I-D.ietf-bier-bier-yang: YANG Data Model for BIER 843 Protocol."; 845 uses bier-key; 846 } 848 container bier-te { 849 description 850 "The transport technology is BIER-TE."; 851 reference 852 "I-D.ietf-bier-te-arch: Traffic Engineering for Bit Index 853 Explicit Replication (BIER-TE)"; 855 uses bier-key; 857 leaf-list bier-te-adj { 858 type uint16; 859 description 860 "The adjacencies ID used in BIER TE forwarding 861 encapsulation."; 862 } 863 } 865 container cisco-mode { 866 description 867 "The transport technology is cisco-mode: Cisco MDT."; 868 reference 869 "RFC 6037: Cisco Systems' Solution for Multicast in 870 BGP/MPLS IP VPNs"; 872 leaf p-group { 873 type rt-types:ip-multicast-group-address; 874 description 875 "The address of p-group. It is used to encapsulate 876 and forward flow according to multicast tree from 877 ingress node to egress nodes."; 878 } 879 uses transport-pim; 880 } 882 container mpls { 883 description 884 "The transport technology is mpls. Multicast overlay can use 885 mpls technologies to build transport layer."; 886 reference 887 "RFC 6513: Multicast in MPLS/BGP IP VPNs."; 889 choice mpls-lsp-type { 890 case mldp { 891 description 892 "The mldp type of lsp is used as multicast 893 transportation. 894 The YANG data model defined in 'ietf-mpls-mldp-yang' 895 can be invoked."; 896 reference 897 "RFC 6388: Label Distribution Protocol Extensions 898 for Point-to-Multipoint and Multipoint-to-Multipoint 899 Label Switched Paths. 900 I-D.ietf-mpls-mldp-yang: 901 YANG Data Model for MPLS mLDP."; 903 container mldp-lsp { 904 description 905 "The specific parameters can be set to use 906 the specific mldp fec."; 907 uses lsp; 908 } 909 } 910 case p2mp-te { 911 description 912 "The p2mp te type of lsp is used as multicast 913 transportation."; 914 reference 915 "RFC 4875: Extensions to Resource Reservation Protocol 916 - Traffic Engineering (RSVP-TE) for Point-to-Multipoint 917 TE Label Switched Paths (LSPs)."; 919 container p2mp-te-lsp { 920 description 921 "The specific parameters can be set to use 922 the specific mldp fec."; 923 uses lsp; 924 } 925 } 926 description "The collection types of mpls tunnels"; 927 } 928 } // mpls 930 container pim { 931 description 932 "The transport technology is PIM. PIM is used 933 commonly in traditional network."; 934 reference 935 "RFC 7761: Protocol Independent Multicast - Sparse Mode 936 (PIM-SM): Protocol Specification (Revised)."; 938 uses transport-pim; 939 } 940 } // choice 941 } // transport-tech 943 grouping underlay-tech { 944 choice underlay { 945 case bgp { 946 description 947 "The underlay technology is BGP. BGP protocol 948 should run if BGP is used as underlay protocol."; 949 reference 950 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 951 } 952 container ospf { 953 description 954 "The underlay technology is OSPF. OSPF protocol 955 should be triggered to run if OSPF is used as underlay 956 protocol."; 957 reference 958 "RFC 2328: OSPF Version 2. 959 RFC 5340: OSPF for IPv6. 960 I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol."; 962 leaf topology { 963 type leafref { 964 path "/rt:routing/rt:control-plane-protocols/" 965 + "rt:control-plane-protocol/ospf:ospf/" 966 + "ospf:topologies/ospf:topology/ospf:name"; 967 } 968 description 969 "The designed topology name of ospf protocol."; 970 } 971 } 972 case isis { 973 description 974 "The underlay technology is ISIS. ISIS protocol should 975 be triggered to run if ISIS is used as underlay protocol. 976 And the associated extensions can be used."; 977 reference 978 "RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and 979 Dual Environments"; 980 } 981 case babel { 982 description 983 "The underlay technology is Babel. Babel protocol 984 should be triggered to run if Babel is used as 985 underlay protocol."; 987 reference 988 "I-D.ietf-babel-rfc6126bis: The Babel Routing Protocol."; 989 } 990 } // choice 991 } // underlay-tech 993 /*overlay*/ 995 grouping overlay-tech { 996 choice overlay-tech-type { 997 case bgp { 998 description 999 "BGP technology is used for multicast overlay."; 1000 reference 1001 "RFC 7716: Global Table Multicast with BGP Multicast 1002 VPN (BGP-MVPN) Procedures."; 1003 } 1004 case evpn { 1005 description 1006 "EVPN technology is used for multicast overlay."; 1007 reference 1008 "RFC 7432: BGP MPLS-Based Ethernet VPN. 1009 I-D.ietf-bess-evpn-bum-procedure-updates: Updates on 1010 EVPN BUM Procedures. 1011 I-D.ietf-bier-evpn: EVPN BUM Using BIER."; 1012 } 1013 case mld { 1014 description 1015 "MLD technology is used for multicast overlay."; 1016 reference 1017 "I-D.ietf-bier-mld: BIER Ingress Multicast Flow Overlay 1018 using Multicast Listener Discovery Protocols."; 1019 leaf mld-instance-group { 1020 type rt-types:ip-multicast-group-address; 1021 description 1022 "The multicast address used for multiple MLD instance 1023 support."; 1024 } 1025 } 1026 case mld-snooping { 1027 description 1028 "MLD snooping technology is used for multicast overlay."; 1029 reference 1030 "RFC 4541: Considerations for Internet Group Management 1031 Protocol (IGMP) and Multicast Listener 1032 Discovery (MLD) Snooping Switches."; 1033 } 1034 case mvpn { 1035 description 1036 "MVPN technology is used for multicast overlay."; 1037 reference 1038 "RFC 6513: Multicast in MPLS/BGP IP VPNs."; 1039 } 1040 case pim { 1041 description 1042 "PIM technology is used for multicast overlay."; 1043 reference 1044 "I-D.ietf-bier-pim-signaling: PIM Signaling 1045 Through BIER Core."; 1046 } 1047 description 1048 "The overlay technology used for multicast service."; 1049 } 1050 description "The overlay technology used for multicast service."; 1051 } // overlay-tech 1053 /*transport*/ 1055 grouping transport-pim { 1056 description 1057 "The requirement information of pim transportion."; 1058 reference 1059 "RFC 7761: Protocol Independent Multicast - Sparse Mode 1060 (PIM-SM): Protocol Specification (Revised)."; 1061 } //transport-pim 1063 /*underlay*/ 1065 container multicast-model { 1066 description 1067 "The model of multicast YANG data. Include keys, overlay, 1068 transport and underlay."; 1070 list multicast-keys{ 1071 key "vpn-rd source-address group-address vni-type vni-value"; 1072 uses general-multicast-key; 1074 container multicast-overlay { 1075 description 1076 "The overlay information of multicast service. 1077 Overlay technology is used to exchange multicast 1078 flows information. Overlay technology may not be 1079 used in SDN controlled completely situation, but 1080 it can be used in partial SDN controlled situation 1081 or non-SDN controlled situation. Different overlay 1082 technologies can be choosed according to different 1083 deploy consideration."; 1085 container ingress-egress { 1086 description 1087 "The ingress and egress nodes address collection. 1088 The ingress node may use the egress nodes set 1089 directly to encapsulate the multicast flow by 1090 transport technology."; 1092 leaf ingress-node { 1093 type inet:ip-address; 1094 description 1095 "The ip address of ingress node for one or more 1096 multicast flow. Or the ingress node of MVPN and 1097 BIER. In MVPN, this is the address of ingress 1098 PE; in BIER, this is the BFR-prefix of ingress 1099 nodes."; 1100 } 1101 list egress-nodes { 1102 key "egress-node"; 1103 description 1104 "The egress multicast nodes of the multicast flow. 1105 Or the egress node of MVPN and BIER. In MVPN, this 1106 is the address of egress PE; in BIER, this is the 1107 BFR-prefix of ingress nodes."; 1109 leaf egress-node { 1110 type inet:ip-address; 1111 description 1112 "The ip-address set of egress multicast nodes."; 1113 } 1114 } 1115 } 1117 container bier-ids { 1118 description 1119 "The BFR-ids of ingress and egress BIER nodes for 1120 one or more multicast flows. This overlay is used 1121 with BIER transport technology. The egress nodes 1122 set can be used to encapsulate the multicast flow 1123 directly in the ingress node."; 1124 reference 1125 "RFC 8279: Multicast Using Bit Index Explicit 1126 Replication (BIER)"; 1128 leaf sub-domain { 1129 type uint16; 1130 description 1131 "The sub-domain that this multicast flow belongs to."; 1132 } 1133 leaf ingress-node { 1134 type uint16; 1135 description 1136 "The ingress node of multicast flow. This is the 1137 BFR-id of ingress nodes."; 1138 } 1139 list egress-nodes { 1140 key "egress-node"; 1141 description 1142 "The egress nodes of multicast flow."; 1144 leaf egress-node { 1145 type uint16; 1146 description 1147 "The BFR-ids of egress multicast BIER nodes."; 1148 } 1149 } 1150 } 1151 uses overlay-tech; 1152 } 1154 container multicast-transport { 1155 description 1156 "The transportion of multicast service. Transport 1157 protocol is responsible for delivering multicast 1158 flows from ingress nodes to egress nodes with or 1159 without specific encapsulation. Different transport 1160 technology can be choosed according to different 1161 deploy consideration. Once a transport technology 1162 is choosed, associated protocol should be triggered 1163 to run."; 1165 uses transport-tech; 1166 } 1167 container multicast-underlay { 1168 description 1169 "The underlay of multicast service. Underlay protocol 1170 is used to build transport layer. Underlay protocol 1171 need not be assigned in ordinary network since 1172 existed underlay protocol fits well, but it can be 1173 assigned in particular networks for better 1174 controll. Once a underlay technology is choosed, 1175 associated protocol should be triggered to run."; 1177 uses underlay-tech; 1178 } 1179 description 1180 "The model of multicast YANG data. Include keys, 1181 overlay, transport and underlay."; 1182 } 1183 } 1185 /*Notifications*/ 1187 notification head-end-event { 1188 leaf event-type { 1189 type enumeration { 1190 enum down { 1191 description 1192 "There is something wrong with head end node, 1193 and head end node can't work properlay."; 1194 } 1195 enum module-loaded { 1196 description 1197 "The new modules that can be used by multicast 1198 flows have been loaded."; 1199 } 1200 enum module-unloaded { 1201 description 1202 "The new modules that can be used by multicast 1203 flows have been unloaded."; 1204 } 1205 } 1206 description "Event type."; 1207 } 1208 container multicast-key { 1209 uses general-multicast-key; 1210 description 1211 "The associated multicast keys that are influenced by 1212 head end node failer."; 1213 } 1214 uses overlay-tech; 1216 container transport-tech { 1217 description 1218 "The modules can be used to forward multicast flows."; 1219 uses transport-tech; 1220 } 1222 container underlay-tech { 1223 description 1224 "There is something wrong with the module which is 1225 used to build multicast transport layer."; 1226 uses underlay-tech; 1228 } 1229 description 1230 "Notification events for the head end nodes. Like head 1231 node failer, overlay/ transport/ underlay module 1232 loading/ unloading. And the potential failer about some 1233 multicast flows and associated 1234 overlay/ transport/ underlay technologies."; 1235 } 1236 } 1237 1239 5. Security Considerations 1241 The YANG module specified in this document defines a schema for data 1242 that is designed to be accessed via network management protocols such 1243 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1244 is the secure transport layer, and the mandatory-to-implement secure 1245 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1246 is HTTPS, and the mandatory-to-implement secure transport is TLS 1247 [RFC8446]. 1249 The NETCONF access control model [RFC8341] provides the means to 1250 restrict access for particular NETCONF or RESTCONF users to a 1251 preconfigured subset of all available NETCONF or RESTCONF protocol 1252 operations and content. 1254 There are a number of data nodes defined in this YANG module that are 1255 writable/creatable/deletable (i.e., config true, which is the 1256 default). These data nodes may be considered sensitive or vulnerable 1257 in some network environments. Write operations (e.g., edit-config) 1258 to these data nodes without proper protection can have a negative 1259 effect on network operations. These are data nodes and their 1260 sensitivity/vulnerability: 1262 Under /rt:routing/rt:control-plane-protocols/multicast-model, 1264 multicast-model 1266 These data nodes in this model specifies the configuration for the 1267 multicast service at the top level. Modifying the configuration 1268 can cause multicast service to be deleted or reconstructed. 1270 Some of the readable data nodes in this YANG module may be considered 1271 sensitive or vulnerable in some network environments. It is thus 1272 important to control read access (e.g., via get, get-config, or 1273 notification) to these data nodes. These are the data nodes and 1274 their sensitivity/vulnerability: 1276 /rt:routing/rt:control-plane-protocols/multicast-model, 1278 Unauthorized access to any data node of the above tree can disclose 1279 the operational state information of multicast service on this 1280 device. 1282 6. IANA Considerations 1284 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1285 number (and remove this note). 1287 The IANA is requested to assign one new URI from the IETF XML 1288 registry [RFC3688]. Authors are suggesting the following URI: 1290 URI: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1292 Registrant Contact: The IESG 1294 XML: N/A, the requested URI is an XML namespace 1296 This document also requests one new YANG module name in the YANG 1297 Module Names registry [RFC6020] with the following suggestion: 1299 name: ietf-multicast-model 1301 namespace: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1303 prefix: multicast-model 1305 reference: RFC XXXX 1307 7. Acknowledgements 1309 The authors would like to thank Stig Venaas, Jake Holland, Min Gu for 1310 their valuable comments and suggestions. 1312 8. References 1314 8.1. Normative References 1316 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1317 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1318 December 1990, . 1320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1321 Requirement Levels", BCP 14, RFC 2119, 1322 DOI 10.17487/RFC2119, March 1997, 1323 . 1325 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1326 DOI 10.17487/RFC2328, April 1998, 1327 . 1329 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1330 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1331 DOI 10.17487/RFC4271, January 2006, 1332 . 1334 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1335 Yasukawa, Ed., "Extensions to Resource Reservation 1336 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1337 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1338 DOI 10.17487/RFC4875, May 2007, 1339 . 1341 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1342 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1343 . 1345 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1346 the Network Configuration Protocol (NETCONF)", RFC 6020, 1347 DOI 10.17487/RFC6020, October 2010, 1348 . 1350 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1351 and A. Bierman, Ed., "Network Configuration Protocol 1352 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1353 . 1355 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1356 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1357 . 1359 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1360 Thomas, "Label Distribution Protocol Extensions for Point- 1361 to-Multipoint and Multipoint-to-Multipoint Label Switched 1362 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1363 . 1365 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1366 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1367 2012, . 1369 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1370 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1371 . 1373 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1374 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1375 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1376 2015, . 1378 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 1379 and D. Pacella, "Global Table Multicast with BGP Multicast 1380 VPN (BGP-MVPN) Procedures", RFC 7716, 1381 DOI 10.17487/RFC7716, December 2015, 1382 . 1384 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1385 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1386 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1387 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1388 2016, . 1390 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1391 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1392 . 1394 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1395 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1396 . 1398 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1399 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1400 . 1402 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1403 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1404 May 2017, . 1406 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1407 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1408 Explicit Replication (BIER)", RFC 8279, 1409 DOI 10.17487/RFC8279, November 2017, 1410 . 1412 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1413 "Common YANG Data Types for the Routing Area", RFC 8294, 1414 DOI 10.17487/RFC8294, December 2017, 1415 . 1417 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1418 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1419 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1420 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1421 2018, . 1423 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1424 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1425 . 1427 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1428 Access Control Model", STD 91, RFC 8341, 1429 DOI 10.17487/RFC8341, March 2018, 1430 . 1432 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1433 and R. Wilton, "Network Management Datastore Architecture 1434 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1435 . 1437 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1438 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1439 . 1441 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1442 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1443 . 1445 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1446 Routing Management (NMDA Version)", RFC 8349, 1447 DOI 10.17487/RFC8349, March 2018, 1448 . 1450 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1451 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1452 . 1454 8.2. Informative References 1456 [I-D.ietf-babel-rfc6126bis] 1457 Chroboczek, J. and D. Schinazi, "The Babel Routing 1458 Protocol", draft-ietf-babel-rfc6126bis-20 (work in 1459 progress), August 2020. 1461 [I-D.ietf-bess-evpn-bum-procedure-updates] 1462 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 1463 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 1464 bess-evpn-bum-procedure-updates-08 (work in progress), 1465 November 2019. 1467 [I-D.ietf-bier-bier-yang] 1468 Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d., 1469 and M. Sivakumar, "YANG Data Model for BIER Protocol", 1470 draft-ietf-bier-bier-yang-07 (work in progress), September 1471 2020. 1473 [I-D.ietf-bier-evpn] 1474 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 1475 "EVPN BUM Using BIER", draft-ietf-bier-evpn-03 (work in 1476 progress), April 2020. 1478 [I-D.ietf-bier-mld] 1479 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 1480 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 1481 using Multicast Listener Discovery Protocols", draft-ietf- 1482 bier-mld-04 (work in progress), March 2020. 1484 [I-D.ietf-bier-pim-signaling] 1485 Bidgoli, H., Xu, F., Kotalwar, J., Wijnands, I., Mishra, 1486 M., and Z. Zhang, "PIM Signaling Through BIER Core", 1487 draft-ietf-bier-pim-signaling-10 (work in progress), July 1488 2020. 1490 [I-D.ietf-bier-te-arch] 1491 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 1492 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 1493 bier-te-arch-08 (work in progress), July 2020. 1495 [I-D.ietf-nvo3-geneve] 1496 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 1497 Network Virtualization Encapsulation", draft-ietf- 1498 nvo3-geneve-16 (work in progress), March 2020. 1500 [I-D.ietf-ospf-yang] 1501 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 1502 "YANG Data Model for OSPF Protocol", draft-ietf-ospf- 1503 yang-29 (work in progress), October 2019. 1505 [I-D.ietf-pim-yang] 1506 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1507 Y., and f. hu, "A YANG Data Model for Protocol Independent 1508 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1509 progress), May 2018. 1511 [I-D.zhang-bier-bierin6] 1512 Zhang, Z., Zhang, Z., Wijnands, I., Bidgoli, H., and M. 1513 McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 1514 bierin6-07 (work in progress), July 2020. 1516 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1517 DOI 10.17487/RFC3688, January 2004, 1518 . 1520 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1521 "Considerations for Internet Group Management Protocol 1522 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1523 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 1524 . 1526 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 1527 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 1528 RFC 6037, DOI 10.17487/RFC6037, October 2010, 1529 . 1531 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1532 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1533 eXtensible Local Area Network (VXLAN): A Framework for 1534 Overlaying Virtualized Layer 2 Networks over Layer 3 1535 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1536 . 1538 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1539 Virtualization Using Generic Routing Encapsulation", 1540 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1541 . 1543 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1544 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1545 DOI 10.17487/RFC8407, October 2018, 1546 . 1548 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1549 E., and A. Tripathy, "Subscription to YANG Notifications", 1550 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1551 . 1553 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1554 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1555 September 2019, . 1557 Appendix A. Data Tree Example 1559 This section contains an example of an instance data tree in JSON 1560 encoding [RFC7951], containing configuration data. 1562 The configuration example: 1564 { 1565 "ietf-multicast-model:multicast-model":{ 1566 "multicast-keys":[ 1567 { 1568 "vpn-rd":"0:65532:4294967292", 1569 "source-address":"*", 1570 "group-address":"234.232.203.84", 1571 "vni-type":"nvgre", 1572 "vni-value":0, 1573 "multicast-overlay":{ 1574 "ingress-egress":{ 1575 "ingress-node":"146.150.100.0", 1576 "egress-nodes":[ 1577 { 1578 "egress-node":"110.141.168.0" 1579 } 1580 ] 1581 }, 1582 }, 1583 "multicast-transport":{ 1584 "bier":{ 1585 "sub-domain":0, 1586 "bitstringlength":256, 1587 "set-identifier":0 1588 } 1589 }, 1590 "multicast-underlay":{ 1591 "ospf":{ 1592 "topology":"2" 1593 } 1594 } 1595 } 1596 ] 1597 } 1598 } 1600 Authors' Addresses 1602 Zheng Zhang 1603 ZTE Corporation 1604 China 1606 Email: zhang.zheng@zte.com.cn 1608 Cui(Linda) Wang 1609 Individual 1610 Australia 1612 Email: lindawangjoy@gmail.com 1614 Ying Cheng 1615 China Unicom 1616 Beijing 1617 China 1619 Email: chengying10@chinaunicom.cn 1621 Xufeng Liu 1622 Volta Networks 1624 Email: xufeng.liu.ietf@gmail.com 1626 Mahesh Sivakumar 1627 Juniper networks 1628 1133 Innovation Way 1629 Sunnyvale, CALIFORNIA 94089 1630 USA 1632 Email: sivakumar.mahesh@gmail.com