draft-ietf-mboned-multicast-yang-model-02.txt   draft-ietf-mboned-multicast-yang-model-03.txt 
MBONED WG Zheng. Zhang MBONED WG Z. Zhang
Internet-Draft Cui. Wang Internet-Draft ZTE Corporation
Intended status: Standards Track ZTE Corporation Intended status: Standards Track C. Wang
Expires: March 15, 2020 Ying. Cheng Expires: September 8, 2020 Individual
Y. Cheng
China Unicom China Unicom
Xufeng. Liu X. Liu
Volta Networks Volta Networks
Mahesh. Sivakumar M. Sivakumar
Juniper networks Juniper networks
September 12, 2019 March 7, 2020
Multicast YANG Data Model Multicast YANG Data Model
draft-ietf-mboned-multicast-yang-model-02 draft-ietf-mboned-multicast-yang-model-03
Abstract Abstract
This document intents to provide a general and all-round multicast This document provides a general multicast YANG data model, which
YANG data model, which tries to stand at a high level to take full takes full advantages of existed multicast protocol models to control
advantages of existed multicast protocol models to control the the multicast network, and guides the deployment of multicast
multicast network, and guides the deployment of multicast service. service.
And also, there will define several possible RPCs about how to
interact between multicast YANG data model and multicast protocol
models. This multicast YANG data model is mainly used by the
management tools run by the network operators in order to manage,
monitor and debug the network resources used to deliver multicast
service, as well as gathering some data from the network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2020. This Internet-Draft will expire on September 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design of the multicast model . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. UML Class like Diagram for Multicast YANG data Model . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
5. Multicast YANG data Model . . . . . . . . . . . . . . . . . . 7 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 20 1.5. Usage of Multicast Model . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 2. Design of the multicast model . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 20 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 7
3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 7
3.1. UML like Class Diagram for Multicast YANG data Model . . 7
3.2. Model Structure . . . . . . . . . . . . . . . . . . . . . 9
3.3. Multicast YANG data model Configuration . . . . . . . . . 12
3.4. Multicast YANG data model State . . . . . . . . . . . . . 12
3.5. Multicast YANG data model Notification . . . . . . . . . 12
4. Multicast YANG data Model . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Currently, there are many multicast protocol YANG models, such as Currently, there are many multicast protocol YANG models, such as
PIM, MLD, and BIER and so on. But all these models are distributed PIM, MLD, and BIER and so on. But all these models are distributed
in different working groups as separate files and focus on the in different working groups as separate files and focus on the
protocol itself. Furthermore, they cannot describe a high-level protocol itself. Furthermore, they cannot describe a high-level
multicast service required by network operators. multicast service required by network operators.
This document intents to provide a general and all-round multicast This document provides a general and all-round multicast model, which
model, which tries to stand at a high level to take full advantages stands at a high level to take full advantages of these
of these aforementioned models to control the multicast network, and aforementioned models to control the multicast network, and guide the
guides the deployment of multicast service. deployment of multicast service.
This model is designed to be used along with other multicast YANG
models such as PIM [I-D.ietf-pim-yang], which are not covered in this
document.
1.1. Terminology
The terminology for describing YANG data models is found in [RFC6020]
and [RFC7950], including:
o augment
o data model
o data node
o identity
o module
The following abbreviations are used in this document and the defined
model:
BIER: Bit Index Explicit Replication [RFC8279].
MLD: Multicast Listener Discovery [I-D.ietf-bier-mld].
PIM: Protocol Independent Multicast [RFC7761].
BGP: Border Gateway Protocol [RFC4271].
MVPN: Multicast in MPLS/BGP IP VPNs [RFC6513].
MLDP: Label Distribution Protocol Extensions for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths [RFC6388].
OSPF: Open Shortest Path First [RFC2328].
ISIS: Intermediate System to Intermediate System Routeing Exchange
Protocol [RFC1195].
BABEL: [I-D.ietf-babel-rfc6126bis].
P2MP-TE: Point-to-Multipoint Traffic Engineering [RFC4875].
BIER-TE: Traffic Engineering for Bit Index Explicit Replication
[I-D.ietf-bier-te-arch].
1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Tree Diagrams
Tree diagrams used in this document follow the notation defined in
[RFC8340].
1.4. Prefixes in Data Node Names
In this document, names of data nodes, actions, and other data model
objects are often used without a prefix, as long as it is clear from
the context in which YANG module each name is defined. Otherwise,
names are prefixed using the standard prefix associated with the
corresponding YANG module, as shown in Table 1.
+----------+--------------------+----------------------+
| Prefix | YANG module | Reference |
+----------+--------------------+----------------------+
| inet | ietf-inet-types | [RFC6991] |
| | | |
| rt-types | ietf-routing-types | [RFC8294] |
| | | |
| rt | ietf-routing | [RFC8349] |
| | | |
| ospf | ietf-ospf | [I-D.ietf-ospf-yang] |
+----------+--------------------+----------------------+
Table 1
1.5. Usage of Multicast Model
This multicast YANG data model is mainly used by the management tools This multicast YANG data model is mainly used by the management tools
run by the network operators in order to manage, monitor and debug run by the network operators, in order to manage, monitor and debug
the network resources used to deliver multicast service, as well as the network resources which are used to deliver multicast service.
gathering some data from the network. This model is used for gathering data from the network as well.
+------------------------+ +------------------------+
| Multicast Model | | Multicast Model |
+------------------------+ +------------------------+
| | | | | |
| | | | | |
| +---------+ +----------+ | +---------+ +----------+
| | EMS/NMS | |Controller| | | EMS/NMS | |Controller|
| +---------+ +----------+ | +---------+ +----------+
| | | | | |
| | | | | |
+------------------------------------------------+ +------------------------------------------------+
| Network Element1.....N | | Network Element1.....N |
+------------------------------------------------+ +------------------------------------------------+
Figure 1: Example usage of Multicast Model Figure 1: Usage of Multicast Model
Detailly, in figure 1, there is an example of usage of this multicast Detailly, in figure 1, there is an example of usage of this multicast
model. Network operators can use this model in a controller who is model. Network operators can use this model in a controller which is
responsible to implement some multicast flows with specific protocols responsible to implement specific multicast flows with specific
and invoke the corresponding protocols' model to configure the protocols and invoke the corresponding protocols' model to configure
network elements through NETCONF/RESTCONF/CLI. Or network operators the network elements through NETCONF/RESTCONF/CLI. Or network
can use this model to the EMS/NMS to manage the network elements or operators can use this model to the EMS/NMS to manage the network
configure the network elements directly. For example, a multicast elements or configure the network elements directly.
service need to be delopy in a network, supposed that the multicast
flow is 239.0.0.0/8, the flow should be transport by BIER technology. +------------+
Then we use this multicast YANG data model and set the correspond key | +----------------------------+
(239.0.0.0) and associated transport technology with BIER, send the +--------------+ Controller | |
model from controller to every egde node in the network. Then there | | +-----------+ |
is an interaction among all the nodes to exchange the multicast flow | +------------+ | |
information. The ingress node will encapsulate the multicast flow | | |
with BIER header and send it into the network. Intermediate nodes | +-----------------------------+ | |
will forward the flows to all the egress nodes by BIER forwarding. | | | | |
| | +------+---+--+ |
| | |Egress router+--+ Receiver |
| | +------+------+ |
+---+-----+----+ | |
Source +-|Ingress router| BIER domain | |
+---------+----+ | |
| +------+------+ |
| |Egress router+--+ Receiver |
| +------+----+-+ |
| | | |
+-----------------------------+ +---------------+
Figure 2: Example
The network administrator can use the multicast model and associated
models to deploy the multicast service. For example, suppose that
the flow for a multicast service is 233.252.0.0/16, the flow should
be forwarded by BIER [RFC8279] with MPLS encapsulation [RFC8296].
Correspoding IGP protocol which is used to build BIER transport layer
is OSPF [RFC2328].
In this model, the correspond key is set to 233.252.0.0/16, the
transport technology is set to BIER. The BIER underlay protocol is
set to OSPF. The model is sent to every egde router from the
controller. If the BIER transport layer which depends on OSPF has
not been built in the network, the multicast YANG model will invoke
the BIER YANG model which is defined in [I-D.ietf-bier-bier-yang]
generation in the controller. After the BIER transport layer is
built, the ingress router encapsulates the multicast flow with BIER
header and sends it into the network. Intermediate routers forward
the flows to all the egress nodes by BIER forwarding.
On the other hand, when the network elements detect failure or some On the other hand, when the network elements detect failure or some
other changes, the network devices can send the affected multicast other changes, the network devices can send the affected multicast
flows and the associated overlay/ transport/ underlay information to flows and the associated overlay/ transport/ underlay information to
the controller. Then the controller/ EMS/NMS can response the controller. Then the controller/ EMS/NMS can response
immediately due to the failure and distribute new model for the flows immediately due to the failure and distribute new model for the flows
to the network nodes quickly. Such as the changing of the failure to the network nodes quickly. Such as the changing of the failure
overlay protocol to another one, as well as transport and underlay overlay protocol to another one, as well as transport and underlay
protocol. protocol.
skipping to change at page 4, line 12 skipping to change at page 6, line 45
fashion. Then, based on this UML like class diagram, there is fashion. Then, based on this UML like class diagram, there is
instantiated and detailed YANG model in Section 5. instantiated and detailed YANG model in Section 5.
In other words, this document does not define any specific protocol In other words, this document does not define any specific protocol
model, instead, it depends on many existed multicast protocol models model, instead, it depends on many existed multicast protocol models
and relates several multicast information together to fulfill and relates several multicast information together to fulfill
multicast service. multicast service.
2. Design of the multicast model 2. Design of the multicast model
2.1. Scope of Model
This model can be used to configure and manage Multicast service.
The operational state data can be retrieved by this model. The
subscription and push mechanism defined in [RFC8639] and [RFC8641]
can be implemented by the user to subscribe to notifications on the
data nodes in this model.
The model contains all the basic configuration parameters to operate
the model. Depending on the implementation choices, some systems may
not allow some of the advanced parameters to be configurable. The
occasionally implemented parameters are modeled as optional features
in this model. This model can be extended, and it has been
structured in a way that such extensions can be conveniently made.
2.2. Specification
The configuration data nodes cover configurations. The container
"multicast-model" is the top level container in this data model. The
presence of this container is expected to enable Multicast service
functionality. The notification includes the error reason and the
associated data nodes.
3. Module Structure
This model imports and augments the ietf-routing YANG model defined
in [RFC8349]. Both configuration data nodes and state data nodes of
[RFC8349] are augmented.
The YANG data model defined in this document conforms to the Network
Management Datastore Architecture (NMDA) [RFC8342]. The operational
state data is combined with the associated configuration data in the
same hierarchy [RFC8407].
3.1. UML like Class Diagram for Multicast YANG data Model
The following is a UML like diagram for Multicast YANG data Model.
+-----------+
+-----+Multi|keys |
| +-----------+
| |Group Addr |
| +-----------+
| |Source Addr| +--------+-----------------+
| +-----------+ | | |
| |VPN Info | | | +------+-------+
| +-----------+ | +-----+------+ | Ing/Eg Nodes |
| |VNI Info | | |Overlay Tech| +--------------+
| +-----------+ | +------------+ |Ingress Nodes |
| | | MLD | +--------------+
| | +------------+ |Egress Nodes |
| Contain | | MVPN | +-------+------+
| +-----------+ | +------------+ | relate
| | Multicast +----+ | BGP | \|/
+-----+ Overlay | +------------+ +----------------+
| | | |MLD|Snooping| | BIER Nodes Info|
| +-----------+ +------------+ +----------------+
| | BFR|ID |
| +----------------+
|
+--------+--+ +---------------+----------+----------+
| Multicast |Contain | | | |
| Model | | +--+---+ +---+----+ +--+---+
+--------+--+ | | MPLS | |BIER|TE | | BIER |
| +---------+--+ +------+ +--------+ +------+
| | Multicast |
+----+ Transport | invoke +-----+ +----------+
| | | | PIM | |Cisco Mode|
| +---------+--+ +--+--+ +----+-----+
| | | |
| | | |
| +---------------+-----------+
|
| +--------------+---------+---------+
| | | | |
| | +--+---+ +--+---+ +--+--+
| +----------+-- | OSPF | | PIM | |BABEL|
| | Multicast | +------+ +------+ +-----+
+----+ Underlay | invoke
| | +------+ +------+
+----------+-- | ISIS | | BGP |
| +--+---+ +--+---+
| | |
+--------------+---------+
Figure 3: UML like Class Diagram for Multicast YANG data Model
3.2. Model Structure
module: ietf-multicast-model
+--rw multicast-model
+--rw multicast-keys* [vpn-rd source-address group-address
vni-type vni-value]
+--rw vpn-rd rt-types:route-distinguisher
+--rw source-address ip-multicast-source-address
+--rw group-address
rt-types:ip-multicast-group-address
+--rw vni-type virtual-type
+--rw vni-value uint32
+--rw multicast-overlay
| +--rw ingress-egress
| | +--rw ingress-node? inet:ip-address
| | +--rw egress-nodes* [egress-node]
| | +--rw egress-node inet:ip-address
| +--rw bier-ids
| | +--rw sub-domain? uint16
| | +--rw ingress-node? uint16
| | +--rw egress-nodes* [egress-node]
| | +--rw egress-node uint16
| +--rw (overlay-tech-type)?
| +--:(bgp)
| +--:(evpn)
| +--:(mld)
| | +--rw mld-instance-group?
rt-types:ip-multicast-group-address
| +--:(mld-snooping)
| +--:(mvpn)
| +--:(pim)
+--rw multicast-transport
| +--rw (transport)?
| +--:(bier)
| | +--rw bier
| | +--rw sub-domain? uint16
| | +--rw bitstringlength? uint16
| | +--rw set-identifier? uint16
| | +--rw (encap-type)?
| | +--:(mpls)
| | +--:(eth)
| | +--:(ipv6)
| +--:(bier-te)
| | +--rw bier-te
| | +--rw sub-domain? uint16
| | +--rw bitstringlength? uint16
| | +--rw set-identifier? uint16
| | +--rw (encap-type)?
| | | +--:(mpls)
| | | +--:(eth)
| | | +--:(ipv6)
| | +--rw bier-te-adj* uint16
| +--:(cisco-mode)
| | +--rw cisco-mode
| | +--rw p-group?
rt-types:ip-multicast-group-address
| +--:(mpls)
| | +--rw mpls
| | +--rw (mpls-tunnel-type)?
| | +--:(mldp)
| | | +--rw mldp-tunnel-id? uint32
| | | +--rw mldp-backup-tunnel? boolean
| | +--:(p2mp-te)
| | +--rw te-tunnel-id? uint32
| | +--rw te-backup-tunnel? boolean
| +--:(pim)
| +--rw pim
+--rw multicast-underlay
+--rw (underlay)?
+--:(bgp)
+--:(ospf)
| +--rw ospf
| +--rw topology?
-> /rt:routing/control-plane-protocols
/control-plane-protocol/ospf:ospf
/topologies/topology/name
+--:(isis)
+--:(babel)
notifications:
+---n head-end-event
+--ro event-type? enumeration
+--ro multicast-key
| +--ro vpn-rd? rt-types:route-distinguisher
| +--ro source-address? ip-multicast-source-address
| +--ro group-address? rt-types:ip-multicast-group-address
| +--ro vni-type? virtual-type
| +--ro vni-value? uint32
+--ro (overlay-tech-type)?
| +--:(bgp)
| +--:(evpn)
| +--:(mld)
| | +--ro mld-instance-group?
rt-types:ip-multicast-group-address
| +--:(mld-snooping)
| +--:(mvpn)
| +--:(pim)
+--ro transport-tech
| +--ro (transport)?
| +--:(bier)
| | +--ro bier
| | +--ro sub-domain? uint16
| | +--ro bitstringlength? uint16
| | +--ro set-identifier? uint16
| | +--ro (encap-type)?
| | +--:(mpls)
| | +--:(eth)
| | +--:(ipv6)
| +--:(bier-te)
| | +--ro bier-te
| | +--ro sub-domain? uint16
| | +--ro bitstringlength? uint16
| | +--ro set-identifier? uint16
| | +--ro (encap-type)?
| | | +--:(mpls)
| | | +--:(eth)
| | | +--:(ipv6)
| | +--ro bier-te-adj* uint16
| +--:(cisco-mode)
| | +--ro cisco-mode
| | +--ro p-group? rt-types:ip-multicast-group-address
| +--:(mpls)
| | +--ro mpls
| | +--ro (mpls-tunnel-type)?
| | +--:(mldp)
| | | +--ro mldp-tunnel-id? uint32
| | | +--ro mldp-backup-tunnel? boolean
| | +--:(p2mp-te)
| | +--ro te-tunnel-id? uint32
| | +--ro te-backup-tunnel? boolean
| +--:(pim)
| +--ro pim
+--ro underlay-tech
+--ro (underlay)?
+--:(bgp)
+--:(ospf)
| +--ro ospf
| +--ro topology?
-> /rt:routing/control-plane-protocols
/control-plane-protocol/ospf:ospf
/topologies/topology/name
+--:(isis)
+--:(babel)
3.3. Multicast YANG data model Configuration
This model is used with other protocol data model to provide
multicast service.
This model includes multicast service keys and three layers: the This model includes multicast service keys and three layers: the
multicast overlay, the transport layer and the multicast underlay multicast overlay, the transport layer and the multicast underlay
information. Multicast keys include the features of multicast flow, information. Multicast keys include the features of multicast flow,
such as(vpnid, multicast source and multicast group) information. In such as(vpnid, multicast source and multicast group) information. In
data center network, for fine-grained to gather the nodes belonging data center network, for fine-grained to gather the nodes belonging
to the same virtual network, there may need VNI-related information to the same virtual network, there may need VNI-related information
to assist. to assist.
Multicast overlay defines (ingress-node, egress-nodes) nodes Multicast overlay defines (ingress-node, egress-nodes) nodes
information. If the transport layer is BIER, there may define BIER information. If the transport layer is BIER, there may define BIER
skipping to change at page 4, line 42 skipping to change at page 12, line 40
multicast YANG data model can invoke the corresponding protocol model multicast YANG data model can invoke the corresponding protocol model
to define them. to define them.
Multicast underlay defines the type of underlay technologies, such as Multicast underlay defines the type of underlay technologies, such as
OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay OSPF, ISIS, BGP, PIM or BABEL and so on. One or several underlay
technologies could be defined at the same time if there is protective technologies could be defined at the same time if there is protective
requirement. As for the specific parameters for each underlay requirement. As for the specific parameters for each underlay
technology, this multicast YANG data model can depend the technology, this multicast YANG data model can depend the
corresponding protocol model to configure them as well. corresponding protocol model to configure them as well.
3. UML Class like Diagram for Multicast YANG data Model The configuration modeling branch is composed of the keys, overlay
layer, transport layer and underlay layer.
The following is a UML like diagram for Multicast YANG data Model.
+-------------------+ 3.4. Multicast YANG data model State
| Multicast Model |
+-------------------+
| | | |Contain
+-----------------------------------------+ | | |
| +----------------- -+ | +---------------------------+
| | | |
+-----------+ +-------------------+ +----------------------+ +--------------------+
|Multi-keys | | Multicast Overlay | | Multicast Transport | | Multicast Underlay |
+-----------+ +-------------------+ +----------------------+ +--------------------+
|Group Addr | | |Contain | | | | | invoke | | | | | invoke
+-----------+ +--------+ +-------+ +----+ | | | +----+ +----+ | | | +----+
|Source Addr| | | | | | | | | | | | |
+-----------+ +------------+ +--------------+ +-----+ | | | +------+ +------+ | | | +------+
|VPN Info | |Overlay Tech| | Ing/Eg Nodes | | PIM | | | | | MPLS | | OSPF | | | | | PIM |
+-----------+ +------------+ +--------------+ +-----+ | | | +------+ +------+ | | | +------+
|VNI Info | | MLD | |Ingress Nodes | +----+ | +-----+ +----+ | +-----+
+-----------+ +------------+ +--------------+ | | | | | |
| MVPN | |Egress Nodes | +----------+ | +--------+ +-----+ | +------+
+------------+ +--------------+ |Cisco Mode| | |BIER-TE | |BABEL| | | BGP |
| BGP | | relate +----------+ | +--------+ +-----+ | +------+
+------------+ \|/ +----+ +----+
|MLD-Snooping| +----------------+ | |
+------------+ | BIER Nodes Info| +------+ +------+
+----------------+ | BIER | | ISIS |
| BFR-ID | +------+ +------+
+----------------+
Figure 2: UML like Class Diagram for Multicast YANG data Model Multicast model states are the same with the configuration.
4. Model Structure 3.5. Multicast YANG data model Notification
module: ietf-multicast-model The defined Notifications include the events of head end nodes. Like
+--rw multicast-model head node failer, overlay/ transport/ underlay module loading/
+--rw multicast-keys* [vpn-rd source-address group-address vni-type vni-value] unloading. And the potential failer about some multicast flows and
+--rw vpn-rd rt-types:route-distinguisher associated overlay/ transport/ underlay technologies.
+--rw source-address ip-multicast-source-address
+--rw group-address rt-types:ip-multicast-group-address
+--rw vni-type virtual-type
+--rw vni-value uint32
+--rw multicast-overlay
| +--rw ingress-egress
| | +--rw ingress-node? inet:ip-address
| | +--rw egress-nodes* [egress-node]
| | +--rw egress-node inet:ip-address
| +--rw bier-ids
| | +--rw sub-domain? uint16
| | +--rw ingress-node? uint16
| | +--rw egress-nodes* [egress-node]
| | +--rw egress-node uint16
| +--rw overlay-tech-type? enumeration
+--rw multicast-transport
| +--rw bier
| | +--rw sub-domain? uint16
| | +--rw (encap-type)?
| | | +--:(mpls)
| | | +--:(eth)
| | | +--:(ipv6)
| | +--rw bitstringlength? uint16
| | +--rw set-identifier? uint16
| | +--rw ecmp? boolean
| | +--rw frr? boolean
| +--rw bier-te
| | +--rw sub-domain? uint16
| | +--rw (encap-type)?
| | | +--:(mpls)
| | | +--:(non-mpls)
| | +--rw bitstringlength? uint16
| | +--rw set-identifier? uint16
| | +--rw ecmp? boolean
| | +--rw frr? boolean
| +--rw cisco-mode
| | +--rw p-group? rt-types:ip-multicast-group-address
| | +--rw graceful-restart? boolean
| | +--rw bfd? boolean
| +--rw mpls
| | +--rw (mpls-tunnel-type)?
| | +--:(mldp)
| | | +--rw mldp-tunnel-id? uint32
| | | +--rw mldp-frr? boolean
| | | +--rw mldp-backup-tunnel? boolean
| | +--:(p2mp-te)
| | +--rw te-tunnel-id? uint32
| | +--rw te-frr? boolean
| | +--rw te-backup-tunnel? boolean
| +--rw pim
| +--rw graceful-restart? boolean
| +--rw bfd? boolean
+--rw multicast-underlay
+--rw underlay-requirement? boolean
+--rw bgp
+--rw ospf
| +--rw topology-id? uint8
+--rw isis
| +--rw topology-id? uint16
+--rw babel
notifications: 4. Multicast YANG data Model
+---n head-end-event
+--ro event-type? enumeration
+--ro multicast-key
| +--ro vpn-rd? rt-types:route-distinguisher
| +--ro source-address? ip-multicast-source-address
| +--ro group-address? rt-types:ip-multicast-group-address
| +--ro vni-type? virtual-type
| +--ro vni-value? uint32
+--ro overlay-tech-type? enumeration
+--ro transport-tech? enumeration
+--ro underlay-tech? enumeration
5. Multicast YANG data Model This module references [RFC1195], [RFC2328], [RFC4271], [RFC4541],
[RFC4875], [RFC5340], [RFC6037], [RFC6388], [RFC6513], [RFC6991],
[RFC7348], [RFC7432], [RFC7637], [RFC7716], [RFC7761], [RFC8279],
[RFC8294], [RFC8296], [RFC8343], [RFC8344], [RFC8349], [RFC8639],
[RFC8641], [I-D.ietf-pim-yang], [I-D.ietf-bier-bier-yang],
[I-D.ietf-bier-te-arch], [I-D.ietf-nvo3-geneve], [I-D.ietf-bier-mld],
[I-D.ietf-bess-evpn-bum-procedure-updates], [I-D.ietf-bier-evpn],
[I-D.zhang-bier-bierin6], [I-D.ietf-babel-rfc6126bis],
[I-D.ietf-bier-pim-signaling].
<CODE BEGINS> file "ietf-multicast-model.yang" <CODE BEGINS> file "ietf-multicast-model@2020-03-06.yang"
module ietf-multicast-model { module ietf-multicast-model {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model"; namespace "urn:ietf:params:xml:ns:yang:ietf-multicast-model";
prefix multicast-model; prefix multicast-model;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
reference "RFC6991"; reference
"RFC 6991: Common YANG Data Types";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix "rt-types";
reference "RFC8294"; reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
import ietf-routing {
prefix "rt";
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
}
import ietf-ospf {
prefix "ospf";
reference
"I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol";
} }
organization " IETF MBONED( MBONE Deployment ) Working Group"; organization " IETF MBONED (MBONE Deployment) Working Group";
contact contact
"WG List: <mailto:mboned@ietf.org> "WG List: <mailto:mboned@ietf.org>
Editor: Zheng Zhang Editor: Zheng Zhang
<mailto:zzhang_ietf@hotmail.com> <mailto:zzhang_ietf@hotmail.com>
Editor: Cui Wang
<mailto:lindawangjoy@gmail.com> Editor: Cui Wang
Editor: Ying Cheng <mailto:lindawangjoy@gmail.com>
<mailto:chengying10@chinaunicom.cn> Editor: Ying Cheng
Editor: Xufeng Liu <mailto:chengying10@chinaunicom.cn>
<mailto:xufeng.liu.ietf@gmail.com> Editor: Xufeng Liu
Editor: Mahesh Sivakumar <mailto:xufeng.liu.ietf@gmail.com>
<mailto:sivakumar.mahesh@gmail.com> Editor: Mahesh Sivakumar
"; <mailto:sivakumar.mahesh@gmail.com>
";
// RFC Ed.: replace XXXX with actual RFC number and remove
// this note
description description
"The module defines the YANG definitions for multicast service "The module defines the YANG definitions for multicast service
management. management.
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD
set forth in Section 4.c of the IETF Trust's Legal Provisions License set forth in Section 4.c of the IETF Trust's Legal
Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module has relationship with This version of this YANG module is part of RFC XXXX
overall multicast technologies, such as PIM(RFC7761), (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
BIER(RFC8279), MVPN(RFC6513), and so on; see the RFC itself itself for full legal notices.
for full legal notices.";
revision 2018-07-30 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
description 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
"Initial revision."; 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
reference are to be interpreted as described in BCP 14 (RFC 2119)
"RFC XXXX: A YANG Data Model for multicast YANG. (RFC 8174) when, and only when, they appear in all
RFC 7761: Protocol Independent Multicast - Sparse Mode (PIM-SM): capitals, as shown here.";
Protocol Specification (Revised).
RFC 8279: Multicast Using Bit Index Explicit Replication (BIER); revision 2020-03-06 {
RFC 6513: Multicast in MPLS/BGP IP VPNs"; description
"Initial revision.";
reference
"RFC XXXX: A YANG Data Model for multicast YANG.";
} }
/*key*/ /*
*typedef
*/
typedef ip-multicast-source-address { typedef ip-multicast-source-address {
type union { type union {
type rt-types:ipv4-multicast-source-address; type rt-types:ipv4-multicast-source-address;
type rt-types:ipv6-multicast-source-address; type rt-types:ipv6-multicast-source-address;
} }
description description
"This type represents a version-neutral IP multicast "This type represents a version-neutral IP multicast
source address. The format of the textual source address. The format of the textual
representation implies the IP version."; representation implies the IP version.";
reference reference
"RFC8294: Common YANG Data Types for the Routing Area."; "RFC8294: Common YANG Data Types for the Routing Area.";
} }
typedef virtual-type { typedef virtual-type {
type enumeration { type enumeration {
enum "vxlan" { enum vxlan {
description "The vxlan type. See more detail in RFC7348."; description
} "The VXLAN encapsulation is used for flow encapsulation.";
enum "virtual subnet" { reference
description "The nvgre type. See more detail in RFC7637."; "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
} A Framework for Overlaying Virtualized Layer 2 Networks
enum "vni" { over Layer 3 Networks.";
description
"The geneve type. See more detail in [ietf-nvo3-geneve].";
}
} }
description "The collection of virtual network type."; enum nvgre {
description
"The NVGRE encapsulation is used for flow encapsulation.";
reference
"RFC 7637: NVGRE: Network Virtualization Using Generic
Routing Encapsulation.";
}
enum geneve {
description
"The GENEVE encapsulation is used for flow encapsulation.";
reference
"I-D.ietf-nvo3-geneve: Geneve: Generic Network
Virtualization Encapsulation.";
}
}
description
"The encapsulation type used for the flow. In case the virtual
type is set, the associated vni-value should also be defined.";
} // virtual-type
/*
* Identities
*/
identity multicast-model {
base rt:control-plane-protocol;
description "Identity for the Multicast model.";
} }
grouping general-multicast-key { grouping general-multicast-key {
description "The general multicast keys. They are used to description
distinguish different multicast service."; "The general multicast keys. They are used to distinguish
leaf vpn-rd { different multicast service.";
type rt-types:route-distinguisher; leaf vpn-rd {
description "A Route Distinguisher used to distinguish type rt-types:route-distinguisher;
routes from different MVPNs (RFC 6513)."; description
reference "A Route Distinguisher used to distinguish
"RFC8294: Common YANG Data Types for the Routing Area."; routes from different MVPNs.";
} reference
leaf source-address { "RFC 8294: Common YANG Data Types for the Routing Area.
type ip-multicast-source-address; RFC 6513: Multicast in MPLS/BGP IP VPNs.";
description }
"The IPv4/IPv6 source address of multicast flow. The leaf source-address {
value set to zero means that the receiver interests type ip-multicast-source-address;
in all source that relevant to one given group."; description
} "The IPv4/IPv6 source address of the multicast flow. The
leaf group-address { value set to zero means that the receiver interests
type rt-types:ip-multicast-group-address; in all source that relevant to one given group.";
description }
"The IPv4/IPv6 group address of multicast flow. This leaf group-address {
type represents a version-neutral IP multicast group type rt-types:ip-multicast-group-address;
address. The format of the textual representation description
implies the IP version."; "The IPv4/IPv6 group address of multicast flow. This
reference type represents a version-neutral IP multicast group
"RFC8294: Common YANG Data Types for the Routing Area."; address. The format of the textual representation
implies the IP version.";
reference
"RFC8294: Common YANG Data Types for the Routing Area.";
}
leaf vni-type {
type virtual-type;
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.";
}
leaf vni-value {
type uint32;
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.";
}
} // general-multicast-key
grouping encap-type {
description
"The encapsulation type used for flow forwarding.";
choice encap-type {
case mpls {
description "The BIER forwarding depends on mpls.";
reference
"RFC 8296: Encapsulation for Bit Index Explicit
Replication (BIER) in MPLS and Non-MPLS Networks.";
} }
leaf vni-type { case eth {
type virtual-type; description "The BIER forwarding depends on ethernet.";
description reference
"The type of virtual network identifier. Includes the "RFC 8296: Encapsulation for Bit Index Explicit
Vxlan, NVGRE and Geneve. This value and vni-value is Replication (BIER) in MPLS and Non-MPLS Networks.";
used to indicate a specific virtual multicast service.";
} }
leaf vni-value { case ipv6 {
type uint32; description "The BIER forwarding depends on IPv6.";
description reference
"The value of Vxlan network identifier, virtual subnet "I-D.zhang-bier-bierin6: BIER in IPv6 (BIERin6)";
ID or virtual net identifier. This value and vni-type
is used to indicate a specific virtual multicast service.";
} }
} description "The encapsulation type in BIER.";
}
/*overlay*/ } // encap-type
grouping overlay-technology { grouping bier-key {
leaf overlay-tech-type { description
type enumeration { "The key parameters set for BIER/BIER TE forwarding.";
enum mld { reference
description "MLD technology is used for multicast "RFC 8279: Multicast Using Bit Index Explicit Replication
overlay. See more detail in [draft-ietf-bier-mld]"; (BIER).";
}
enum mvpn {
description "MVPN technology is used for multicast
overlay. See more detail in RFC6513.";
}
enum bgp {
description "BGP technology is used for multicast
overlay. See more detail in RFC7716.";
}
enum mld-snooping {
description "MLD snooping technology is used for
multicast overlay. See more detail in RFC4541.";
}
}
description "The possible overlay technologies for multicast service.";
}
description "The possible overlay technologies for multicast service.";
}
grouping multicast-overlay { leaf sub-domain {
type uint16;
description description
"The multicast overlay information, includes ingress node "The subdomain id that the multicast flow belongs to.";
and egress nodes' information."; }
leaf bitstringlength {
type uint16;
description
"The bitstringlength used by BIER forwarding.";
}
leaf set-identifier {
type uint16;
description
"The set identifier used by the multicast flow.";
container ingress-egress { }
description "The ingress and egress nodes address collection."; uses encap-type;
leaf ingress-node { }
type inet:ip-address;
description
"The ip address of ingress node for one or more
multicast flow. Or the ingress node of MVPN and
BIER. In MVPN, this is the address of ingress
PE; in BIER, this is the BFR-prefix of ingress
nodes.";
}
list egress-nodes { grouping transport-tech {
key "egress-node"; choice transport {
description description "The selected transport technology.";
"The egress multicast nodes of multicast flow. Or container bier {
the egress node of MVPN and BIER. In MVPN, this description
is the address of egress PE; in BIER, this is the "The transport technology is BIER. The BIER technology
BFR-prefix of ingress nodes."; is introduced in RFC8279. The parameter is consistent
with the definition in BIER YANG data model.";
reference
"RFC 8279: Multicast Using Bit Index Explicit
Replication (BIER).
I-D.ietf-bier-bier-yang: YANG Data Model for BIER
Protocol.";
leaf egress-node { uses bier-key;
type inet:ip-address;
description
"The ip-address of egress multicast nodes.
See more details in RFC6513.";
}
}
} }
container bier-ids { container bier-te {
description description
"The BFR-ids of ingress and egress BIER nodes for "The transport technology is BIER-TE.";
one or more multicast flows."; reference
leaf sub-domain { "I-D.ietf-bier-te-arch: Traffic Engineering for Bit Index
type uint16; Explicit Replication (BIER-TE)";
description
"The sub-domain that this multicast flow belongs
to. See more details in RFC8279.";
}
leaf ingress-node {
type uint16;
description
"The ingress node of multicast flow. This is the
BFR-id of ingress nodes. See more details in RFC8279.";
}
list egress-nodes {
key "egress-node";
description
"This ID information of one adjacency. See more
details in RFC8279.";
leaf egress-node { uses bier-key;
type uint16;
description
"The BFR-ids of egress multicast BIER nodes.
See more details in RFC8279.";
} leaf-list bier-te-adj {
} type uint16;
description
"The adjacencies ID used in BIER TE forwarding
encapsulation.";
}
} }
uses overlay-technology; container cisco-mode {
} description
"The transport technology is cisco-mode: Cisco MDT.";
/*transport*/ reference
"RFC 6037: Cisco Systems' Solution for Multicast in
BGP/MPLS IP VPNs";
grouping transport-pim { leaf p-group {
description type rt-types:ip-multicast-group-address;
"The requirement information of pim transportion.
PIM protocol is defined in RFC7761.";
leaf graceful-restart {
type boolean;
description description
"If the graceful restart function should be supported."; "The address of p-group. It is used to encapsulate
} and forward flow according to multicast tree from
leaf bfd { ingress node to egress nodes.";
type boolean; }
description "If the bfd function should be supported."; uses transport-pim;
} }
}
grouping multicast-transport { container mpls {
description "The transport information of multicast service."; description
container bier { "The transport technology is mpls. MVPN overlay can use
description mpls tunnel technologies to build transport layer.";
"The transport technology is BIER. The BIER technology reference
is introduced in RFC8279. The parameter is consistent "RFC 6513: Multicast in MPLS/BGP IP VPNs.";
with the definition in [ietf-bier-bier-yang].";
leaf sub-domain { choice mpls-tunnel-type {
type uint16; case mldp {
description description "The mldp tunnel.";
"The subdomain id that the multicast flow belongs reference
to. See more details in RFC8279."; "RFC 6388: Label Distribution Protocol Extensions
} for Point-to-Multipoint and Multipoint-to-Multipoint
choice encap-type { Label Switched Paths.";
case mpls {
description "The BIER forwarding depends on mpls. leaf mldp-tunnel-id {
See more details in RFC8296."; type uint32;
}
case eth {
description "The BIER forwarding depends on ethernet.
See more details in RFC8296.";
}
case ipv6 {
description "The BIER forwarding depends on IPv6.";
}
description "The encapsulation type in BIER.";
}
leaf bitstringlength {
type uint16;
description "The bitstringlength used by BIER forwarding.
See more details in RFC8279.";
}
leaf set-identifier {
type uint16;
description "The set identifier used by the multicast flow.
See more details in RFC8279.";
}
leaf ecmp {
type boolean;
description description
"The capability of ECMP. If this value is set to true, "The tunnel id that correspond this flow.";
ecmp mechanism should be enabled. See more details in RFC8279."; }
} leaf mldp-backup-tunnel {
leaf frr {
type boolean; type boolean;
description description
"The capability of fast re-route. If this value is "If the backup tunnel function should be
set to true, fast re-route mechanism should be supported.";
enabled. See more details in RFC8279."; }
}
}
container bier-te {
description
"The transport technology is BIER-TE. BIER-TE technology
is introduced in [ietf-bier-te-arch].";
leaf sub-domain {
type uint16;
description
"The subdomain id that the multicast flow belongs to.
See more details in [ietf-bier-te-arch].";
} }
choice encap-type { case p2mp-te {
case mpls { description
description "The p2mp te tunnel.";
"The BIER-TE forwarding depends on mpls. See more reference
details in [ietf-bier-te-arch]."; "RFC 4875: Extensions to Resource Reservation Protocol
} - Traffic Engineering (RSVP-TE) for Point-to-Multipoint
case non-mpls { TE Label Switched Paths (LSPs).";
description
"The BIER-TE forwarding depends on non-mpls. See
more details in [ietf-bier-te-arch].";
} leaf te-tunnel-id {
description "The encapsulation type in BIER-TE."; type uint32;
}
leaf bitstringlength {
type uint16;
description "The bitstringlength used by BIER-TE forwarding.
See more details in [ietf-bier-te-arch].";
}
leaf set-identifier {
type uint16;
description
"The set identifier used by the multicast flow,
especially in BIER TE. See more details in
[ietf-bier-te-arch].";
}
leaf ecmp {
type boolean;
description description
"The capability of ECMP. If this value is set to "The tunnel id that correspond this flow.";
true, ecmp mechanism should be enabled. }
See more details in [ietf-bier-te-arch]."; leaf te-backup-tunnel {
}
leaf frr {
type boolean; type boolean;
description description
"The capability of fast re-route. If this value "If the backup tunnel function should be
is set to true, fast re-route mechanism should supported.";
be enabled. See more details in }
[ietf-eckert-bier-te-frr].";
}
}
container cisco-mode {
description
"The transport technology is cisco-mode. The Cisco MDT
multicast mechanism is defined in RFC6037.";
leaf p-group {
type rt-types:ip-multicast-group-address;
description
"The address of p-group. It is used to encapsulate
and forward flow according to multicast tree from
ingress node to egress nodes.";
} }
uses transport-pim; description "The collection types of mpls tunnels";
}
} // mpls
container pim {
description
"The transport technology is PIM. PIM is used
commonly in traditional network.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification (Revised).";
uses transport-pim;
} }
container mpls { } // choice
description } // transport-tech
"The transport technology is mpls. MVPN overlay can use
mpls tunnel technologies to build transport layer. The
usage is introduced in RFC6513.";
choice mpls-tunnel-type {
case mldp {
description "The mldp tunnel. The protocol detail
is defined in RFC6388.";
leaf mldp-tunnel-id {
type uint32;
description "The tunnel id that correspond this
flow. The detail is defined in RFC6388.";
}
leaf mldp-frr {
type boolean;
description
"If the fast re-route function should be
supported. The detail is defined in RFC6388.";
}
leaf mldp-backup-tunnel {
type boolean;
description
"If the backup tunnel function should be
supported. The detail is defined in RFC6388.";
}
}
case p2mp-te {
description
"The p2mp te tunnel. The protocol detail is
defined in RFC4875.";
leaf te-tunnel-id {
type uint32;
description
"The tunnel id that correspond this flow.
The detail is defined in RFC4875.";
}
leaf te-frr {
type boolean;
description
"If the fast re-route function should be
supported. The detail is defined in RFC4875.";
}
leaf te-backup-tunnel {
type boolean;
description
"If the backup tunnel function should be
supported. The detail is defined in RFC4875.";
}
}
description "The collection types of mpls tunnels";
}
grouping underlay-tech {
choice underlay {
case bgp {
description
"The underlay technology is BGP. BGP protocol
should be used to run if BGP is used as
underlay protocol.";
reference
"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
} }
container pim { container ospf {
uses transport-pim; description
"The underlay technology is OSPF. OSPF protocol
should be triggered to run if OSPF is used as underlay
protocol.";
reference
"RFC 2328: OSPF Version 2.
RFC 5340: OSPF for IPv6.
I-D.ietf-ospf-yang: YANG Data Model for OSPF Protocol.";
leaf topology {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/ospf:ospf/"
+ "ospf:topologies/ospf:topology/ospf:name";
}
description description
"The transport technology is PIM. PIM [RFC7761] is used "The designed topology name of ospf protocol.";
commonly in traditional network."; }
} }
} case isis {
description
"The underlay technology is ISIS. ISIS protocol should
be triggered to run if ISIS is used as underlay protocol.
And the associated extensions can be used.";
reference
"RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments";
}
case babel {
description
"The underlay technology is Babel. Babel protocol
should be triggered to run if Babel is used as
underlay protocol.";
reference
"I-D.ietf-babel-rfc6126bis: The Babel Routing Protocol.";
}
} // choice
} // underlay-tech
/*underlay*/ /*overlay*/
grouping multicast-underlay { grouping overlay-tech {
description choice overlay-tech-type {
"The underlay information relevant multicast service. case bgp {
Underlay protocols are used to build transport layer. description
It is unnecessary in traditional network that use "BGP technology is used for multicast overlay.";
PIM [RFC7761] to build multicast tree. Diversity underlay reference
protocols can be choosed to build BIER transport layer."; "RFC 7716: Global Table Multicast with BGP Multicast
leaf underlay-requirement { VPN (BGP-MVPN) Procedures.";
type boolean;
description "If the underlay technology is required.";
} }
container bgp { case evpn {
description description
"The underlay technology is BGP. BGP protocol RFC4271 "EVPN technology is used for multicast overlay.";
should be triggered to run if BGP is used as reference
underlay protocol."; "RFC 7432: BGP MPLS-Based Ethernet VPN.
I-D.ietf-bess-evpn-bum-procedure-updates: Updates on
EVPN BUM Procedures.
I-D.ietf-bier-evpn: EVPN BUM Using BIER.";
} }
container ospf { case mld {
description
"MLD technology is used for multicast overlay.";
reference
"I-D.ietf-bier-mld: BIER Ingress Multicast Flow Overlay
using Multicast Listener Discovery Protocols.";
leaf mld-instance-group {
type rt-types:ip-multicast-group-address;
description description
"The underlay technology is OSPF. OSPF protocol RFC2328 "The multicast address used for multiple MLD instance
should be triggered to run if OSPF is used as underlay support.";
protocol."; }
leaf topology-id {
type uint8;
description
"The topology id of ospf instance. The topology id
can be assigned In some situations. More details
is defined in RFC2328.";
}
} }
container isis { case mld-snooping {
description description
"The underlay technology is ISIS. ISIS protocol should "MLD snooping technology is used for multicast overlay.";
be triggered to run if ISIS is used as underlay protocol. reference
Details is defined in RFC1195."; "RFC 4541: Considerations for Internet Group Management
leaf topology-id { Protocol (IGMP) and Multicast Listener
type uint16; Discovery (MLD) Snooping Switches.";
description
"The topology id of isis instance. The topology id
can be assigned In some situations.";
}
} }
container babel { case mvpn {
description description
"The underlay technology is Babel. Babel protocol should "MVPN technology is used for multicast overlay.";
be triggered to run if Babel is used as underlay protocol."; reference
"RFC 6513: Multicast in MPLS/BGP IP VPNs.";
} }
} case pim {
description
"PIM technology is used for multicast overlay.";
reference
"I-D.ietf-bier-pim-signaling: PIM Signaling
Through BIER Core.";
}
description
"The overlay technology used for multicast service.";
}
description "The overlay technology used for multicast service.";
} // overlay-tech
/*transport*/
grouping transport-pim {
description
"The requirement information of pim transportion.";
reference
"RFC 7761: Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification (Revised).";
} //transport-pim
/*underlay*/
container multicast-model { container multicast-model {
description description
"The model of multicast YANG data. Include keys, overlay, "The model of multicast YANG data. Include keys, overlay,
transport and underlay."; transport and underlay.";
list multicast-keys{ list multicast-keys{
key "vpn-rd source-address group-address vni-type vni-value"; key "vpn-rd source-address group-address vni-type vni-value";
uses general-multicast-key; uses general-multicast-key;
container multicast-overlay { container multicast-overlay {
description description
"The overlay information of multicast service. "The overlay information of multicast service.
Overlay technology is used to exchange multicast Overlay technology is used to exchange multicast
flows information. Overlay technology may not be flows information. Overlay technology may not be
used in SDN controlled completely situation, but used in SDN controlled completely situation, but
it can be used in partial SDN controlled situation it can be used in partial SDN controlled situation
or non-SDN controlled situation. Different overlay or non-SDN controlled situation. Different overlay
technology can be choosed according to different technologies can be choosed according to different
deploy consideration."; deploy consideration.";
uses multicast-overlay;
container ingress-egress {
description
"The ingress and egress nodes address collection.
The ingress node may use the egress nodes set
directly to encapsulate the multicast flow by
transport technology.";
leaf ingress-node {
type inet:ip-address;
description
"The ip address of ingress node for one or more
multicast flow. Or the ingress node of MVPN and
BIER. In MVPN, this is the address of ingress
PE; in BIER, this is the BFR-prefix of ingress
nodes.";
} }
container multicast-transport { list egress-nodes {
key "egress-node";
description
"The egress multicast nodes of the multicast flow.
Or the egress node of MVPN and BIER. In MVPN, this
is the address of egress PE; in BIER, this is the
BFR-prefix of ingress nodes.";
leaf egress-node {
type inet:ip-address;
description description
"The transportion of multicast service. Transport "The ip-address set of egress multicast nodes.";
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.";
uses multicast-transport;
} }
container multicast-underlay { }
container bier-ids {
description
"The BFR-ids of ingress and egress BIER nodes for
one or more multicast flows. This overlay is used
with BIER transport technology. The egress nodes
set can be used to encapsulate the multicast flow
directly in the ingress node.";
reference
"RFC 8279: Multicast Using Bit Index Explicit
Replication (BIER)";
leaf sub-domain {
type uint16;
description
"The sub-domain that this multicast flow belongs to.";
}
leaf ingress-node {
type uint16;
description
"The ingress node of multicast flow. This is the
BFR-id of ingress nodes.";
}
list egress-nodes {
key "egress-node";
description
"The egress nodes of multicast flow.";
leaf egress-node {
type uint16;
description description
"The underlay of multicast service. Underlay protocol "The BFR-ids of egress multicast BIER nodes.";
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
controll. Once a underlay technology is choosed,
associated protocol should be triggered to run.";
uses multicast-underlay;
} }
description }
"The model of multicast YANG data. Include keys, uses overlay-tech;
overlay, transport and underlay.";
} }
container multicast-transport {
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.";
uses transport-tech;
}
container multicast-underlay {
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
controll. Once a underlay technology is choosed,
associated protocol should be triggered to run.";
uses underlay-tech;
}
description
"The model of multicast YANG data. Include keys,
overlay, transport and underlay.";
}
} }
/*Notifications*/ /*Notifications*/
notification head-end-event { notification head-end-event {
leaf event-type { leaf event-type {
type enumeration { type enumeration {
enum down { enum down {
description
"There is something wrong with head end node,
and head end node can't work properlay.";
}
enum module-loaded {
description
"Some new modules that can be used by multicast
flows finish loading.";
}
enum module-unloaded {
description
"Some new modules that can be used by multicast
flows have been unloaded.";
}
}
description "Event type.";
}
container multicast-key {
uses general-multicast-key;
description description
"The associated multicast keys that are influenced by "There is something wrong with head end node,
head end node failer."; and head end node can't work properlay.";
}
enum module-loaded {
description
"The new modules that can be used by multicast
flows have been loaded.";
}
enum module-unloaded {
description
"The new modules that can be used by multicast
flows have been unloaded.";
}
} }
uses overlay-technology; description "Event type.";
}
container multicast-key {
uses general-multicast-key;
description
"The associated multicast keys that are influenced by
head end node failer.";
}
uses overlay-tech;
leaf transport-tech { container transport-tech {
type enumeration {
enum bier {
description
"BIER(RFC8279) technology can be used to
forward multicast flows.";
}
enum bier-te {
description
"BIER-TE(draft-ietf-bier-te-arch) technology
can be used to forward multicast flows.";
}
enum cisco-mode {
description
"Cisco mode(RFC6037) technology can be used
to forward multicast flows.";
}
enum mldp {
description
"MLDP(RFC6388) technology can be used to
forward multicast flows.";
}
enum p2mp-te {
description
"P2MP TE(RFC4875) technology can be used to
forward multicast flows.";
}
enum pim {
description
"PIM(RFC7761) technology can be used to
forward multicast flows.";
}
}
description "The modules can be used to forward multicast flows.";
}
leaf underlay-tech {
type enumeration {
enum bgp {
description "BGP protocol can be used to build
multicast transport layer.";
}
enum ospf {
description "OSPF protocol can be used to build
multicast transport layer.";
}
enum isis {
description "ISIS protocol can be used to build
multicast transport layer.";
}
enum babel {
description "Babel protocol can be used to build
multicast transport layer.";
}
}
description "The modules can be used to build multicast
transport layer.";
}
description description
"Notification events for the head end nodes. Like head "The modules can be used to forward multicast flows.";
node failer, overlay/ transport/ underlay module uses transport-tech;
loading/ unloading. And the potential failer about some }
multicast flows and associated
overlay/ transport/ underlay technologies."; container underlay-tech {
description
"There is something wrong with the module which is
used to build multicast transport layer.";
uses underlay-tech;
}
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.";
} }
} }
<CODE ENDS> <CODE ENDS>
6. Notifications 5. Security Considerations
The defined Notifications include the events of head end nodes. Like The YANG module specified in this document defines a schema for data
head node failer, overlay/ transport/ underlay module loading/ that is designed to be accessed via network management protocols such
unloading. And the potential failer about some multicast flows and as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
associated overlay/ transport/ underlay technologies. is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are data nodes and their
sensitivity/vulnerability:
Under /rt:routing/rt:control-plane-protocols/multicast-model,
multicast-model
These data nodes in this model specifies the configuration for the
multicast service at the top level. Modifying the configuration
can cause multicast service to be deleted or reconstructed.
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the data nodes and
their sensitivity/vulnerability:
/rt:routing/rt:control-plane-protocols/multicast-model,
Unauthorized access to any data node of the above tree can disclose
the operational state information of multicast service on this
device.
6. IANA Considerations
RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC
number (and remove this note).
The IANA is requested to assign one new URI from the IETF XML
registry [RFC3688]. Authors are suggesting the following URI:
URI: urn:ietf:params:xml:ns:yang:ietf-multicast-model
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
This document also requests one new YANG module name in the YANG
Module Names registry [RFC6020] with the following suggestion:
name: ietf-multicast-model
namespace: urn:ietf:params:xml:ns:yang:ietf-multicast-model
prefix: multicast-model
reference: RFC XXXX
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Stig Venaas, Jake Holland, Min Gu for The authors would like to thank Stig Venaas, Jake Holland, Min Gu for
their valuable comments and suggestions. their valuable comments and suggestions.
8. Normative References 8. References
[I-D.ietf-bier-bier-yang] 8.1. Normative References
Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d.,
and M. Sivakumar, "YANG Data Model for BIER Protocol",
draft-ietf-bier-bier-yang-05 (work in progress), May 2019.
[I-D.ietf-bier-te-arch] [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
Eckert, T., Cauchie, G., and M. Menth, "Traffic dual environments", RFC 1195, DOI 10.17487/RFC1195,
Engineering for Bit Index Explicit Replication (BIER-TE)", December 1990, <https://www.rfc-editor.org/info/rfc1195>.
draft-ietf-bier-te-arch-03 (work in progress), July 2019.
[I-D.ietf-pim-yang] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, Requirement Levels", BCP 14, RFC 2119,
Y., and f. hu, "A YANG Data Model for Protocol Independent DOI 10.17487/RFC2119, March 1997,
Multicast (PIM)", draft-ietf-pim-yang-17 (work in <https://www.rfc-editor.org/info/rfc2119>.
progress), May 2018.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
Systems' Solution for Multicast in BGP/MPLS IP VPNs",
RFC 6037, DOI 10.17487/RFC6037, October 2010,
<https://www.rfc-editor.org/info/rfc6037>.
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", RFC 6087, DOI 10.17487/RFC6087,
January 2011, <https://www.rfc-editor.org/info/rfc6087>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
<https://www.rfc-editor.org/info/rfc6388>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
RFC 7277, DOI 10.17487/RFC7277, June 2014, Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
<https://www.rfc-editor.org/info/rfc7277>. Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
Zhang, "YANG Data Model for Key Chains", RFC 8177, and D. Pacella, "Global Table Multicast with BGP Multicast
DOI 10.17487/RFC8177, June 2017, VPN (BGP-MVPN) Procedures", RFC 7716,
<https://www.rfc-editor.org/info/rfc8177>. DOI 10.17487/RFC7716, December 2015,
<https://www.rfc-editor.org/info/rfc7716>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294, "Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017, DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>. <https://www.rfc-editor.org/info/rfc8294>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[I-D.ietf-babel-rfc6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", draft-ietf-babel-rfc6126bis-17 (work in
progress), February 2020.
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", draft-ietf-
bess-evpn-bum-procedure-updates-08 (work in progress),
November 2019.
[I-D.ietf-bier-bier-yang]
Chen, R., hu, f., Zhang, Z., dai.xianxian@zte.com.cn, d.,
and M. Sivakumar, "YANG Data Model for BIER Protocol",
draft-ietf-bier-bier-yang-06 (work in progress), February
2020.
[I-D.ietf-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
"EVPN BUM Using BIER", draft-ietf-bier-evpn-02 (work in
progress), November 2019.
[I-D.ietf-bier-mld]
Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang,
Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay
using Multicast Listener Discovery Protocols", draft-ietf-
bier-mld-04 (work in progress), March 2020.
[I-D.ietf-bier-pim-signaling]
Bidgoli, H., Kotalwar, J., Xu, F., mishra, m., Zhang, Z.,
and A. Dolganow, "PIM Signaling Through BIER Core", draft-
ietf-bier-pim-signaling-08 (work in progress), November
2019.
[I-D.ietf-bier-te-arch]
Eckert, T., Cauchie, G., and M. Menth, "Path Engineering
for Bit Index Explicit Replication (BIER-TE)", draft-ietf-
bier-te-arch-06 (work in progress), February 2020.
[I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-14 (work in progress), September 2019.
[I-D.ietf-ospf-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for OSPF Protocol", draft-ietf-ospf-
yang-29 (work in progress), October 2019.
[I-D.ietf-pim-yang]
Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu,
Y., and f. hu, "A YANG Data Model for Protocol Independent
Multicast (PIM)", draft-ietf-pim-yang-17 (work in
progress), May 2018.
[I-D.zhang-bier-bierin6]
Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
bierin6-04 (work in progress), January 2020.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>.
[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
Systems' Solution for Multicast in BGP/MPLS IP VPNs",
RFC 6037, DOI 10.17487/RFC6037, October 2010,
<https://www.rfc-editor.org/info/rfc6037>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/info/rfc8407>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
Appendix A. Data Tree Example
This section contains an example of an instance data tree in JSON
encoding [RFC7951], containing configuration data.
The configuration example:
{
"ietf-multicast-model:multicast-model":{
"multicast-keys":[
{
"vpn-rd":"0:65532:4294967292",
"source-address":"*",
"group-address":"234.232.203.84",
"vni-type":"nvgre",
"vni-value":0,
"multicast-overlay":{
"ingress-egress":{
"ingress-node":"146.150.100.0",
"egress-nodes":[
{
"egress-node":"110.141.168.0"
}
]
},
},
"multicast-transport":{
"bier":{
"sub-domain":0,
"bitstringlength":256,
"set-identifier":0
}
},
"multicast-underlay":{
"ospf":{
"topology":"2"
}
}
}
]
}
}
Authors' Addresses Authors' Addresses
Zheng Zhang Zheng Zhang
ZTE Corporation ZTE Corporation
China China
Email: zzhang_ietf@hotmail.com Email: zzhang_ietf@hotmail.com
Cui(Linda) Wang Cui(Linda) Wang
ZTE Corporation Individual
China Australia
Email: lindawangjoy@gmail.com Email: lindawangjoy@gmail.com
Ying Cheng Ying Cheng
China Unicom China Unicom
Beijing Beijing
China China
Email: chengying10@chinaunicom.cn Email: chengying10@chinaunicom.cn
 End of changes. 107 change blocks. 
738 lines changed or deleted 1304 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/