idnits 2.17.1 draft-ietf-mboned-multicast-yang-model-06.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 437 has weird spacing: '...ss-node ine...' == Line 439 has weird spacing: '...ss-node ine...' == Line 443 has weird spacing: '...ss-node uin...' == Line 445 has weird spacing: '...ss-node uin...' == Line 472 has weird spacing: '... adj-id uin...' == (6 more instances...) -- The document date (28 February 2022) is 780 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 (-08) exists of draft-ietf-bier-bier-yang-07 == Outdated reference: A later version (-09) exists of draft-ietf-bier-bierin6-03 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-05 == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-06 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-10 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-03 == Outdated reference: A later version (-21) exists of draft-ietf-rift-rift-15 Summary: 0 errors (**), 0 flaws (~~), 14 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: 1 September 2022 Individual 6 Y. Cheng 7 China Unicom 8 X. Liu 9 Volta Networks 10 M. Sivakumar 11 Juniper networks 12 28 February 2022 14 Multicast YANG Data Model 15 draft-ietf-mboned-multicast-yang-model-06 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 1 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 60 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 61 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 62 1.5. Usage of Multicast Model . . . . . . . . . . . . . . . . 5 63 1.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7 64 2. Design of the multicast model . . . . . . . . . . . . . . . . 8 65 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 8 66 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 8 67 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1. UML like Class Diagram for Multicast YANG data Model . . 8 69 3.2. Model Structure . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 14 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 34 79 8.2. Informative References . . . . . . . . . . . . . . . . . 37 80 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 40 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 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 document does not define any specific protocol model, instead, 97 it depends on many existing multicast protocol models and relates 98 several multicast information together to fulfill multicast service. 100 This model can be used along with other multicast YANG models such as 101 PIM [I-D.ietf-pim-yang], which are not covered in this document. 103 1.1. Terminology 105 The terminology for describing YANG data models is found in [RFC6020] 106 and [RFC7950], including: 108 * augment 110 * data model 112 * data node 114 * identity 116 * module 118 The following abbreviations are used in this document and the defined 119 model: 121 BABEL: [RFC8966]. 123 BGP: Border Gateway Protocol [RFC4271]. 125 BIER: Bit Index Explicit Replication [RFC8279]. 127 BIER-TE: Traffic Engineering for Bit Index Explicit Replication 128 [I-D.ietf-bier-te-arch]. 130 ISIS: Intermediate System to Intermediate System Routeing Exchange 131 Protocol [RFC1195]. 133 MLD: Multicast Listener Discovery [I-D.ietf-bier-mld]. 135 MLDP: Label Distribution Protocol Extensions for Point-to-Multipoint 136 and Multipoint-to-Multipoint Label Switched Paths [RFC6388]. 138 MVPN: Multicast in MPLS/BGP IP VPNs [RFC6513]. 140 OSPF: Open Shortest Path First [RFC2328]. 142 P2MP-TE: Point-to-Multipoint Traffic Engineering [RFC4875]. 144 PIM: Protocol Independent Multicast [RFC7761]. 146 SR-P2MP: Segment Routing Point-to-Multipoint 147 [I-D.ietf-pim-sr-p2mp-policy]. 149 1.2. Conventions Used in This Document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 1.3. Tree Diagrams 159 Tree diagrams used in this document follow the notation defined in 160 [RFC8340]. 162 1.4. Prefixes in Data Node Names 164 In this document, names of data nodes, actions, and other data model 165 objects are often used without a prefix, as long as it is clear from 166 the context in which YANG module each name is defined. Otherwise, 167 names are prefixed using the standard prefix associated with the 168 corresponding YANG module, as shown in Table 1. 170 +==========+====================+===============================+ 171 | Prefix | YANG module | Reference | 172 +==========+====================+===============================+ 173 | inet | ietf-inet-types | [RFC6991] | 174 +----------+--------------------+-------------------------------+ 175 | isis | ietf-isis | [I-D.ietf-isis-yang-isis-cfg] | 176 +----------+--------------------+-------------------------------+ 177 | ospf | ietf-ospf | [I-D.ietf-ospf-yang] | 178 +----------+--------------------+-------------------------------+ 179 | rt-types | ietf-routing-types | [RFC8294] | 180 +----------+--------------------+-------------------------------+ 181 | rt | ietf-routing | [RFC8349] | 182 +----------+--------------------+-------------------------------+ 183 | yang | ietf-yang-types | [RFC6991] | 184 +----------+--------------------+-------------------------------+ 186 Table 1 188 1.5. Usage of Multicast Model 190 This multicast YANG data model is mainly used by the management tools 191 run by the network operators, in order to manage, monitor and debug 192 the network resources that are used to deliver multicast service. 193 This model is used for gathering data from the network as well. 195 +------------------------+ 196 | Multicast Model | 197 +------------------------+ 198 | | | 199 | | | 200 | +---------+ +----------+ 201 | | EMS/NMS | |Controller| 202 | +---------+ +----------+ 203 | | | 204 | | | 205 +------------------------------------------------+ 206 | Network Element1.....N | 207 +------------------------------------------------+ 209 Figure 1: Usage of Multicast Model 211 Figure 1 illustrates example use cases for this multicast model. 212 Network operators can use this model in a controller which is 213 responsible to implement specific multicast flows with specific 214 protocols and work with the corresponding protocols' model to 215 configure the network elements through NETCONF/RESTCONF/CLI. Or 216 network operators can use this model to the EMS (Element Management 217 System)/ NMS (Network Management System) to manage or configure the 218 network elements directly. 220 On the other hand, when the network elements detect failure or some 221 other changes, the network devices can send the affected multicast 222 flows and the associated overlay/ transport/ underlay information to 223 the controller. Then the controller/ EMS/NMS can respond immediately 224 due to the failure and distribute new model for the flows to the 225 network nodes quickly. Such as the changing of the failure overlay 226 protocol to another one, as well as transport and underlay protocol. 228 Specifically, in section 3, it provides a human readability of the 229 whole multicast network through UML like class diagram, which frames 230 different multicast components and correlates them in a readable 231 fashion. Then, based on this UML like class diagram, there is 232 instantiated and detailed YANG model in Section 4. 234 The usage of this model is flexible. The multicast-keys indicate the 235 flow characters. The flow can be L3 multicast flow, or L2 flow which 236 is also called BUM (Broadcast, Unknown unicast, Multicast) flow in 237 EVPN ([RFC7432]) deployment. 239 Among the multicast-keys, the group-address of L3 multicast flow and 240 the mac-address of BUM flow are the most important keys. The other 241 keys are optional, and need not be all set. For example, only group- 242 address is set, this is (*,G) analogous. If source-address and 243 group-address are both set, this is (S,G) analogous. In addition to 244 the source-address and group-address, when vpn-rd is also set, this 245 is MVPN use case. If mac-address and vpn-rd are set, this is EVPN 246 use case. In case vni-value is set with associated group-address, 247 etc., this is NVO3 multicast use case. 249 * When the controller manages all the ingress and egress routers for 250 the flow, it sends the model that is set with flow characters, 251 ingress and egress nodes information to the ingress and egress 252 nodes. Then the ingress and egress nodes can work without any 253 other dynamic overlay protocols. 255 * When the controller manages the ingress nodes only for the flow, 256 it sends the model that is set with the flow characters to the 257 ingress nodes. The dynamic overlay protocol can be set or not. 258 If the overlay protocol is set, the nodes use the protocol to 259 signal the flow information with other nodes. If the overlay 260 protocol is not set, the nodes use the local running overlay 261 protocol to signal the flow information. 263 * When the transport protocol is set in the model, the nodes 264 encapsulate the flow according to the transport protocol. When 265 the transport protocol is not set in the model, the nodes use the 266 local configured transport protocol for encapsulation. 268 * When the transport protocol is set in the model, the underlay 269 protocol may be set in the model also. In case the underlay 270 protocol is set, the nodes use the underlay protocol to signal and 271 build the transport/forwarding layer. In case the underlay 272 protocol is not set, the nodes use the local configured underlay 273 protocol to signal and build the transport/forwarding layer. 275 * More than one ingress node for a multicast flow can be set in the 276 model. In this situation, two or more ingress nodes can used for 277 a multicast flow forwarding, the ingress routers can be backup for 278 each other. More information can be found in 279 [I-D.szcl-mboned-redundant-ingress-failover]. 281 1.5.1. Example 283 +------------+ 284 | +---------------------------+ 285 +--------------+ Controller | | 286 | | +-----------+ | 287 | +------------+ | | 288 | | | 289 | +-----------------------------+ | | 290 | | | | | 291 | | +------+---+--+ | 292 | | |Egress router+--+ Receiver| 293 | | +------+------+ | 294 +---+-----+----+ | | 295 Source +-|Ingress router| BIER domain | | 296 +---------+----+ | | 297 | +------+------+ | 298 | |Egress router+--+ Receiver| 299 | +------+----+-+ | 300 | | | | 301 +-----------------------------+ +--------------+ 303 Figure 2: Example 305 The network administrator can use the multicast model and associated 306 models to deploy the multicast service. For example, suppose that 307 the flow for a multicast service is 233.252.0.0/16, the flow should 308 be forwarded by BIER [RFC8279] with MPLS encapsulation [RFC8296]. 309 Corresponding IGP protocol which is used to build BIER transport 310 layer is OSPF [RFC2328]. 312 In this model, the corresponding group-address that is in multicast- 313 keys is set to 233.252.0.0/16, the transport technology is set to 314 BIER. The BIER underlay protocol is set to OSPF. The model is sent 315 to every edge router from the controller. If the BIER transport 316 layer which depends on OSPF has not been built in the network, the 317 multicast YANG model may invoke the BIER YANG model that is defined 318 in [I-D.ietf-bier-bier-yang] generation in the controller. After the 319 BIER transport layer is built, the ingress router encapsulates the 320 multicast flow with BIER header and sends it into the network. 321 Intermediate routers forward the flows to all the egress nodes by 322 BIER forwarding. 324 Another example for this figure is, the controller can act as the 325 BIER overlay only. The routers in the domain build BIER forwarding 326 plane beforehand. The controller sends the multicast group-address 327 and/or the source-address to the edge routers in BIER domain only, 328 without transport and underlay set in the model. Then the ingres 329 router can encapsulate the multicast flow with BIER encapsulation 330 automatically. 332 2. Design of the multicast model 334 2.1. Scope of Model 336 This model can be used to configure and manage Multicast service. 337 The operational state data can be retrieved by this model. The 338 subscription and push mechanism defined in [RFC8639] and [RFC8641] 339 can be implemented by the user to subscribe to notifications on the 340 data nodes in this model. 342 The model contains all the basic configuration parameters to operate 343 the model. Depending on the implementation choices, some systems may 344 not allow some of the advanced parameters to be configurable. The 345 occasionally implemented parameters are modeled as optional features 346 in this model. This model can be extended, and it has been 347 structured in a way that such extensions can be conveniently made. 349 2.2. Specification 351 The configuration data nodes cover configurations. The container 352 "multicast-model" is the top level container in this data model. The 353 presence of this container is expected to enable Multicast service 354 functionality. The notification is used to notify the controller 355 that there is error and the error reason. 357 3. Module Structure 359 This model imports and augments the ietf-routing YANG model defined 360 in [RFC8349]. Both configuration data nodes and state data nodes of 361 [RFC8349] are augmented. 363 The YANG data model defined in this document conforms to the Network 364 Management Datastore Architecture (NMDA) [RFC8342]. The operational 365 state data is combined with the associated configuration data in the 366 same hierarchy [RFC8407]. 368 3.1. UML like Class Diagram for Multicast YANG data Model 370 The following is a UML like diagram for Multicast YANG data Model. 372 +-----------+ 373 +-----+Multi|keys | 374 | +-----------+ 375 | |Group Addr | 376 | +-----------+ 377 | |Source Addr| +--------+-----------------+ 378 | +-----------+ | | | 379 | |VPN Info | | | +------+-------+ 380 | +-----------+ | +-----+------+ | Ing/Eg Nodes | 381 | |VNI Info | | |Overlay Tech| +--------------+ 382 | +-----------+ | +------------+ |Ingress Nodes | 383 | | | EVPN | +--------------+ 384 | | +------------+ |Egress Nodes | 385 | Contain | | MLD | +-------+------+ 386 | +-----------+ | +------------+ | relate 387 | | Multicast +----+ |MLD-Snooping| \|/ 388 +-----+ Overlay | +------------+ +----------------+ 389 | | | | MVPN | | BIER Nodes Info| 390 | +-----------+ +------------+ +----------------+ 391 | | PIM | | BFR-ID | 392 | +------------+ +----------------+ 393 | 394 +--------+--+ +---------------+----------+----------+ 395 | Multicast |Contain | | | | 396 | Model | | +--+---+ +---+----+ +--+---+ 397 +--------+--+ | | BIER | |BIER-TE | | MPLS | 398 | +---------+--+ +------+ +--------+ +------+ 399 | | Multicast | 400 +----+ Transport | invoke +-----+ +----------+ +-------+ 401 | | | | PIM | |Cisco Mode| |SR-P2MP| 402 | +---------+--+ +--+--+ +----+-----+ +---+---+ 403 | | | | | 404 | | | | | 405 | +---------------+----------+-----------+ 406 | 407 | +--------------+---------+---------+ 408 | | | | | 409 | | +--+---+ +--+---+ +--+--+ 410 | +----------+-- | BABEL| | BGP | |ISIS | 411 | | Multicast | +------+ +------+ +-----+ 412 +----+ Underlay | invoke 413 | | +------+ +------+ +-----+ 414 +----------+-- | OSPF | | PIM | |RIFT | 415 | +--+---+ +--+---+ +--+--+ 416 | | | | 417 +--------------+---------+---------+ 419 Figure 3: UML like Class Diagram for Multicast YANG data Model 421 3.2. Model Structure 423 module: ietf-multicast-model 424 +--rw multicast-model 425 +--rw multicast-keys* 426 [vpn-rd source-address group-address mac-address vni-value] 427 +--rw vpn-rd rt-types:route-distinguisher 428 +--rw source-address ip-multicast-source-address 429 +--rw group-address 430 | rt-types:ip-multicast-group-address 431 +--rw mac-address yang:mac-address 432 +--rw vni-value uint32 433 +--rw multicast-overlay 434 | +--rw vni-type? virtual-type 435 | +--rw ingress-egress 436 | | +--rw ingress-nodes* [ingress-node] 437 | | | +--rw ingress-node inet:ip-address 438 | | +--rw egress-nodes* [egress-node] 439 | | +--rw egress-node inet:ip-address 440 | +--rw bier-ids {bier}? 441 | | +--rw sub-domain? uint16 442 | | +--rw ingress-nodes* [ingress-node] 443 | | | +--rw ingress-node uint16 444 | | +--rw egress-nodes* [egress-node] 445 | | +--rw egress-node uint16 446 | +--rw dynamic-overlay 447 | +--rw type? identityref 448 | +--rw mld 449 | +--rw mld-instance-group? 450 | rt-types:ip-multicast-group-address 451 +--rw multicast-transport 452 | +--rw type? identityref 453 | +--rw bier 454 | | +--rw sub-domain? uint16 455 | | +--rw bitstringlength? uint16 456 | | +--rw set-identifier? uint16 457 | | +--rw (encap-type)? 458 | | +--:(mpls) 459 | | +--:(eth) 460 | | +--:(ipv6) 461 | +--rw bier-te 462 | | +--rw sub-domain? uint16 463 | | +--rw bitstringlength? uint16 464 | | +--rw set-identifier? uint16 465 | | +--rw (encap-type)? 466 | | | +--:(mpls) 467 | | | +--:(eth) 468 | | | +--:(ipv6) 469 | | +--rw bitstring* [name] 470 | | +--rw name string 471 | | +--rw bier-te-adj* [adj-id] 472 | | +--rw adj-id uint16 473 | +--rw cisco-mdt 474 | | +--rw p-group? rt-types:ip-multicast-group-address 475 | +--rw rsvp-te-p2mp 476 | | +--rw template-name? string 477 | +--rw pim 478 | | +--rw source-address? ip-multicast-source-address 479 | | +--rw group-address 480 | | rt-types:ip-multicast-group-address 481 | +--rw sr-p2mp 482 | +--rw ir-segment-lists* [name] 483 | | +--rw name string 484 | +--rw replication-segment* [replication-id node-id] 485 | +--rw replication-id tree-sid 486 | +--rw node-id inet:ip-address 487 +--rw multicast-underlay 488 +--rw type? identityref 489 +--rw ospf 490 | +--rw topology? string 491 +--rw isis 492 | +--rw topology? string 493 +--rw pim 494 +--rw source-address? ip-multicast-source-address 495 +--rw group-address 496 rt-types:ip-multicast-group-address 498 notifications: 499 +---n ingress-egress-event 500 +--ro event-type? enumeration 501 +--ro multicast-key 502 | +--ro vpn-rd? rt-types:route-distinguisher 503 | +--ro source-address? ip-multicast-source-address 504 | +--ro group-address? rt-types:ip-multicast-group-address 505 | +--ro mac-address? yang:mac-address 506 | +--ro vni-value? uint32 507 +--ro dynamic-overlay 508 | +--ro type? identityref 509 | +--ro mld 510 | +--ro mld-instance-group? 511 | rt-types:ip-multicast-group-address 512 +--ro transport-tech 513 | +--ro type? identityref 514 | +--ro bier 515 | | +--ro sub-domain? uint16 516 | | +--ro bitstringlength? uint16 517 | | +--ro set-identifier? uint16 518 | | +--ro (encap-type)? 519 | | +--:(mpls) 520 | | +--:(eth) 521 | | +--:(ipv6) 522 | +--ro bier-te 523 | | +--ro sub-domain? uint16 524 | | +--ro bitstringlength? uint16 525 | | +--ro set-identifier? uint16 526 | | +--ro (encap-type)? 527 | | | +--:(mpls) 528 | | | +--:(eth) 529 | | | +--:(ipv6) 530 | | +--ro bitstring* [name] 531 | | +--ro name string 532 | | +--ro bier-te-adj* [adj-id] 533 | | +--ro adj-id uint16 534 | +--ro cisco-mdt 535 | | +--ro p-group? rt-types:ip-multicast-group-address 536 | +--ro rsvp-te-p2mp 537 | | +--ro template-name? string 538 | +--ro pim 539 | | +--ro source-address? ip-multicast-source-address 540 | | +--ro group-address 541 | | rt-types:ip-multicast-group-address 542 | +--ro sr-p2mp 543 | +--ro ir-segment-lists* [name] 544 | | +--ro name string 545 | +--ro replication-segment* [replication-id node-id] 546 | +--ro replication-id tree-sid 547 | +--ro node-id inet:ip-address 548 +--ro underlay-tech 549 +--ro type? identityref 550 +--ro ospf 551 | +--ro topology? string 552 +--ro isis 553 | +--ro topology? string 554 +--ro pim 555 +--ro source-address? ip-multicast-source-address 556 +--ro group-address 557 rt-types:ip-multicast-group-address 559 3.3. Multicast YANG data model Configuration 561 This model is used with other protocol data model to provide 562 multicast service. 564 This model includes multicast service keys and three layers: the 565 multicast overlay, the transport layer and the multicast underlay 566 information. Multicast keys include the features of multicast flow, 567 such as(vpnid, multicast source and multicast group) information. In 568 data center network, for fine-grained to gather the nodes belonging 569 to the same virtual network, there may need VNI-related information 570 to assist. 572 Multicast overlay defines (ingress-node, egress-nodes) nodes 573 information. If the transport layer is BIER, there may define BIER 574 information including (Subdomain, ingress-node BFR-id, egress-nodes 575 BFR-id). If no (ingress-node, egress-nodes) information are defined 576 directly, there may need overlay multicast signaling technology, such 577 as MLD or MVPN, to collect these nodes information. 579 Multicast transport layer defines the type of transport technologies 580 that can be used to forward multicast flow, including BIER forwarding 581 type, MPLS forwarding type, or PIM forwarding type and so on. One or 582 several transport technologies could be defined at the same time. As 583 for the detailed parameters for each transport technology, this 584 multicast YANG data model may invoke the corresponding protocol model 585 to define them. 587 Multicast underlay defines the type of underlay technologies, such as 588 OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay 589 technologies could be defined at the same time if there is protective 590 requirement. As for the specific parameters for each underlay 591 technology, this multicast YANG data model can depend the 592 corresponding protocol model to configure them as well. 594 The configuration modeling branch is composed of the keys, overlay 595 layer, transport layer and underlay layer. 597 3.4. Multicast YANG data model State 599 Multicast model states are the same with the configuration. 601 3.5. Multicast YANG data model Notification 603 The defined Notifications include the events of ingress or egress 604 nodes. Like ingress node failure, overlay/ transport/ underlay 605 module loading/ unloading. And the potential failure about some 606 multicast flows and associated overlay/ transport/ underlay 607 technologies. 609 4. Multicast YANG data Model 611 This module references [RFC1195], [RFC2328], [RFC4271], [RFC4541], 612 [RFC4875], [RFC5340], [RFC6037], [RFC6388], [RFC6513], [RFC6991], 613 [RFC7348], [RFC7432], [RFC7637], [RFC7716], [RFC7761], [RFC8279], 614 [RFC8294], [RFC8296], [RFC8343], [RFC8344], [RFC8349], [RFC8639], 615 [RFC8641], [RFC8926], [RFC8966], [I-D.ietf-pim-yang], 616 [I-D.ietf-bier-bier-yang], [I-D.ietf-bier-te-arch], 617 [I-D.ietf-bier-mld], [I-D.ietf-bess-evpn-bum-procedure-updates], 618 [I-D.ietf-bier-evpn], [I-D.ietf-bier-bierin6], 619 [I-D.ietf-bier-pim-signaling], [I-D.ietf-rift-rift], 620 [I-D.ietf-isis-yang-isis-cfg]. 622 file "ietf-multicast-model@2022-02-28.yang" 623 module ietf-multicast-model { 625 yang-version 1.1; 627 namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model"; 628 prefix ietf-multicast-model; 630 import ietf-yang-types { 631 prefix "yang"; 632 reference 633 "RFC 6991: Common YANG Data Types"; 634 } 636 import ietf-inet-types { 637 prefix "inet"; 638 reference 639 "RFC 6991: Common YANG Data Types"; 640 } 641 import ietf-routing-types { 642 prefix "rt-types"; 643 reference 644 "RFC 8294: Common YANG Data Types for the Routing Area"; 645 } 646 import ietf-routing { 647 prefix "rt"; 648 reference 649 "RFC 8349: A YANG Data Model for Routing Management 650 (NMDA Version)"; 651 } 653 organization " IETF MBONED (MBONE Deployment) Working Group"; 654 contact 655 "WG List: 656 Editor: Zheng Zhang 657 658 Editor: Cui Wang 659 660 Editor: Ying Cheng 661 662 Editor: Xufeng Liu 663 664 Editor: Mahesh Sivakumar 665 666 "; 668 // RFC Ed.: replace XXXX with actual RFC number and remove 669 // this note 671 description 672 "The module defines the YANG definitions for multicast service 673 management. 675 Copyright (c) 2021 IETF Trust and the persons identified as 676 authors of the code. All rights reserved. 678 Redistribution and use in source and binary forms, with or 679 without modification, is permitted pursuant to, and subject 680 to the license terms contained in, the Simplified BSD 681 License set forth in Section 4.c of the IETF Trust's Legal 682 Provisions Relating to IETF Documents 683 (https://trustee.ietf.org/license-info). 685 This version of this YANG module is part of RFC XXXX 686 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 687 itself for full legal notices. 689 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 690 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 691 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 692 are to be interpreted as described in BCP 14 (RFC 2119) 693 (RFC 8174) when, and only when, they appear in all 694 capitals, as shown here."; 696 revision 2022-02-28 { 697 description 698 "Initial revision."; 699 reference 700 "RFC XXXX: A YANG Data Model for multicast YANG."; 701 } 703 /* 704 *feature 705 */ 706 feature bier { 707 description 708 "Cooperation with BIER technology."; 709 reference 710 "RFC 8279: 711 Multicast Using Bit Index Explicit Replication (BIER)."; 712 } 714 /* 715 *typedef 716 */ 717 typedef ip-multicast-source-address { 718 type union { 719 type enumeration { 720 enum * { 721 description 722 "Any source address."; 723 } 724 } 725 type inet:ipv4-address; 726 type inet:ipv6-address; 727 } 728 description 729 "Multicast source IP address type."; 730 } 731 typedef tree-sid { 732 type union { 733 type rt-types:mpls-label; 734 type inet:ip-prefix; 735 } 736 description 737 "The type of the Segment Identifier of a Replication segment 738 is a SR-MPLS label or a SRv6 SID."; 739 } 740 typedef virtual-type { 741 type enumeration { 742 enum vxlan { 743 description 744 "The VXLAN encapsulation is used for flow encapsulation."; 745 reference 746 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 747 A Framework for Overlaying Virtualized Layer 2 Networks 748 over Layer 3 Networks."; 749 } 750 enum nvgre { 751 description 752 "The NVGRE encapsulation is used for flow encapsulation."; 753 reference 754 "RFC 7637: NVGRE: Network Virtualization Using Generic 755 Routing Encapsulation."; 756 } 757 enum geneve { 758 description 759 "The GENEVE encapsulation is used for flow encapsulation."; 760 reference 761 "RFC 8926: Geneve: Generic Network 762 Virtualization Encapsulation."; 763 } 764 } 765 description 766 "The encapsulation type used for the flow. 767 When this type is set, the associated vni-value 768 MUST be set."; 769 } // virtual-type 771 /* 772 * Identities 773 */ 775 identity multicast-model { 776 base "rt:control-plane-protocol"; 777 description "Identity for the multicast model."; 778 } 779 identity overlay-type { 780 description 781 "Base identity for the type of multicast overlay technology."; 782 } 783 identity transport-type { 784 description "Identity for the multicast transport technology."; 785 } 786 identity underlay-type { 787 description "Identity for the multicast underlay technology."; 788 } 789 identity overlay-pim { 790 base overlay-type; 791 description 792 "Using PIM as multicast overlay technology. 793 For example, as BIER overlay."; 794 reference 795 "I-D.ietf-bier-pim-signaling: 796 PIM Signaling Through BIER Core."; 797 } 798 identity mld { 799 base overlay-type; 800 description 801 "Using MLD as multicast overlay technology. 802 For example, as BIER overlay."; 803 reference 804 "I-D.ietf-bier-mld: 805 BIER Ingress Multicast Flow Overlay 806 using Multicast Listener Discovery Protocols."; 807 } 808 identity mld-snooping { 809 base overlay-type; 810 description 811 "Using MLD as multicast overlay technology. 812 For example, as BIER overlay."; 813 reference 814 "RFC 4541: 815 Considerations for Internet Group Management 816 Protocol (IGMP) and Multicast Listener 817 Discovery (MLD) Snooping Switches."; 818 } 819 identity evpn { 820 base overlay-type; 821 description 822 "Using EVPN as multicast overlay technology."; 823 reference 824 "RFC 7432: BGP MPLS-Based Ethernet VPN. 825 I-D.ietf-bess-evpn-bum-procedure-updates: 826 Updates on EVPN BUM Procedures. 827 I-D.ietf-bier-evpn: EVPN BUM Using BIER."; 828 } 829 identity mvpn { 830 base overlay-type; 831 description 832 "Using MVPN as multicast overlay technology."; 833 reference 834 "RFC 6513: Multicast in MPLS/BGP IP VPNs. 835 RFC 7716: 836 Global Table Multicast with BGP Multicast VPN 837 (BGP-MVPN) Procedures."; 838 } 839 identity bier { 840 base transport-type; 841 description 842 "Using BIER as multicast transport technology."; 843 reference 844 "RFC 8279: 845 Multicast Using Bit Index Explicit Replication (BIER)."; 846 } 847 identity bier-te { 848 base transport-type; 849 description 850 "Using BIER-TE as multicast transport technology."; 851 reference 852 "I-D.ietf-bier-te-arch: 853 Traffic Engineering for Bit Index Explicit Replication 854 (BIER-TE)"; 855 } 856 identity mldp { 857 base transport-type; 858 description 859 "Using mLDP as multicast transport technology."; 860 reference 861 "RFC 6388: 862 Label Distribution Protocol Extensions 863 for Point-to-Multipoint and Multipoint-to-Multipoint 864 Label Switched Paths. 865 I-D.ietf-mpls-mldp-yang: YANG Data Model for MPLS mLDP."; 866 } 867 identity rsvp-te-p2mp { 868 base transport-type; 869 description 870 "Using P2MP TE as multicast transport technology."; 871 reference 872 "RFC 4875: 873 Extensions to Resource Reservation Protocol 874 - Traffic Engineering (RSVP-TE) for Point-to-Multipoint 875 TE Label Switched Paths (LSPs)."; 876 } 877 identity sr-p2mp { 878 base transport-type; 879 description 880 "Using Segment Routing as multicast transport technology."; 881 reference 882 "I-D.ietf-pim-sr-p2mp-policy: 883 Segment Routing Point-to-Multipoint Policy."; 884 } 885 identity cisco-mdt { 886 base transport-type; 887 description 888 "Using cisco MDT for multicast transport technology."; 889 reference 890 "RFC 6037: 891 Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs"; 892 } 893 identity pim { 894 base transport-type; 895 base underlay-type; 896 description 897 "Using PIM as multicast transport technology."; 898 reference 899 "RFC 7761: 900 Protocol Independent Multicast - Sparse Mode 901 (PIM-SM): Protocol Specification (Revised)."; 902 } 903 identity bgp { 904 base underlay-type; 905 description 906 "Using BGP as underlay technology to build the multicast 907 transport layer. For example, using BGP as BIER underlay."; 908 reference 909 "I-D.ietf-bier-idr-extensions: BGP Extensions for BIER."; 910 } 911 identity ospf { 912 base underlay-type; 913 description 914 "Using OSPF as multicast underlay technology. 915 For example, using OSPF as BIER underlay."; 916 reference 917 "RFC 8444: 918 OSPFv2 Extensions for Bit Index Explicit Replication (BIER), 919 I-D.ietf-bier-ospfv3-extensions: 920 OSPFv3 Extensions for BIER."; 921 } 922 identity isis { 923 base underlay-type; 924 description 925 "Using ISIS as multicast underlay technology. 926 For example, using ISIS as BIER underlay."; 927 reference 928 "RFC 8401: 929 Bit Index Explicit Replication (BIER) Support via IS-IS"; 930 } 931 identity babel { 932 base underlay-type; 933 description 934 "Using BABEL as multicast underlay technology. 935 For example, using BABEL as BIER underlay."; 936 reference 937 "RFC 8966: The Babel Routing Protocol 938 I-D.zhang-bier-babel-extensions: BIER in BABEL"; 939 } 940 identity rift { 941 base underlay-type; 942 description 943 "Using RIFT as multicast underlay technology. 945 For example, using RIFT as BIER underlay."; 946 reference 947 "I-D.ietf-rift-rift: RIFT: Routing in Fat Trees. 948 I-D.zzhang-bier-rift: Supporting BIER with RIFT"; 949 } 951 grouping general-multicast-key { 952 description 953 "The general multicast keys. They are used to distinguish 954 different multicast service."; 955 leaf vpn-rd { 956 type rt-types:route-distinguisher; 957 description 958 "A Route Distinguisher used to distinguish 959 routes from different MVPNs."; 960 reference 961 "RFC 8294: Common YANG Data Types for the Routing Area. 962 RFC 6513: Multicast in MPLS/BGP IP VPNs."; 963 } 964 leaf source-address { 965 type ip-multicast-source-address; 966 description 967 "The IPv4/IPv6 source address of the multicast flow. The 968 value set to zero means that the receiver interests 969 in all source that relevant to one given group."; 970 } 971 leaf group-address { 972 type rt-types:ip-multicast-group-address; 973 description 974 "The IPv4/IPv6 group address of multicast flow. This 975 type represents a version-neutral IP multicast group 976 address. The format of the textual representation 977 implies the IP version."; 978 reference 979 "RFC 8294: Common YANG Data Types for the Routing Area."; 980 } 981 leaf mac-address { 982 type yang:mac-address; 983 description 984 "The mac address of flow. In the EVPN situation, the L2 985 flow that is called 986 BUM (Broadcast, Unknown Unicast, Multicast) 987 can be sent to the other PEs that 988 are in a same broadcast domain."; 989 reference 990 "RFC 6991: Common YANG Data Types. 991 RFC 7432: BGP MPLS-Based Ethernet VPN."; 992 } 993 leaf vni-value { 994 type uint32; 995 description 996 "The value of Vxlan network identifier, virtual subnet ID 997 or virtual net identifier. This value and vni-type is used 998 to indicate a specific virtual multicast service."; 999 } 1000 } // general-multicast-key 1002 grouping encap-type { 1003 description 1004 "The encapsulation type used for flow forwarding. 1005 This encapsulation acts as the inner encapsulation, 1006 as compare to the outer multicast-transport encapsulation."; 1007 choice encap-type { 1008 case mpls { 1009 description "The BIER forwarding depends on mpls."; 1010 reference 1011 "RFC 8296: Encapsulation for Bit Index Explicit 1012 Replication (BIER) in MPLS and Non-MPLS Networks."; 1013 } 1014 case eth { 1015 description "The BIER forwarding depends on ethernet."; 1016 reference 1017 "RFC 8296: Encapsulation for Bit Index Explicit 1018 Replication (BIER) in MPLS and Non-MPLS Networks."; 1019 } 1020 case ipv6 { 1021 description "The BIER forwarding depends on IPv6."; 1022 reference 1023 "I-D.ietf-bier-bierin6: BIER in IPv6 (BIERin6)"; 1024 } 1025 description "The encapsulation type in BIER."; 1026 } 1027 } // encap-type 1029 grouping bier-key { 1030 description 1031 "The key parameters set for BIER/BIER TE forwarding."; 1032 reference 1033 "RFC 8279: Multicast Using Bit Index Explicit Replication 1034 (BIER)."; 1036 leaf sub-domain { 1037 type uint16; 1038 description 1039 "The subdomain id that the multicast flow belongs to."; 1040 } 1041 leaf bitstringlength { 1042 type uint16; 1043 description 1044 "The bitstringlength used by BIER forwarding."; 1045 } 1046 leaf set-identifier { 1047 type uint16; 1048 description 1049 "The set identifier used by the multicast flow."; 1050 } 1051 uses encap-type; 1052 } 1054 grouping transport-tech { 1055 description 1056 "The transport technology selected for the multicast service. 1057 For one specific multicast flow, it's better to use only one 1058 transport technology for forwarding."; 1060 leaf type { 1061 type identityref { 1062 base transport-type; 1063 } 1064 description "The type of transport technology"; 1065 } 1066 container bier { 1067 when "../type = 'ietf-multicast-model:bier'" { 1068 description 1069 "Only when BIER is used as transport technology."; 1070 } 1071 description 1072 "The transport technology is BIER. The BIER technology 1073 is introduced in RFC8279. The parameters are consistent 1074 with the definition in BIER YANG data model."; 1075 reference 1076 "I-D.ietf-bier-bier-yang: 1077 YANG Data Model for BIER Protocol."; 1078 uses bier-key; 1079 } 1080 container bier-te { 1081 when "../type = 'ietf-multicast-model:bier-te'" { 1082 description 1083 "Only when BIER-TE is used as transport technology."; 1084 } 1085 description 1086 "The BIER-TE parameter that may need to be set. 1087 The parameters are consistent with the definition in 1088 BIER and BIER TE YANG data model."; 1090 reference 1091 "I-D.ietf-bier-bier-yang: 1092 YANG Data Model for BIER Protocol 1093 I-D.ietf-bier-te-yang: 1094 A YANG data model for Traffic Engineering for Bit Index 1095 Explicit Replication (BIER-TE)"; 1097 uses bier-key; 1099 list bitstring { 1100 key "name"; 1101 leaf name { 1102 type string; 1103 description "The name of the bitstring"; 1104 } 1105 list bier-te-adj { 1106 key "adj-id"; 1107 leaf adj-id { 1108 type uint16; 1109 description 1110 "The link adjacency ID used for BIER TE forwarding."; 1111 } 1112 description 1113 "The adjacencies ID used for BIER TE bitstring 1114 encapsulation."; 1115 } 1116 description 1117 "The bitstring name and detail used for BIER TE 1118 forwarding encapsulation. One or more bitstring can be 1119 used for backup path."; 1120 } 1121 } 1122 container cisco-mdt { 1123 when "../type = 'ietf-multicast-model:cisco-mdt'" { 1124 description 1125 "Only when cisco MDT is used as transport technology."; 1126 } 1127 description "The MDT parameter that may need to be set."; 1128 leaf p-group { 1129 type rt-types:ip-multicast-group-address; 1130 description 1131 "The address of p-group. It is used to encapsulate 1132 and forward flow according to multicast tree from 1133 ingress node to egress nodes."; 1134 } 1135 } 1136 container rsvp-te-p2mp { 1137 when "../type = 'ietf-multicast-model:rsvp-te-p2mp'" { 1138 description 1139 "Only when RSVP TE P2MP is used as transport technology."; 1140 } 1141 description 1142 "The parameter that may be set. They are consistent with 1143 the definition in TE data model."; 1144 reference 1145 "RFC 8776: Common YANG Data Types for Traffic Engineering"; 1147 leaf template-name { 1148 type string { 1149 pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; 1150 } 1151 description 1152 "A type for the name of a TE node template or TE link 1153 template."; 1154 } 1155 } 1156 container pim { 1157 when "../type = 'ietf-multicast-model:pim'" { 1158 description 1159 "Only when PIM is used as transport technology."; 1160 } 1161 description "The PIM parameter that may need to be set."; 1162 uses pim; 1163 } 1164 container sr-p2mp { 1165 when "../type = 'ietf-multicast-model:sr-p2mp'" { 1166 description 1167 "Only when segment routing P2MP is used as transport 1168 technology."; 1169 } 1170 description "The SR-P2MP parameter that may need to be set."; 1171 list ir-segment-lists { 1172 key "name"; 1173 leaf name { 1174 type string; 1175 description "Segment-list name"; 1176 } 1177 description 1178 "The segment lists used for ingress replication. 1179 The name refers a segment list."; 1180 } 1182 list replication-segment { 1183 key "replication-id node-id"; 1184 leaf replication-id { 1185 type tree-sid; 1186 description 1187 "The identifier for a Replication segment that is 1188 unique in context of the Replication Node. 1189 This is a SR-MPLS label or a SRv6 SID"; 1190 } 1191 leaf node-id { 1192 type inet:ip-address; 1193 description 1194 "The address of the Replication Node that the 1195 Replication segment is for."; 1196 } 1197 description 1198 "A Multi-point service delivery could be realized via 1199 P2MP trees in a Segment Routing domain. 1200 It may consist of one or more Replication segment"; 1201 reference 1202 "I-D.ietf-spring-sr-replication-segment: 1203 SR Replication Segment for Multi-point Service 1204 Delivery."; 1205 } 1206 } // sr-p2mp 1207 } // transport-tech 1209 grouping underlay-tech { 1210 description 1211 "The underlay technology selected for the transport layer. 1212 The underlay technology has no straight relationship with 1213 the multicast overlay, it is used for transport path 1214 building, for example BIER forwarding path building."; 1216 leaf type { 1217 type identityref { 1218 base underlay-type; 1219 } 1220 description "The type of underlay technology"; 1221 } 1222 container ospf { 1223 when "../type = 'ietf-multicast-model:ospf'" { 1224 description 1225 "Only when OSPF is used as underay technology."; 1226 } 1227 description 1228 "If OSPF protocol supports multiple topology feature, 1229 the associated topology name may be assigned. 1230 In case the topology name is assigned, the specific 1231 OSPF topology is used for underly to building the 1232 transport layer."; 1233 reference 1234 "RFC 4915: Multi-Topology Routing"; 1235 leaf topology { 1236 type string; 1237 description 1238 "The designed topology name of ospf protocol."; 1239 } 1240 } 1241 container isis { 1242 when "../type = 'ietf-multicast-model:isis'" { 1243 description 1244 "Only when ISIS is used as underay technology."; 1245 } 1246 description 1247 "If ISIS protocol supports multiple topology feature, 1248 the associated topology name may be assigned. 1249 In case the topology name is assigned, the specific 1250 ISIS topology is used for underly to building the 1251 transport layer."; 1252 reference 1253 "RFC 5120: M-IS-IS: Multi Topology Routing in IS-IS"; 1254 leaf topology { 1255 type string; 1256 description 1257 "The designed topology name of isis protocol."; 1258 } 1259 } 1260 container pim { 1261 when "../type = 'ietf-multicast-model:pim'" { 1262 description 1263 "Only when PIM is used as underay technology."; 1264 } 1265 description "The PIM parameter that may need to be set."; 1266 uses pim; 1267 } 1268 } // underlay-tech 1270 /*overlay*/ 1272 grouping overlay-tech { 1273 container dynamic-overlay { 1274 leaf type { 1275 type identityref { 1276 base overlay-type; 1277 } 1278 description "The type of overlay technology"; 1279 } 1280 container mld { 1281 when "../type = 'ietf-multicast-model:mld'" { 1282 description 1283 "Only when MLD is used as overlay technology."; 1284 } 1285 description "The MLD parameter that may need to be set."; 1286 leaf mld-instance-group { 1287 type rt-types:ip-multicast-group-address; 1288 description 1289 "The multicast address used for multiple MLD instance 1290 support."; 1291 } 1292 } 1293 description 1294 "The dynamic overlay technologies and associated parameter 1295 that may be set."; 1296 } 1297 description "The overlay technology used for multicast service."; 1298 } // overlay-tech 1300 /*transport*/ 1302 grouping pim { 1303 description 1304 "The required information of pim transportion."; 1305 leaf source-address { 1306 type ip-multicast-source-address; 1307 description 1308 "The IPv4/IPv6 source address of the multicast flow. The 1309 value set to zero means that the receiver interests 1310 in all source that relevant to one given group."; 1311 } 1312 leaf group-address { 1313 type rt-types:ip-multicast-group-address; 1314 mandatory true; 1315 description 1316 "The IPv4/IPv6 group address of multicast flow. This 1317 type represents a version-neutral IP multicast group 1318 address. The format of the textual representation 1319 implies the IP version."; 1320 } 1321 reference 1322 "RFC 7761: Protocol Independent Multicast - Sparse Mode 1323 (PIM-SM): Protocol Specification (Revised)."; 1324 } //pim 1326 /*underlay*/ 1328 container multicast-model { 1329 description 1330 "The model of multicast YANG data. Include keys, overlay, 1331 transport and underlay."; 1333 list multicast-keys{ 1334 key "vpn-rd source-address group-address mac-address 1335 vni-value"; 1336 uses general-multicast-key; 1338 container multicast-overlay { 1339 description 1340 "The overlay information of multicast service. 1341 Overlay technology is used to exchange multicast 1342 flows information. Overlay technology may not be 1343 used in SDN controlled completely situation, but 1344 it can be used in partial SDN controlled situation 1345 or non-SDN controlled situation. Different overlay 1346 technologies can be choosed according to different 1347 deploy consideration."; 1349 leaf vni-type { 1350 type virtual-type; 1351 description 1352 "The encapsulated type for the multicast flow, 1353 it is used to carry the virtual network identifier 1354 for the multicast service."; 1355 } 1357 container ingress-egress { 1358 description 1359 "The ingress and egress nodes address collection. 1360 The ingress node may use the egress nodes set 1361 directly to encapsulate the multicast flow by 1362 transport technology."; 1364 list ingress-nodes { 1365 key "ingress-node"; 1366 description 1367 "The egress nodes of multicast flow."; 1369 leaf ingress-node { 1370 type inet:ip-address; 1371 description 1372 "The ip address of ingress node for one or more 1373 multicast flow. Or the ingress node of MVPN and 1374 BIER. In MVPN, this is the address of ingress 1375 PE; in BIER, this is the BFR-prefix of ingress 1376 nodes. 1377 Two or more ingress nodes may existed for the 1378 redundant ingress node protection."; 1379 } 1380 } 1382 list egress-nodes { 1383 key "egress-node"; 1384 description 1385 "The egress multicast nodes of the multicast flow. 1386 Or the egress node of MVPN and BIER. In MVPN, this 1387 is the address of egress PE; in BIER, this is the 1388 BFR-prefix of ingress nodes."; 1390 leaf egress-node { 1391 type inet:ip-address; 1392 description 1393 "The ip-address set of egress multicast nodes."; 1394 } 1395 } 1396 } 1398 container bier-ids { 1399 if-feature bier; 1400 description 1401 "The BFR-ids of ingress and egress BIER nodes for 1402 one or more multicast flows. This overlay is used 1403 with BIER transport technology. The egress nodes 1404 set can be used to encapsulate the multicast flow 1405 directly in the ingress node."; 1406 reference 1407 "RFC 8279: Multicast Using Bit Index Explicit 1408 Replication (BIER)"; 1410 leaf sub-domain { 1411 type uint16; 1412 description 1413 "The sub-domain that this multicast flow belongs to."; 1414 } 1415 list ingress-nodes { 1416 key "ingress-node"; 1417 description 1418 "The ingress nodes of multicast flow."; 1419 leaf ingress-node { 1420 type uint16; 1421 description 1422 "The ingress node of multicast flow. This is the 1423 BFR-id of ingress nodes."; 1424 } 1425 } 1426 list egress-nodes { 1427 key "egress-node"; 1428 description 1429 "The egress nodes of multicast flow."; 1431 leaf egress-node { 1432 type uint16; 1433 description 1434 "The BFR-ids of egress multicast BIER nodes."; 1435 } 1436 } 1437 } 1438 uses overlay-tech; 1439 } 1441 container multicast-transport { 1442 description 1443 "The transportion of multicast service. Transport 1444 protocol is responsible for delivering multicast 1445 flows from ingress nodes to egress nodes with or 1446 without specific encapsulation. Different transport 1447 technology can be choosed according to different 1448 deploy consideration. Once a transport technology 1449 is choosed, associated protocol should be triggered 1450 to run."; 1452 uses transport-tech; 1453 } 1454 container multicast-underlay { 1455 description 1456 "The underlay of multicast service. Underlay protocol 1457 is used to build transport layer. Underlay protocol 1458 need not be assigned in ordinary network since 1459 existed underlay protocol fits well, but it can be 1460 assigned in particular networks for better 1461 controll. Once a underlay technology is choosed, 1462 associated protocol should be triggered to run."; 1464 uses underlay-tech; 1465 } 1466 description 1467 "The model of multicast YANG data. Include keys, 1468 overlay, transport and underlay."; 1469 } 1470 } 1472 /*Notifications*/ 1473 notification ingress-egress-event { 1474 leaf event-type { 1475 type enumeration { 1476 enum down { 1477 description 1478 "There is something wrong with ingress or egress node, 1479 and node can't work properlay."; 1480 } 1481 enum protocol-enabled { 1482 description 1483 "The protocol that is used for multicast 1484 flows have been enabled."; 1485 } 1486 enum protocol-disabled { 1487 description 1488 "The protocol that is used by multicast 1489 flows have been disabled."; 1490 } 1491 } 1492 description "Event type."; 1493 } 1494 container multicast-key { 1495 uses general-multicast-key; 1496 description 1497 "The associated multicast keys that are influenced by 1498 ingress or egress node failer."; 1499 } 1500 uses overlay-tech; 1502 container transport-tech { 1503 description 1504 "The modules can be used to forward multicast flows."; 1505 uses transport-tech; 1506 } 1508 container underlay-tech { 1509 description 1510 "There is something wrong with the module which is 1511 used to build multicast transport layer."; 1512 uses underlay-tech; 1513 } 1514 description 1515 "Notification events for the ingress or egress nodes. Like 1516 node failer, overlay/ transport/ underlay module 1517 loading/ unloading. And the potential failer about some 1518 multicast flows and associated 1519 overlay/ transport/ underlay technologies."; 1520 } 1522 } 1523 1525 5. Security Considerations 1527 The YANG module specified in this document defines a schema for data 1528 that is designed to be accessed via network management protocols such 1529 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1530 is the secure transport layer, and the mandatory-to-implement secure 1531 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1532 is HTTPS, and the mandatory-to-implement secure transport is TLS 1533 [RFC8446]. 1535 The NETCONF access control model [RFC8341] provides the means to 1536 restrict access for particular NETCONF or RESTCONF users to a 1537 preconfigured subset of all available NETCONF or RESTCONF protocol 1538 operations and content. 1540 There are a number of data nodes defined in this YANG module that are 1541 writable/creatable/deletable (i.e., config true, which is the 1542 default). These data nodes may be considered sensitive or vulnerable 1543 in some network environments. Write operations (e.g., edit-config) 1544 to these data nodes without proper protection can have a negative 1545 effect on network operations. These are data nodes and their 1546 sensitivity/vulnerability: 1548 Under /rt:routing/rt:control-plane-protocols/multicast-model, 1550 multicast-model 1552 * These data nodes in this model specifies the configuration for the 1553 multicast service at the top level. Modifying the configuration 1554 can cause multicast service to be deleted or reconstructed. 1556 Some of the readable data nodes in this YANG module may be considered 1557 sensitive or vulnerable in some network environments. It is thus 1558 important to control read access (e.g., via get, get-config, or 1559 notification) to these data nodes. These are the data nodes and 1560 their sensitivity/vulnerability: 1562 /rt:routing/rt:control-plane-protocols/multicast-model, 1564 Unauthorized access to any data node of the above tree can disclose 1565 the operational state information of multicast service on this 1566 device. 1568 6. IANA Considerations 1570 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1571 number (and remove this note). 1573 The IANA is requested to assign one new URI from the IETF XML 1574 registry [RFC3688]. Authors are suggesting the following URI: 1576 URI: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1578 Registrant Contact: The IESG 1580 XML: N/A, the requested URI is an XML namespace 1582 This document also requests one new YANG module name in the YANG 1583 Module Names registry [RFC6020] with the following suggestion: 1585 name: ietf-multicast-model 1587 namespace: urn:ietf:params:xml:ns:yang:ietf-multicast-model 1589 prefix: multicast-model 1591 reference: RFC XXXX 1593 7. Acknowledgements 1595 The authors would like to thank Stig Venaas, Jake Holland, Min Gu, 1596 Gyan Mishra for their valuable comments and suggestions. 1598 8. References 1600 8.1. Normative References 1602 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 1603 dual environments", RFC 1195, DOI 10.17487/RFC1195, 1604 December 1990, . 1606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1607 Requirement Levels", BCP 14, RFC 2119, 1608 DOI 10.17487/RFC2119, March 1997, 1609 . 1611 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1612 DOI 10.17487/RFC2328, April 1998, 1613 . 1615 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1616 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1617 DOI 10.17487/RFC4271, January 2006, 1618 . 1620 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1621 Yasukawa, Ed., "Extensions to Resource Reservation 1622 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1623 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 1624 DOI 10.17487/RFC4875, May 2007, 1625 . 1627 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1628 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1629 . 1631 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1632 the Network Configuration Protocol (NETCONF)", RFC 6020, 1633 DOI 10.17487/RFC6020, October 2010, 1634 . 1636 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1637 and A. Bierman, Ed., "Network Configuration Protocol 1638 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1639 . 1641 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1642 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1643 . 1645 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1646 Thomas, "Label Distribution Protocol Extensions for Point- 1647 to-Multipoint and Multipoint-to-Multipoint Label Switched 1648 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1649 . 1651 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 1652 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 1653 2012, . 1655 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1656 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1657 . 1659 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1660 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1661 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1662 2015, . 1664 [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., 1665 and D. Pacella, "Global Table Multicast with BGP Multicast 1666 VPN (BGP-MVPN) Procedures", RFC 7716, 1667 DOI 10.17487/RFC7716, December 2015, 1668 . 1670 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1671 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1672 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1673 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1674 2016, . 1676 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1677 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1678 . 1680 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1681 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1682 . 1684 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1685 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1686 . 1688 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1689 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1690 May 2017, . 1692 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1693 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 1694 Explicit Replication (BIER)", RFC 8279, 1695 DOI 10.17487/RFC8279, November 2017, 1696 . 1698 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1699 "Common YANG Data Types for the Routing Area", RFC 8294, 1700 DOI 10.17487/RFC8294, December 2017, 1701 . 1703 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1704 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1705 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1706 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1707 2018, . 1709 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1710 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1711 . 1713 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1714 Access Control Model", STD 91, RFC 8341, 1715 DOI 10.17487/RFC8341, March 2018, 1716 . 1718 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1719 and R. Wilton, "Network Management Datastore Architecture 1720 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1721 . 1723 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1724 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1725 . 1727 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1728 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1729 . 1731 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1732 Routing Management (NMDA Version)", RFC 8349, 1733 DOI 10.17487/RFC8349, March 2018, 1734 . 1736 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1737 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1738 . 1740 8.2. Informative References 1742 [I-D.ietf-bess-evpn-bum-procedure-updates] 1743 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 1744 Sajassi, "Updates on EVPN BUM Procedures", Work in 1745 Progress, Internet-Draft, draft-ietf-bess-evpn-bum- 1746 procedure-updates-14, 18 November 2021, 1747 . 1750 [I-D.ietf-bier-bier-yang] 1751 Chen, R., Hu, F., Zhang, Z., Dai, X., and M. Sivakumar, 1752 "YANG Data Model for BIER Protocol", Work in Progress, 1753 Internet-Draft, draft-ietf-bier-bier-yang-07, 8 September 1754 2020, . 1757 [I-D.ietf-bier-bierin6] 1758 Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, 1759 H., and G. Mishra, "Supporting BIER in IPv6 Networks 1760 (BIERin6)", Work in Progress, Internet-Draft, draft-ietf- 1761 bier-bierin6-03, 3 February 2022, 1762 . 1765 [I-D.ietf-bier-evpn] 1766 Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan, 1767 "EVPN BUM Using BIER", Work in Progress, Internet-Draft, 1768 draft-ietf-bier-evpn-05, 7 December 2021, 1769 . 1772 [I-D.ietf-bier-mld] 1773 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 1774 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 1775 using Multicast Listener Discovery Protocols", Work in 1776 Progress, Internet-Draft, draft-ietf-bier-mld-06, 5 1777 January 2022, . 1780 [I-D.ietf-bier-pim-signaling] 1781 Bidgoli, H., Xu, F., Kotalwar, J., Wijnands, I., Mishra, 1782 M., and Z. Zhang, "PIM Signaling Through BIER Core", Work 1783 in Progress, Internet-Draft, draft-ietf-bier-pim- 1784 signaling-12, 25 July 2021, 1785 . 1788 [I-D.ietf-bier-te-arch] 1789 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 1790 for Bit Index Explicit Replication (BIER-TE)", Work in 1791 Progress, Internet-Draft, draft-ietf-bier-te-arch-10, 9 1792 July 2021, . 1795 [I-D.ietf-isis-yang-isis-cfg] 1796 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 1797 Lhotka, "YANG Data Model for IS-IS Protocol", Work in 1798 Progress, Internet-Draft, draft-ietf-isis-yang-isis-cfg- 1799 42, 15 October 2019, . 1802 [I-D.ietf-ospf-yang] 1803 Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, 1804 "YANG Data Model for OSPF Protocol", Work in Progress, 1805 Internet-Draft, draft-ietf-ospf-yang-29, 17 October 2019, 1806 . 1809 [I-D.ietf-pim-sr-p2mp-policy] 1810 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 1811 and Z. Zhang, "Segment Routing Point-to-Multipoint 1812 Policy", Work in Progress, Internet-Draft, draft-ietf-pim- 1813 sr-p2mp-policy-03, 23 August 2021, 1814 . 1817 [I-D.ietf-pim-yang] 1818 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1819 Y., and F. Hu, "A YANG Data Model for Protocol Independent 1820 Multicast (PIM)", Work in Progress, Internet-Draft, draft- 1821 ietf-pim-yang-17, 19 May 2018, 1822 . 1825 [I-D.ietf-rift-rift] 1826 Sharma, A., Thubert, P., Rijsman, B., Afanasiev, D., and 1827 A. Przygienda, "RIFT: Routing in Fat Trees", Work in 1828 Progress, Internet-Draft, draft-ietf-rift-rift-15, 3 1829 January 2022, . 1832 [I-D.szcl-mboned-redundant-ingress-failover] 1833 Shepherd, G., Zhang, Z., Liu, Y., and Y. Cheng, "Multicast 1834 Redundant Ingress Router Failover", Work in Progress, 1835 Internet-Draft, draft-szcl-mboned-redundant-ingress- 1836 failover-02, 13 February 2022, 1837 . 1840 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1841 DOI 10.17487/RFC3688, January 2004, 1842 . 1844 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 1845 "Considerations for Internet Group Management Protocol 1846 (IGMP) and Multicast Listener Discovery (MLD) Snooping 1847 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 1848 . 1850 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 1851 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 1852 RFC 6037, DOI 10.17487/RFC6037, October 2010, 1853 . 1855 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1856 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1857 eXtensible Local Area Network (VXLAN): A Framework for 1858 Overlaying Virtualized Layer 2 Networks over Layer 3 1859 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1860 . 1862 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 1863 Virtualization Using Generic Routing Encapsulation", 1864 RFC 7637, DOI 10.17487/RFC7637, September 2015, 1865 . 1867 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1868 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1869 DOI 10.17487/RFC8407, October 2018, 1870 . 1872 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1873 E., and A. Tripathy, "Subscription to YANG Notifications", 1874 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1875 . 1877 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1878 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1879 September 2019, . 1881 [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., 1882 "Geneve: Generic Network Virtualization Encapsulation", 1883 RFC 8926, DOI 10.17487/RFC8926, November 2020, 1884 . 1886 [RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing 1887 Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021, 1888 . 1890 Appendix A. Data Tree Example 1892 This section contains an example of an instance data tree in JSON 1893 encoding [RFC7951], containing configuration data. 1895 The configuration example: 1897 { 1898 "ietf-multicast-model:multicast-model":{ 1899 "multicast-keys":[ 1900 { 1901 "vpn-rd":"0:65532:4294967292", 1902 "source-address":"*", 1903 "group-address":"234.232.203.84", 1904 "mac-address": "00:00:5e:00:53:01", 1905 "vni-value":0, 1906 "multicast-overlay":{ 1907 "vni-type":"nvgre", 1908 "ingress-egress":{ 1909 "ingress-nodes":[ 1910 { 1911 "ingress-node":"146.150.100.0" 1912 } 1913 ], 1914 "egress-nodes":[ 1915 { 1916 "egress-node":"110.141.168.0" 1917 } 1918 ] 1919 } 1920 }, 1921 "multicast-transport":{ 1922 "type": "ietf-multicast-model:bier", 1923 "bier":{ 1924 "sub-domain":0, 1925 "bitstringlength":256, 1926 "set-identifier":0 1927 } 1928 }, 1929 "multicast-underlay":{ 1930 "type": "ietf-multicast-model:ospf", 1931 "ospf":{ 1932 "topology":"2" 1933 } 1934 } 1935 } 1936 ] 1937 } 1938 } 1940 Authors' Addresses 1941 Zheng Zhang 1942 ZTE Corporation 1943 China 1944 Email: zhang.zheng@zte.com.cn 1946 Cui(Linda) Wang 1947 Individual 1948 Australia 1949 Email: lindawangjoy@gmail.com 1951 Ying Cheng 1952 China Unicom 1953 Beijing 1954 China 1955 Email: chengying10@chinaunicom.cn 1957 Xufeng Liu 1958 Volta Networks 1959 Email: xufeng.liu.ietf@gmail.com 1961 Mahesh Sivakumar 1962 Juniper networks 1963 1133 Innovation Way 1964 Sunnyvale, CALIFORNIA 94089, 1965 United States of America 1966 Email: sivakumar.mahesh@gmail.com