idnits 2.17.1 draft-zhang-mboned-multicast-yang-model-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 118 instances of too long lines in the document, the longest one being 324 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 220 has weird spacing: '...ss-node ine...' == Line 225 has weird spacing: '...ss-node bie...' -- The document date (February 21, 2018) is 2256 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) == Unused Reference: 'I-D.ietf-bier-bier-yang' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-te-arch' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pim-yang' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC6037' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC6087' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC7277' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC8022' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'RFC8177' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC8279' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC8294' is defined on line 816, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-bier-yang-03 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 == Outdated reference: A later version (-17) exists of draft-ietf-pim-yang-13 ** Downref: Normative reference to an Historic RFC: RFC 6037 ** Obsolete normative reference: RFC 6087 (Obsoleted by RFC 8407) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) ** Obsolete normative reference: RFC 8022 (Obsoleted by RFC 8349) Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED WG Zheng. Zhang 3 Internet-Draft Cui. Wang 4 Intended status: Standards Track ZTE Corporation 5 Expires: August 25, 2018 Ying. Cheng 6 China Unicom 7 February 21, 2018 9 Multicast YANG Data Model 10 draft-zhang-mboned-multicast-yang-model-00 12 Abstract 14 This document intents to provide a general and all-round multicast 15 YANG data model, which tries to stand at a high level to take full 16 advantages of existed multicast protocol models to control the 17 multicast network, and guides the deployment of multicast service. 18 And also, there will define several possible RPCs about how to 19 interact between multicast YANG data model and multicast protocol 20 models. This multicast YANG data model is mainly used by the 21 management tools run by the network operators in order to manage, 22 monitor and debug the network resources used to deliver multicast 23 service, as well as gathering some data from the network. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 25, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Design of the multicast model . . . . . . . . . . . . . . . . 4 61 3. UML Class like Diagram for Multicast YANG data Model . . . . 4 62 4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Multicast YANG data Model . . . . . . . . . . . . . . . . . . 7 64 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 16 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 16 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 69 1. Introduction 71 Currently, there are many multicast protocol YANG models, such as 72 PIM, MLD, and BIER and so on. But all these models are distributed 73 in different working groups as separate files and focus on the 74 protocol itself. Furthermore, they cannot describe a high-level 75 multicast service required by network operators. 77 This document intents to provide a general and all-round multicast 78 model, which tries to stand at a high level to take full advantages 79 of these aforementioned models to control the multicast network, and 80 guides the deployment of multicast service. 82 This multicast YANG data model is mainly used by the management tools 83 run by the network operators in order to manage, monitor and debug 84 the network resources used to deliver multicast service, as well as 85 gathering some data from the network. 87 +------------------------+ 88 | Multicast Model | 89 +------------------------+ 90 | | | 91 | | | 92 | +---------+ +----------+ 93 | | EMS/NMS | |Controller| 94 | +---------+ +----------+ 95 | | | 96 | | | 97 +------------------------------------------------+ 98 | Network Element1.....N | 99 +------------------------------------------------+ 101 Figure 1: Example usage of Multicast Model 103 Detailly, in figure 1, there is an example of usage of this multicast 104 model. Network operators can use this model in a controller who is 105 responsible to implement some multicast flows with specific protocols 106 and invoke the corresponding protocols' model to configure the 107 network elements through NETCONF/RESTCONF/CLI. Or network operators 108 can use this model to the EMS/NMS to manage the network elements or 109 configure the network elements directly. For example, a multicast 110 service need to be delopy in a network, supposed that the multicast 111 flow is 239.0.0.0/8, the flow should be transport by BIER technology. 112 Then we use this multicast YANG data model and set the correspond key 113 (239.0.0.0) and associated transport technology with BIER, send the 114 model from controller to every egde node in the network. Then there 115 is an interaction among all the nodes to exchange the multicast flow 116 information. The ingress node will encapsulate the multicast flow 117 with BIER header and send it into the network. Intermediate nodes 118 will forward the flows to all the egress nodes by BIER forwarding. 120 On the other hand, when the network elements detect failure or some 121 other changes, the network devices can send the affected multicast 122 flows and the associated overlay/ transport/ underlay information to 123 the controller. Then the controller/ EMS/NMS can response 124 immediately due to the failure and distribute new model for the flows 125 to the network nodes quickly. Such as the changing of the failure 126 overlay protocol to another one, as well as transport and underlay 127 protocol. 129 Specifically, in section 3, it provides a human readability of the 130 whole multicast network through UML like class diagram, which frames 131 different multicast components and correlates them in a readable 132 fashion. Then, based on this UML like class diagram, there is 133 instantiated and detailed YANG model in Section 5. 135 In other words, this document does not define any specific protocol 136 model, instead, it depends on many existed multicast protocol models 137 and relates several multicast information together to fulfill 138 multicast service. 140 2. Design of the multicast model 142 This model includes multicast service keys and three layers: the 143 multicast overlay, the transport layer and the multicast underlay 144 information. Multicast keys include the features of multicast flow, 145 such as(vpnid, multicast source and multicast group) information. In 146 data center network, for fine-grained to gather the nodes belonging 147 to the same virtual network, there may need VNI-related information 148 to assist. 150 Multicast overlay defines (ingress-node, egress-nodes) nodes 151 information. If the transport layer is BIER, there may define BIER 152 information including (Subdomain, ingress-node BFR-id, egress-nodes 153 BFR-id). If no (ingress-node, egress-nodes) information are defined 154 directly, there may need overlay multicast signaling technology, such 155 as MLD or MVPN, to collect these nodes information. 157 Multicast transport layer defines the type of transport technologies 158 that can be used to forward multicast flow, including BIER forwarding 159 type, MPLS forwarding type, or PIM forwarding type and so on. One or 160 several transport technologies could be defined at the same time. As 161 for the detailed parameters for each transport technology, this 162 multicast YANG data model can invoke the corresponding protocol model 163 to define them. 165 Multicast underlay defines the type of underlay technologies, such as 166 OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay 167 technologies could be defined at the same time if there is protective 168 requirement. As for the specific parameters for each underlay 169 technology, this multicast YANG data model can depend the 170 corresponding protocol model to configure them as well. 172 3. UML Class like Diagram for Multicast YANG data Model 174 The following is a UML like diagram for Multicast YANG data Model. 176 +-------------------+ 177 | Multicast Model | 178 +-------------------+ 179 | | | |Contain 180 +-----------------------------------------+ | | | 181 | +----------------- -+ | +---------------------------+ 182 | | | | 183 +-----------+ +-------------------+ +----------------------+ +--------------------+ 184 |Multi-keys | | Multicast Overlay | | Multicast Transport | | Multicast Underlay | 185 +-----------+ +-------------------+ +----------------------+ +--------------------+ 186 |Group Addr | | |Contain | | | | | invoke | | | | | invoke 187 +-----------+ +--------+ +-------+ +----+ | | | +----+ +----+ | | | +----+ 188 |Source Addr| | | | | | | | | | | | | 189 +-----------+ +------------+ +--------------+ +-----+ | | | +------+ +------+ | | | +------+ 190 |VPN Info | |Overlay Tech| | Ing/Eg Nodes | | PIM | | | | | MPLS | | OSPF | | | | | PIM | 191 +-----------+ +------------+ +--------------+ +-----+ | | | +------+ +------+ | | | +------+ 192 |VNI Info | | MLD | |Ingress Nodes | +----+ | +-----+ +----+ | +-----+ 193 +-----------+ +------------+ +--------------+ | | | | | | 194 | MVPN | |Egress Nodes | +----------+ | +--------+ +-----+ | +------+ 195 +------------+ +--------------+ |Cisco Mode| | |BIER-TE | |BABEL| | | BGP | 196 | BGP | | relate +----------+ | +--------+ +-----+ | +------+ 197 +------------+ \|/ +----+ +----+ 198 |MLD-Snooping| +----------------+ | | 199 +------------+ | BIER Nodes Info| +------+ +------+ 200 +----------------+ | BIER | | ISIS | 201 | BFR-ID | +------+ +------+ 202 +----------------+ 204 Figure 2: UML like Class Diagram for Multicast YANG data Model 206 4. Model Structure 208 module: ietf-multicast-model 209 +--rw multicast-model 210 +--rw multicast-keys* [vpn-rd source-address group-address vni-type vni-value] 211 +--rw vpn-rd rt-types:route-distinguisher 212 +--rw source-address ip-multicast-source-address 213 +--rw group-address rt-types:ip-multicast-group-address 214 +--rw vni-type virtual-type 215 +--rw vni-value uint32 216 +--rw multicast-overlay 217 | +--rw ingress-egress 218 | | +--rw ingress-node? inet:ip-address 219 | | +--rw egress-nodes* [egress-node] 220 | | +--rw egress-node inet:ip-address 221 | +--rw bier-ids 222 | | +--rw sub-domain? bier:sub-domain-id 223 | | +--rw ingress-node? bier:bfr-id 224 | | +--rw egress-nodes* [egress-node] 225 | | +--rw egress-node bier:bfr-id 226 | +--rw overlay-tech-type? enumeration 227 +--rw multicast-transport 228 | +--rw bier 229 | | +--rw sub-domain? bier:sub-domain-id 230 | | +--rw (encap-type)? 231 | | | +--:(mpls) 232 | | | +--:(eth) 233 | | | +--:(ipv6) 234 | | +--rw bitstringlength? bier:bsl 235 | | +--rw set-identifier? bier:si 236 | | +--rw ecmp? boolean 237 | | +--rw frr? boolean 238 | +--rw bier-te 239 | | +--rw sub-domain? bier:sub-domain-id 240 | | +--rw (encap-type)? 241 | | | +--:(mpls) 242 | | | +--:(non-mpls) 243 | | +--rw bitstringlength? bier:bsl 244 | | +--rw set-identifier? bier:si 245 | | +--rw ecmp? boolean 246 | | +--rw frr? boolean 247 | +--rw cisco-mode 248 | | +--rw p-group? rt-types:ip-multicast-group-address 249 | | +--rw graceful-restart? boolean 250 | | +--rw bfd? boolean 251 | +--rw mpls 252 | | +--rw (mpls-tunnel-type)? 253 | | +--:(mldp) 254 | | | +--rw mldp-tunnel-id? uint32 255 | | | +--rw mldp-frr? boolean 256 | | | +--rw mldp-backup-tunnel? boolean 257 | | +--:(p2mp-te) 258 | | +--rw te-tunnel-id? uint32 259 | | +--rw te-frr? boolean 260 | | +--rw te-backup-tunnel? boolean 261 | +--rw pim 262 | +--rw graceful-restart? boolean 263 | +--rw bfd? boolean 264 +--rw multicast-underlay 265 +--rw underlay-requirement? boolean 266 +--rw bgp 267 +--rw ospf 268 | +--rw topology-id? uint8 269 +--rw isis 270 | +--rw topology-id? uint16 271 +--rw babel 273 notifications: 274 +---n head-end-event 275 +--ro event-type? enumeration 276 +--ro multicast-key 277 | +--ro vpn-rd? rt-types:route-distinguisher 278 | +--ro source-address? ip-multicast-source-address 279 | +--ro group-address? rt-types:ip-multicast-group-address 280 | +--ro vni-type? virtual-type 281 | +--ro vni-value? uint32 282 +--ro overlay-tech-type? enumeration 283 +--ro transport-tech? enumeration 284 +--ro underlay-tech? enumeration 286 5. Multicast YANG data Model 288 file "ietf-multicast-model.yang" 289 module ietf-multicast-model { 291 yang-version 1.1; 293 namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model"; 294 prefix multicast-model; 296 import ietf-inet-types { 297 prefix "inet"; 298 reference "RFC6991"; 299 } 301 import ietf-routing-types { 302 prefix rt-types; 303 reference "RFC8294"; 304 } 306 import ietf-bier { 307 prefix bier; 308 } 310 organization " IETF MBONED( MBONE Deployment ) Working Group"; 311 contact 312 "WG List: 314 Editor: Zheng Zhang 315 316 Editor: Cui Wang 317 318 Editor: Ying Cheng 319 320 "; 322 description 323 "The module defines the YANG definitions for multicast service 324 management. 326 Copyright (c) 2018 IETF Trust and the persons 327 identified as authors of the code. All rights reserved. 329 Redistribution and use in source and binary forms, with or 330 without modification, is permitted pursuant to, and subject 331 to the license terms contained in, the Simplified BSD License 332 set forth in Section 4.c of the IETF Trust's Legal Provisions 333 Relating to IETF Documents 334 (http://trustee.ietf.org/license-info). 335 This version of this YANG module has relationship with overall multicast 336 technologies, such as PIM(RFC7761), BIER(RFC8279), MVPN(RFC6513), and so 337 on; see the RFC itself for full legal notices."; 339 revision 2018-02-22 { 340 description 341 "Initial revision."; 342 reference 343 "RFC XXXX: A YANG Data Model for multicast YANG. 344 RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): 345 Protocol Specification (Revised). 346 RFC 8279: Multicast Using Bit Index Explicit Replication (BIER); 347 RFC 6513: Multicast in MPLS/BGP IP VPNs"; 348 } 350 /*key*/ 352 typedef ip-multicast-source-address { 353 type union { 354 type rt-types:ipv4-multicast-source-address; 355 type rt-types:ipv6-multicast-source-address; 356 } 357 description 358 "This type represents a version-neutral IP multicast source 359 address. The format of the textual representation implies 360 the IP version."; 361 reference 362 "RFC8294: Common YANG Data Types for the Routing Area."; 363 } 365 typedef virtual-type { 366 type enumeration { 367 enum "vxlan" { 368 description "The vxlan type. See more detail in RFC7348."; 369 } 370 enum "virtual subnet" { 371 description "The nvgre type. See more detail in RFC7637."; 372 } 373 enum "vni" { 374 description "The geneve type. See more detail in [ietf-nvo3-geneve]."; 375 } 376 } 377 description "The collection of virtual network type."; 378 } 380 grouping general-multicast-key { 381 description "The general multicast keys. They are used to distinguish different multicast service."; 382 leaf vpn-rd { 383 type rt-types:route-distinguisher; 384 description "A Route Distinguisher used to distinguish routes from different MVPNs (RFC 6513)."; 385 reference 386 "RFC8294: Common YANG Data Types for the Routing Area."; 387 } 388 leaf source-address { 389 type ip-multicast-source-address; 390 description "The IPv4/IPv6 source address of multicast flow. The value set to zero means that the receiver interests in all source that relevant to one given group."; 391 } 392 leaf group-address { 393 type rt-types:ip-multicast-group-address; 394 description "The IPv4/IPv6 group address of multicast flow. This type represents a version-neutral IP multicast group address. The format of the textual representation implies the IP version."; 395 reference 396 "RFC8294: Common YANG Data Types for the Routing Area."; 397 } 398 leaf vni-type { 399 type virtual-type; 400 description "The type of virtual network identifier. Includes the Vxlan, NVGRE and Geneve. This value and vni-value is used to indicate a specific virtual multicast service."; 401 } 402 leaf vni-value { 403 type uint32; 404 description "The value of Vxlan network identifier, virtual subnet ID or virtual net identifier. This value and vni-type is used to indicate a specific virtual multicast service."; 405 } 406 } 408 /*overlay*/ 410 grouping overlay-technology { 411 leaf overlay-tech-type { 412 type enumeration { 413 enum mld { 414 description "MLD technology is used for multicast overlay. See more detail in [draft-ietf-bier-mld]"; 415 } 416 enum mvpn { 417 description "MVPN technology is used for multicast overlay. See more detail in RFC6513."; 419 } 420 enum bgp { 421 description "BGP technology is used for multicast overlay. See more detail in RFC7716."; 422 } 423 enum mld-snooping { 424 description "MLD snooping technology is used for multicast overlay. See more detail in RFC4541."; 425 } 426 } 427 description "The possible overlay technologies for multicast service."; 428 } 429 description "The possible overlay technologies for multicast service."; 430 } 432 grouping multicast-overlay { 433 description "The multicast overlay information, includes ingress node and egress nodes' information."; 434 container ingress-egress { 435 description "The ingress and egress nodes address collection."; 436 leaf ingress-node { 437 type inet:ip-address; 438 description "The ip address of ingress node for one or more multicast flow. 439 Or the ingress node of MVPN and BIER. In MVPN, this is the address of ingress 440 PE; in BIER, this is the BFR-prefix of ingress nodes."; 441 } 443 list egress-nodes { 444 key "egress-node"; 445 description "The egress multicast nodes of multicast flow. 446 Or the egress node of MVPN and BIER. In MVPN, this is the 447 address of egress PE; in BIER, this is the BFR-prefix of 448 ingress nodes."; 450 leaf egress-node { 451 type inet:ip-address; 452 description 453 "The ip-address of egress multicast nodes. See more details in RFC6513."; 454 } 455 } 456 } 458 container bier-ids { 459 description "The BFR-ids of ingress and egress BIER nodes for one or more multicast flows."; 460 leaf sub-domain { 461 type bier:sub-domain-id; 462 description "The sub-domain that this multicast flow belongs to. See more details in RFC8279."; 463 } 464 leaf ingress-node { 465 type bier:bfr-id; 466 description "The ingress node of multicast flow. This is the 467 BFR-id of ingress nodes. See more details in RFC8279."; 468 } 469 list egress-nodes { 470 key "egress-node"; 471 description "This ID information of one adjacency. See more details in RFC8279."; 473 leaf egress-node { 474 type bier:bfr-id; 475 description "The BFR-ids of egress multicast BIER nodes. See more details in RFC8279."; 476 } 477 } 478 } 480 uses overlay-technology; 481 } 483 /*transport*/ 485 grouping transport-pim { 486 description "The requirement information of pim transportion. PIM protocol is defined in RFC7761."; 487 leaf graceful-restart { 488 type boolean; 489 description "If the graceful restart function should be supported."; 490 } 491 leaf bfd { 492 type boolean; 493 description "If the bfd function should be supported."; 494 } 495 } 497 grouping multicast-transport { 498 description "The transport information of multicast service."; 499 container bier { 500 description "The transport technology is BIER. The BIER technology is introduced in RFC8279. The parameter is consistent with the definition in [ietf-bier-bier-yang]."; 501 leaf sub-domain { 502 type bier:sub-domain-id; 503 description "The subdomain id that the multicast flow belongs to. See more details in RFC8279."; 504 } 505 choice encap-type { 506 case mpls { 507 description "The BIER forwarding depends on mpls. See more details in RFC8296."; 508 } 509 case eth { 510 description "The BIER forwarding depends on ethernet. See more details in RFC8296."; 511 } 512 case ipv6 { 513 description "The BIER forwarding depends on IPv6."; 515 } 516 description "The encapsulation type in BIER."; 517 } 518 leaf bitstringlength { 519 type bier:bsl; 520 description "The bitstringlength used by BIER forwarding. See more details in RFC8279."; 521 } 522 leaf set-identifier { 523 type bier:si; 524 description "The set identifier used by the multicast flow. See more details in RFC8279."; 525 } 526 leaf ecmp { 527 type boolean; 528 description "The capability of ECMP. If this value is set to true, ecmp mechanism should be enabled. See more details in RFC8279."; 529 } 530 leaf frr { 531 type boolean; 532 description "The capability of fast re-route. If this value is set to true, fast re-route mechanism should be enabled. See more details in RFC8279."; 533 } 534 } 535 container bier-te { 536 description "The transport technology is BIER-TE. BIER-TE technology is introduced in [ietf-bier-te-arch]."; 537 leaf sub-domain { 538 type bier:sub-domain-id; 539 description "The subdomain id that the multicast flow belongs to. See more details in [ietf-bier-te-arch]."; 540 } 541 choice encap-type { 542 case mpls { 543 description "The BIER-TE forwarding depends on mpls. See more details in [ietf-bier-te-arch]."; 544 } 545 case non-mpls { 546 description "The BIER-TE forwarding depends on non-mpls. See more details in [ietf-bier-te-arch]."; 547 } 548 description "The encapsulation type in BIER-TE."; 549 } 550 leaf bitstringlength { 551 type bier:bsl; 552 description "The bitstringlength used by BIER-TE forwarding. See more details in [ietf-bier-te-arch]."; 553 } 554 leaf set-identifier { 555 type bier:si; 556 description "The set identifier used by the multicast flow, especially in BIER TE. See more details in [ietf-bier-te-arch]."; 557 } 558 leaf ecmp { 559 type boolean; 560 description "The capability of ECMP. If this value is set to true, ecmp mechanism should be enabled. See more details in [ietf-bier-te-arch]."; 561 } 562 leaf frr { 563 type boolean; 564 description "The capability of fast re-route. If this value is set to true, fast re-route mechanism should be enabled. See more details in [ietf-eckert-bier-te-frr]."; 565 } 566 } 567 container cisco-mode { 568 description "The transport technology is cisco-mode. The Cisco MDT multicast mechanism is defined in RFC6037."; 569 leaf p-group { 570 type rt-types:ip-multicast-group-address; 571 description "The address of p-group. It is used to encapsulate and forward flow according to multicast tree from ingress node to egress nodes."; 572 } 573 uses transport-pim; 574 } 575 container mpls { 576 description "The transport technology is mpls. MVPN overlay can use mpls tunnel technologies to build transport layer. The usage is introduced in RFC6513."; 577 choice mpls-tunnel-type { 578 case mldp { 579 description "The mldp tunnel. The protocol detail is defined in RFC6388."; 580 leaf mldp-tunnel-id { 581 type uint32; 582 description "The tunnel id that correspond this flow. The detail is defined in RFC6388."; 583 } 584 leaf mldp-frr { 585 type boolean; 586 description "If the fast re-route function should be supported. The detail is defined in RFC6388."; 587 } 588 leaf mldp-backup-tunnel { 589 type boolean; 590 description "If the backup tunnel function should be supported. The detail is defined in RFC6388."; 591 } 592 } 593 case p2mp-te { 594 description "The p2mp te tunnel. The protocol detail is defined in RFC4875."; 595 leaf te-tunnel-id { 596 type uint32; 597 description "The tunnel id that correspond this flow. The detail is defined in RFC4875."; 598 } 599 leaf te-frr { 600 type boolean; 601 description "If the fast re-route function should be supported. The detail is defined in RFC4875."; 602 } 603 leaf te-backup-tunnel { 604 type boolean; 605 description "If the backup tunnel function should be supported. The detail is defined in RFC4875."; 606 } 607 } 608 description "The collection types of mpls tunnels"; 609 } 610 } 611 container pim { 612 uses transport-pim; 613 description "The transport technology is PIM. PIM [RFC7761] is used commonly in traditional network."; 614 } 615 } 617 /*underlay*/ 619 grouping multicast-underlay { 620 description "The underlay information relevant multicast service. Underlay protocols are used to build transport layer. It is unnecessary in traditional network that use PIM [RFC7761] to build multicast tree. Diversity underlay protocols can be choosed to build BIER transport layer."; 621 leaf underlay-requirement { 622 type boolean; 623 description "If the underlay technology is required."; 624 } 625 container bgp { 626 description "The underlay technology is BGP. BGP protocol RFC4271 should be triggered to run if BGP is used as underlay protocol."; 627 } 628 container ospf { 629 description "The underlay technology is OSPF. OSPF protocol RFC2328 should be triggered to run if OSPF is used as underlay protocol."; 630 leaf topology-id { 631 type uint8; 632 description "The topology id of ospf instance. The topology id can be assigned In some situations. More details is defined in RFC2328."; 633 } 634 } 635 container isis { 636 description "The underlay technology is ISIS. ISIS protocol should be triggered to run if ISIS is used as underlay protocol. Details is defined in RFC1195."; 637 leaf topology-id { 638 type uint16; 639 description "The topology id of isis instance. The topology id can be assigned In some situations."; 640 } 641 } 642 container babel { 643 description "The underlay technology is Babel. Babel protocol should be triggered to run if Babel is used as underlay protocol."; 644 } 645 } 647 container multicast-model { 648 description "The model of multicast YANG data. Include keys, overlay, transport and underlay."; 650 list multicast-keys{ 651 key "vpn-rd source-address group-address vni-type vni-value"; 652 uses general-multicast-key; 654 container multicast-overlay { 655 description "The overlay information of multicast service. Overlay technology is used to exchange multicast flows information. Overlay technology may not be used in SDN controlled completely situation, but it can be used in partial SDN controlled situation or non-SDN controlled situation. Different overlay technology can be choosed according to different deploy consideration."; 656 uses multicast-overlay; 657 } 658 container multicast-transport { 659 description "The transportion of multicast service. Transport protocol is responsible for delivering multicast flows from ingress nodes to egress nodes with or without specific encapsulation. Different transport technology can be choosed according to different deploy consideration. Once a transport technology is choosed, associated protocol should be triggered to run."; 660 uses multicast-transport; 661 } 662 container multicast-underlay { 663 description "The underlay of multicast service. Underlay protocol is used to build transport layer. Underlay protocol need not be assigned in ordinary network since existed underlay protocol fits well, but it can be assigned in particular networks for better controlling. Once a underlay technology is choosed, associated protocol should be triggered to run."; 664 uses multicast-underlay; 665 } 666 description "The model of multicast YANG data. Include keys, overlay, transport and underlay."; 667 } 668 } 670 /*Notifications*/ 672 notification head-end-event { 673 leaf event-type { 674 type enumeration { 675 enum down { 676 description "There is something wrong with head end node, and head end node can't work properlay."; 677 } 678 enum module-loaded { 679 description "Some new modules that can be used by multicast flows finish loading."; 680 } 681 enum module-unloaded { 682 description "Some new modules that can be used by multicast flows have been unloaded."; 683 } 684 } 685 description "Event type."; 686 } 687 container multicast-key { 688 uses general-multicast-key; 689 description "The associated multicast keys that are influenced by head end node failer."; 690 } 691 uses overlay-technology; 693 leaf transport-tech { 694 type enumeration { 695 enum bier { 696 description "BIER(RFC8279) technology can be used to forward multicast flows."; 697 } 698 enum bier-te { 699 description "BIER-TE(draft-ietf-bier-te-arch) technology can be used to forward multicast flows."; 700 } 701 enum cisco-mode { 702 description "Cisco mode(RFC6037) technology can be used to forward multicast flows."; 703 } 704 enum mldp { 705 description "MLDP(RFC6388) technology can be used to forward multicast flows."; 706 } 707 enum p2mp-te { 708 description "P2MP TE(RFC4875) technology can be used to forward multicast flows."; 709 } 710 enum pim { 711 description "PIM(RFC7761) technology can be used to forward multicast flows."; 712 } 713 } 714 description "The modules can be used to forward multicast flows."; 715 } 716 leaf underlay-tech { 717 type enumeration { 718 enum bgp { 719 description "BGP protocol can be used to build multicast transport layer."; 720 } 721 enum ospf { 722 description "OSPF protocol can be used to build multicast transport layer."; 723 } 724 enum isis { 725 description "ISIS protocol can be used to build multicast transport layer."; 726 } 727 enum babel { 728 description "Babel protocol can be used to build multicast transport layer."; 729 } 730 } 731 description "The modules can be used to build multicast transport layer."; 732 } 733 description "Notification events for the head end nodes. Like head node failer, overlay/ transport/ underlay module loading/ unloading. And the potential failer about some multicast flows and associated overlay/ transport/ underlay technologies."; 734 } 735 } 736 738 6. Notifications 740 The defined Notifications include the events of head end nodes. Like 741 head node failer, overlay/ transport/ underlay module loading/ 742 unloading. And the potential failer about some multicast flows and 743 associated overlay/ transport/ underlay technologies. 745 7. Acknowledgements 747 The authors would like to thank Stig Venaas, Jake Holland for their 748 valuable comments and suggestions. 750 8. Normative References 752 [I-D.ietf-bier-bier-yang] 753 Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d., 754 and M. Sivakumar, "YANG Data Model for BIER Protocol", 755 draft-ietf-bier-bier-yang-03 (work in progress), February 756 2018. 758 [I-D.ietf-bier-te-arch] 759 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 760 Engineering for Bit Index Explicit Replication (BIER-TE)", 761 draft-ietf-bier-te-arch-00 (work in progress), January 762 2018. 764 [I-D.ietf-pim-yang] 765 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 766 Y., and f. hu, "A YANG data model for Protocol-Independent 767 Multicast (PIM)", draft-ietf-pim-yang-13 (work in 768 progress), January 2018. 770 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 771 the Network Configuration Protocol (NETCONF)", RFC 6020, 772 DOI 10.17487/RFC6020, October 2010, 773 . 775 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 776 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 777 RFC 6037, DOI 10.17487/RFC6037, October 2010, 778 . 780 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 781 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 782 January 2011, . 784 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 785 and A. Bierman, Ed., "Network Configuration Protocol 786 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 787 . 789 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 790 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 791 2012, . 793 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 794 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 795 . 797 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", 798 RFC 7277, DOI 10.17487/RFC7277, June 2014, 799 . 801 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 802 Management", RFC 8022, DOI 10.17487/RFC8022, November 803 2016, . 805 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 806 Zhang, "YANG Data Model for Key Chains", RFC 8177, 807 DOI 10.17487/RFC8177, June 2017, 808 . 810 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 811 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 812 Explicit Replication (BIER)", RFC 8279, 813 DOI 10.17487/RFC8279, November 2017, 814 . 816 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 817 "Common YANG Data Types for the Routing Area", RFC 8294, 818 DOI 10.17487/RFC8294, December 2017, 819 . 821 Authors' Addresses 823 Zheng Zhang 824 ZTE Corporation 825 No. 50 Software Ave, Yuhuatai Distinct 826 Nanjing 827 China 829 Email: zhang.zheng@zte.com.cn 831 Cui(Linda) Wang 832 ZTE Corporation 833 No. 50 Software Ave, Yuhuatai Distinct 834 Nanjing 835 China 837 Email: lindawangjoy@gmail.com 839 Ying Cheng 840 China Unicom 841 Beijing 842 China 844 Email: chengying10@chinaunicom.cn