RFC 9128: YANG Data Model for Protocol Independent Multicast (PIM)
- X. Liu,
- P. McAllister,
- A. Peter,
- M. Sivakumar,
- Y. Liu,
- F. Hu
Abstract
This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). The model covers the PIM protocol configuration, operational state, and event notifications data.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
YANG [RFC7950] is a data modeling language that was introduced to model the configuration and operational state of a device managed using network management protocols such as the Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040]. YANG is now also being used as a component of other management interfaces, such as command-line interfaces (CLIs).¶
This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM). This model supports the core PIM protocol, as well as many other features; see Section 2.1. Non-core features are defined as optional in the provided data model.¶
1.1. Terminology
The terminology for describing YANG data models is found in [RFC7950].¶
The following abbreviations are used in this document and the defined model:¶
- ASM:
- Any-Source Multicast service model [RFC3569] [RFC4607]¶
- BFD:
- Bidirectional Forwarding Detection [RFC5880]¶
- BIDIR-PIM:
- Protocol Independent Multicast - Bidirectional Mode [RFC5015]¶
- BSR:
- Bootstrap Router [RFC5059]¶
- DF:
- Designated Forwarder [RFC5015]¶
- DR:
- Designated Router [RFC7761]¶
- IGMP:
- Internet Group Management Protocol [RFC3376]¶
- MLD:
- Multicast Listener Discovery [RFC3810]¶
- mLDP:
- Multipoint extensions for LDP [RFC6388]¶
- MRIB:
- Multicast Routing Information Base [RFC3973] [RFC5015] [RFC7761]¶
- MSDP:
- Multicast Source Discovery Protocol [RFC3618]¶
- mVPN:
- Multicast VPN¶
- PIM:
- Protocol Independent Multicast [RFC3973] [RFC5015] [RFC7761]¶
- PIM-DM:
- Protocol Independent Multicast - Dense Mode [RFC3973]¶
- PIM-SM:
- Protocol Independent Multicast - Sparse Mode [RFC7761]¶
- RP:
- Rendezvous Point [RFC7761]¶
- RPA:
- Rendezvous Point Address [RFC5015]¶
- RPF:
- Reverse Path Forwarding [RFC3973] [RFC5015] [RFC7761]¶
- RPT:
- Rendezvous Point Tree [RFC7761]¶
- SPT:
- Shortest Path Tree [RFC7761]¶
- SSM:
- Source-Specific Multicast service model [RFC3569] [RFC4607]¶
- VRF:
- Virtual Routing and Forwarding¶
1.2. Tree Diagrams
Tree diagrams used in this document follow the notation defined in [RFC8340].¶
In addition, the following notation is used as a placeholder at the location of the name of a tree node, to represent a section of nodes:¶
<summary description of a section of nodes>¶
1.3. 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 the context clearly indicates the YANG module in which each name is defined. Otherwise, names are prefixed using the standard prefix associated with the corresponding YANG module, as shown in Table 1.¶
2. Design of Data Model
2.1. Scope of Model
The model covers PIM Sparse Mode [RFC7761] (including the Source-Specific subset [RFC3569] [RFC4607]), Dense Mode [RFC3973], and Bidirectional PIM [RFC5015].¶
The PIM extensions represented in the model include BSRs [RFC5059] and Anycast-RPs [RFC4610].¶
The data model can be used to configure and manage these
protocol features. The operational state data and statistics
can be retrieved by this model. The protocol
This model does not cover other multicast protocols such as IGMP/MLD, MSDP, mVPN, or mLDP in-band signaling. It does not cover any configuration required to generate the MRIB. These will be specified in separate documents.¶
2.2. Optional Capabilities
This model is designed to represent the capabilities of devices supporting PIM with various specifications, including some with basic subsets of the PIM protocol. The main design goals of this document are that any major currently existing implementation may be said to support the base model and that the configuration of all implementations meeting the specification is easy to express through some combination of the features in the base model and simple vendor augmentations.¶
There is also value in widely supported features being standardized, to save work for individual vendors, and so that mapping between different vendors' configurations is not needlessly complicated. Therefore, these modules declare a number of features representing capabilities that not all deployed devices support.¶
The extensive use of feature declarations should also substantially simplify the capability negotiation process for a vendor's PIM implementation.¶
On the other hand, operational state parameters are not so widely designated as features, as there are many cases where the defaulting of an operational state parameter would not cause any harm to the system, and it is much more likely that an implementation without intrinsic support for a piece of operational state would be able to derive a suitable value for a state variable that is not intrinsically supported.¶
For the same reason, wide constant ranges (for example, timer maxima
and minima) are used in the model. It is expected that
vendors will augment the model with any specific extensions
and restrictions needed to adapt it to their vendor-specific
implementations
2.3. Datastore Applicability
This model 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].¶
2.4. Module and Hierarchy Organization
This model defines several separate modules for modeling PIM configuration. Again, this separation makes it easier to express the specific capabilities of a PIM device. The module organization, along with the usage of the YANG extensible features such as identity, allows the model to be easily augmented for new capabilities.¶
The hierarchy of PIM configuration is designed so that objects that are only relevant for one situation or feature are collected in a container for that feature. For example, a configuration for PIM-SM that is not relevant for an SSM-only implementation is collected in an ASM container.¶
Where fields are not genuinely essential to protocol operation, they are marked as optional. Some fields are essential but have a default specified, so they need not be explicitly configured.¶
This module structure also applies, where applicable, to the operational state and notifications of the model.¶
2.5. Position of Address Family in Hierarchy
This document contains "address
The reasoning for this is to make it easier for implementations in which configuration options are not supported for specific address families.¶
For these implementations
3. Module Structure
3.1. PIM Base Module
The PIM base module defines the base framework not
specific to any PIM mode and is imported by the other
modules. The base module by itself does not provide
sufficient data for any PIM mode to operate. Other mode-specific
and feature
This model augments the core routing data model "ietf-routing"
specified in [RFC8349].
The PIM base model augments
"
3.1.1. High-Level Structure
The high-level structure of the model is shown below:¶
The presence of the top-level container "pim" enables the PIM protocols.¶
3.1.2. Global Data
The global configuration data and operational state data cover support for graceful restart in the PIM base model. Additional features can be added by augmentation if required by an implementation.¶
3.1.3. Per-Address-Family Data
Support for per
This is the location that most of the PIM RP module (ietf-pim-rp) augments. Each of the mode-specific modules also augments this schema tree.¶
3.1.4. PIM Interface Modeling
The configuration data and operational state data of PIM interfaces are modeled as shown below:¶
Support for BFD client configuration is achieved by using a grouping provided
by an external module, "ietf
3.1.5. Neighbor Modeling
For each PIM interface, there can be a list of neighbors that contains operational state data for each neighbor. To model such data, the following structure is specified:¶
3.1.6. Notifications
The PIM base module also defines the notifications for PIM interface and neighbor events, as shown below:¶
3.2. PIM RP Module
The PIM RP module augments the PIM base module to define the configuration and operational state information scoped to RP-related features:¶
This module is shared by PIM-SM and BIDIR-PIM mode but is not shared by PIM-DM. The PIM-SM module and the BIDIR-PIM module augment this module to cover mode-specific data.¶
The following sections describe the features and capabilities covered in this module.¶
3.2.1. Static RPs
Static RPs can be configured by using the following portion of the module:¶
3.2.2. BSRs
Support for BSRs includes both configuration data and operational state data, as shown below:¶
3.2.3. RP State Data
This portion of the model provides the operational state information for all RPs on the router, including the statically configured RPs and the BSR-elected RPs.¶
3.2.4. RP-to-Group Mappings
The operational state data of the mappings between RPs and multicast groups is modeled as follows:¶
3.2.5. Notifications
The PIM RP module also defines the notifications for RP-related events, as shown below:¶
3.3. PIM-SM Module
The PIM-SM module covers Sparse Mode modeling, including PIM Any-Source Multicast (PIM-ASM) and PIM Source-Specific Multicast (PIM-SSM). This module has dependencies on the PIM base module and the PIM RP module, both of which are augmented by this module.¶
The augmentation to the "address
To support PIM-SM on an interface, this module augments the "interface" branch of the PIM base module, as follows:¶
This module also augments the PIM RP module to allow an RP to be configured in PIM-SM:¶
3.4. PIM-DM Module
The PIM-DM module covers Dense Mode modeling. This module augments the PIM base module, but it has no dependency on the PIM RP module.¶
3.5. BIDIR-PIM Module
The BIDIR-PIM module covers Bidirectional PIM modeling. Like PIM-SM, this module augments both the PIM base module and the PIM RP module.¶
The augmentations to the PIM base module, on
the "address
This module also augments the PIM RP module to extend the capabilities of RPs for BIDIR-PIM mode:¶
4. Complete Tree Structure
4.1. PIM Base Module
4.2. PIM RP Module
4.3. PIM-SM Module
4.4. PIM-DM Module
4.5. BIDIR-PIM Module
5. Relationship to the PIM-STD-MIB
The following sections describe the mappings between the objects in the PIM-STD-MIB defined in [RFC5060] and the YANG data nodes defined in this document.¶
5.1. pimInterfaceTable
pim
Table 2 lists the YANG data nodes with
corresponding objects of pim
5.2. pimNeighborTable
pim
Table 3 lists the YANG data nodes with
corresponding objects of pim
5.3. pimStarGTable
pimStarGTable is mapped to
pim
Table 4 lists the YANG data nodes with corresponding objects of pimStarGTable in the PIM-STD-MIB.¶
In addition, the object "pim
5.4. pimSGTable
pimSGTable is mapped to
pim
Table 5 lists the YANG data nodes with corresponding objects of pimSGTable in the PIM-STD-MIB.¶
5.5. pimSGRptTable
pimSGRptTable is mapped to
pim
Table 6 lists the YANG data nodes with corresponding objects of pimSGRptTable in the PIM-STD-MIB.¶
5.6. pimBidirDFElectionTable
pim
Table 7 lists the YANG data nodes with
corresponding objects of pim
5.7. pimStaticRPTable
pim
Table 8 lists the YANG data nodes with
corresponding objects of pim
5.8. pimAnycastRPSetTable
pim
Table 9 lists the YANG data nodes with
corresponding objects of pim
5.9. pimGroupMappingTable
pim
Table 10 lists the YANG data nodes with
corresponding objects of pim
In addition, the object "pim
6. PIM YANG Modules
6.1. PIM Base Module
This module references [RFC3973], [RFC5015], [RFC5880], [RFC6991], [RFC7761], [RFC8294], [RFC8343], [RFC8349], [RFC8706], and [RFC9314].¶
6.2. PIM RP Module
This module references [RFC5059], [RFC6991], [RFC7761], [RFC8294], [RFC8343], and [RFC8349].¶
6.3. PIM-SM Module
This module references [RFC4607], [RFC6991], [RFC7761], and [RFC8349].¶
6.4. PIM-DM Module
6.5. BIDIR-PIM Module
This module references [RFC5015], [RFC6991], [RFC8294], [RFC8343], and [RFC8349].¶
7. Security Considerations
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the
mandatory
The Network Configuration Access Control Model (NACM) [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 these YANG modules that are
writable
- pim
-base :graceful -restart - This subtree specifies the configuration for PIM graceful restart at the global level on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart.¶
- pim
-base :address -family /pim -base :graceful -restart -
This subtree specifies the per
-address -family configuration for PIM graceful restart on a device. Modifying the configuration can cause temporary interruption to the multicast routing during restart.¶ - pim
-base :address -family /pim -rp :pim -rp :rp - This subtree specifies the configuration for the PIM Rendezvous Point (RP) on a device. Modifying the configuration can cause RP malfunctions.¶
- pim
-base :address -family /pim -sm :sm - This subtree specifies the configuration for PIM Sparse Mode (PIM‑SM) on a device. Modifying the configuration can cause multicast traffic to be disabled or rerouted in PIM-SM.¶
- pim
-base :address -family /pim -dm :dm - This subtree specifies the configuration for PIM Dense Mode (PIM‑DM) on a device. Modifying the configuration can cause multicast traffic to be disabled or rerouted in PIM-DM.¶
- pim
-base :address -family /pim -bidir :bidir - This subtree specifies the configuration for PIM Bidirectional Mode (BIDIR-PIM) on a device. Modifying the configuration can cause multicast traffic to be disabled or rerouted in BIDIR-PIM.¶
- pim
-base :interfaces - This subtree specifies the configuration for the PIM interfaces on a device. Modifying the configuration can cause the PIM protocol to get insufficient or incorrect information.¶
These subtrees are all under
"
Unauthorized access to any data node of these subtrees can adversely affect the multicast routing subsystem of both the local device and the network. This may lead to network malfunctions, delivery of packets to inappropriate destinations, and other problems.¶
Some of the readable data nodes in these YANG modules 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 subtrees and data nodes and their
sensitivity
Unauthorized access to any data node of the above subtree can disclose the operational state information of PIM on this device.¶
8. IANA Considerations
IANA has registered the following namespace URIs in the "IETF XML Registry" [RFC3688]:¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -pim -base¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -pim -bidir¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -pim -dm¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -pim -rp¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
- URI:
- urn
:ietf :params :xml :ns :yang :ietf -pim -sm¶ - Registrant Contact:
- The IESG.¶
- XML:
- N/A; the requested URI is an XML namespace.¶
IANA has registered the following YANG modules in the "YANG Module Names" registry [RFC6020]:¶
- Name:
- ietf-pim-base¶
- Namespace:
- urn
:ietf :params :xml :ns :yang :ietf -pim -base¶ - Prefix:
- pim-base¶
- Reference:
- RFC 9128¶
- Name:
- ietf-pim-bidir¶
- Namespace:
- urn
:ietf :params :xml :ns :yang :ietf -pim -bidir¶ - Prefix:
- pim-bidir¶
- Reference:
- RFC 9128¶
- Name:
- ietf-pim-dm¶
- Namespace:
- urn
:ietf :params :xml :ns :yang :ietf -pim -dm¶ - Prefix:
- pim-dm¶
- Reference:
- RFC 9128¶
9. References
9.1. Normative References
- [RFC3569]
-
Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10
.17487 , , <https:///RFC3569 www >..rfc -editor .org /info /rfc3569 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC3973]
-
Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10
.17487 , , <https:///RFC3973 www >..rfc -editor .org /info /rfc3973 - [RFC4607]
-
Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10
.17487 , , <https:///RFC4607 www >..rfc -editor .org /info /rfc4607 - [RFC4610]
-
Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, DOI 10
.17487 , , <https:///RFC4610 www >..rfc -editor .org /info /rfc4610 - [RFC5015]
-
Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10
.17487 , , <https:///RFC5015 www >..rfc -editor .org /info /rfc5015 - [RFC5059]
-
Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, DOI 10
.17487 , , <https:///RFC5059 www >..rfc -editor .org /info /rfc5059 - [RFC5060]
-
Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, DOI 10
.17487 , , <https:///RFC5060 www >..rfc -editor .org /info /rfc5060 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6242]
-
Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10
.17487 , , <https:///RFC6242 www >..rfc -editor .org /info /rfc6242 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [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 , , <https:///RFC7761 www >..rfc -editor .org /info /rfc7761 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 www >..rfc -editor .org /info /rfc8040 - [RFC8294]
-
Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10
.17487 , , <https:///RFC8294 www >..rfc -editor .org /info /rfc8294 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 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 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8349]
-
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10
.17487 , , <https:///RFC8349 www >..rfc -editor .org /info /rfc8349 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC9314]
-
Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed., Pallagatti, S., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", RFC 9314, DOI 10
.17487 , , <https:///RFC9314 www >..rfc -editor .org /info /rfc9314
9.2. Informative References
- [RFC3376]
-
Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10
.17487 , , <https:///RFC3376 www >..rfc -editor .org /info /rfc3376 - [RFC3618]
-
Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, DOI 10
.17487 , , <https:///RFC3618 www >..rfc -editor .org /info /rfc3618 - [RFC3810]
-
Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10
.17487 , , <https:///RFC3810 www >..rfc -editor .org /info /rfc3810 - [RFC5880]
-
Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10
.17487 , , <https:///RFC5880 www >..rfc -editor .org /info /rfc5880 - [RFC6388]
-
Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point
-to , RFC 6388, DOI 10-Multipoint and Multipoint -to -Multipoint Label Switched Paths" .17487 , , <https:///RFC6388 www >..rfc -editor .org /info /rfc6388 - [RFC7951]
-
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10
.17487 , , <https:///RFC7951 www >..rfc -editor .org /info /rfc7951 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8407]
-
Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10
.17487 , , <https:///RFC8407 www >..rfc -editor .org /info /rfc8407 - [RFC8706]
-
Ginsberg, L. and P. Wells, "Restart Signaling for IS-IS", RFC 8706, DOI 10
.17487 , , <https:///RFC8706 www >..rfc -editor .org /info /rfc8706
Appendix A. Data Tree Example
This appendix contains an example of an instance data tree, in JSON encoding [RFC7951], containing both configuration data and state data.¶
The configuration instance data tree for Router R3 in the above figure could be as follows:¶
The corresponding operational state data for Router R3 could be as follows:¶
Acknowledgments
The authors would like to thank Steve Baillargeon, Feng Guo, Robert Kebler, Tanmoy Kundu, and Stig Venaas for their valuable contributions.¶