PIM Working Group X. Liu Internet-Draft Ericsson Intended status: Standards Track P. McAllister Expires: January 4, 2016 Metaswitch Networks A. Peter Juniper Networks July 3, 2015 A YANG data model for Protocol-Independent Multicast (PIM) draft-mcallister-pim-yang-00 Abstract This document defines a YANG data model that can be used to configure Protocol Independent Multicast (PIM) devices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 4, 2016. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Liu, et al. Expires January 4, 2016 [Page 1] Internet-Draft PIM YANG July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2.1. Scope of model . . . . . . . . . . . . . . . . . . . . . 3 2.2. Optional capabilities . . . . . . . . . . . . . . . . . . 3 2.3. Top-level structure . . . . . . . . . . . . . . . . . . . 4 3. Unresolved Issues . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Current status of work in progress . . . . . . . . . . . 4 3.2. Position of address family in hierarchy . . . . . . . . . 4 3.3. RP configuration tree . . . . . . . . . . . . . . . . . . 6 3.4. Passive mode . . . . . . . . . . . . . . . . . . . . . . 6 4. Module Structure . . . . . . . . . . . . . . . . . . . . . . 7 4.1. PIM base module . . . . . . . . . . . . . . . . . . . . . 7 4.2. PIM RP module . . . . . . . . . . . . . . . . . . . . . . 8 4.3. PIM-SM module . . . . . . . . . . . . . . . . . . . . . . 9 4.4. PIM-DM module . . . . . . . . . . . . . . . . . . . . . . 10 4.5. PIM-BIDIR module . . . . . . . . . . . . . . . . . . . . 10 5. PIM YANG Modules . . . . . . . . . . . . . . . . . . . . . . 11 5.1. PIM base module . . . . . . . . . . . . . . . . . . . . . 11 5.2. PIM RP module . . . . . . . . . . . . . . . . . . . . . . 17 5.3. PIM-SM module . . . . . . . . . . . . . . . . . . . . . . 24 5.4. PIM-DM module . . . . . . . . . . . . . . . . . . . . . . 29 5.5. PIM-BIDIR module . . . . . . . . . . . . . . . . . . . . 31 6. TODO list . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction YANG [RFC6020] [RFC6087] is a data definition language that was introduced to model the configuration and running state of a device managed using NETCONF [RFC6241]. YANG is now also being used as a component of wider management interfaces, such as CLIs. This document defines a draft YANG data model that can be used to configure and manage Protocol-Independent Multicast (PIM) devices. Currently this model is incomplete, but it will support the core PIM protocol, as well as many other features mentioned in separate PIM RFCs. Non-core features are defined as optional in the provided data model. Liu, et al. Expires January 4, 2016 [Page 2] Internet-Draft PIM YANG July 2015 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 1.2. Terminology The terminology for describing YANG data models is found in [RFC6020]. This draft employs YANG tree diagrams, which are explained in [I-D.ietf-netmod-rfc6087bis]. 2. Design of Data Model 2.1. Scope of model The model covers PIM Sparse Mode [RFC4601], including the Source- Specfic subset [RFC3569], Dense Mode [RFC3973], and Bi-directional PIM [RFC5015]. The PIM extensions represented in the model include BSR [RFC5059] and Anycast RP [RFC4610]. The representation of some of these features is not completely specified in this draft of the data model. This model is being circulated in its current form for early oversight and review of the basic hierarchy. This model does not cover other multicast protocols such as IGMP/MLD, MSDP, mVPN, or m-LDP in-band signalling. It does not cover any configuration required to generate the MRIB. These will be covered by future Internet Drafts. 2.2. Optional capabilities This model is designed to represent the capabilities of PIM devices with various specifications, including some with basic subsets of the PIM protocol. Since a design goal of this draft is to define a data model that is capable of representing all of these implementations, these modules declare a number of features representing capabilities that not all deployed devices support. The extensive use of feature declarations should substantially simplify the capability negotiation process for a vendor's PIM implementation. Liu, et al. Expires January 4, 2016 [Page 3] Internet-Draft PIM YANG July 2015 For the same reason, wide constant ranges (for example, timer maxima and minima) will be used in the model. It is expected that vendors will augment the model with any specific restrictions that might be required. Vendors may also extend the features list with proprietary extensions. 2.3. Top-level structure This model defines several separate modules for modelling PIM configuration, defined below. Again, this separation will make it easier to express the specific capabilities of a PIM device. 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, the 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 will be essential but have a default specified, so they need not be explicitly configured. 3. Unresolved Issues 3.1. Current status of work in progress The model so far details how the PIM modules interact and covers the higher levels of their hierarchy. Some details of interface configuration, RP configuration, and PIM-ASM-specific parameters are also complete. For a list of the most substantial areas still to cover, please see the "TODO list" section below. 3.2. Position of address family in hierarchy The current draft (1) has an address-family container at a high level in the hierarchy of the model, with an interface list as a child object. This is a similar structure to the draft OSPF YANG model. There is ongoing discussion about this decision in the design team, so this may be considered unresolved. An alternative structure (2) would be for the address family to be a sub- list of the interface object. We would then provide interface configuration objects at both an address family-specific and a non- AF-specific level, exposing both options as mutually-exclusive features. This would be a similar structure to the IS-IS YANG draft. Liu, et al. Expires January 4, 2016 [Page 4] Internet-Draft PIM YANG July 2015 Another option (3) would be to expose both sets of objects, address- family specific and all-address-family, both exposed as features. Vendors could then advertise support for one or other of the features. This is the approach taken in this draft for entity-scoped parameters like graceful restart configuration. The advantages of (1) over (2) are that interface objects effectively represent {interface, address-family} pairs, which is in line with several existing implementations. Expressing interface-scoped configuration that is also address family dependent is made much easier using this model. It also may be useful to be able to configure router-wide options on an address-family basis, which would be more inconvenient if address family were a child object of the interface list. At least one deployed implementation allows configuration of basic router-scoped concepts on an address family basis. The main disadvantage of (1) compared to (2) is for implementations that configure interfaces on an address-family-independent basis with one set of configuration. This is true of some existing vendors' implementations, as PIM has a single specification for IPv4 and IPv6 address families, and for these implementations the structure (2) is more natural. For some interface parameters there is no clear use- case for address-family-specific configuration. For these implementations, the restriction that interface configuration must be address-family independent must be expressed somehow. This can be done in various ways; perhaps the easiest is a constraint of a form similar to: must ". = ../../address-family[address-family='ipv4']/ interface[interface=current()/sibling:interface]/dr-priority" { error-app-tag dr-priority-mismatch; error-message "Error: IPv6 DR priority must match IPv4 DR priority "; } Conversely, if (2) were adopted, an implementation that allowed address- family-specific configuration would have to make augmentations to the base model in order to express that flexibility. Those augmentations would not be particularly difficult to make, however. The advantage of (3) over (1) or (2) is that no such vendor augmentations or constraints would be required. It is likely that vendors' requirements under models (1) or (2) would be similar enough that option (3) would cover all needs in this area. Liu, et al. Expires January 4, 2016 [Page 5] Internet-Draft PIM YANG July 2015 The advantage of (1) or (2) over (3) is just that the model is simpler and leaner, and that feature negotiation is simpler and easier to understand. 3.3. RP configuration tree This draft of the model provides a module (currently called pim-rp) which is used for group range mapping configuration. Though some of this configuration is only relevant for some PIM modes, the pim-rp structure itself is independent of the PIM mode structures. The main advantage of this structure is that it substantially simplifies the representation of the mapping algorithm from a specific group address to its PIM mode and configuration. Validation is also easier, as only the pim-rp module itself needs to be checked if there is another entry with a conflicting or inconsistent group prefix. There are also some advantages to this approach in non-duplication of configuration parameters that are specific to multiple PIM modes, such as BSR. The current name of this module is pim-rp, as it is roughly analogous to the pimStaticRPTable in the PIM MIB, and it is currently indexed by RP. However, as it is used for some group-range-scoped configuration not directly related to RPs, and because a single RP address might need two rows in the table (for SM and BI-DIR), it might be better to call this something like pim-group-mapping and index it on group range. This is still under discussion. 3.4. Passive mode This draft contains an interface leaf 'passive', indicating that no PIM protocol messages are to be sent on the interface. For some implementations, there is a closely related concept, configurable on a PIM-mode basis, that an interface is not used to run the PIM protocol and also not used for multicast forwarding. This may be used to restrict dense-mode flooding, for example. This will likely be included as a feature in a future draft, but the details are under discussion. Liu, et al. Expires January 4, 2016 [Page 6] Internet-Draft PIM YANG July 2015 4. Module Structure 4.1. PIM base module The PIM base module defines the router-wide configuration options not specific to any PIM mode, and is included by the other modules. There are a couple of things worth mentioning here regarding where the PIM model fits in the overall routing hierarchy: 1. Our current direction is to agree to a routing-instance-centric (VRF) model as opposed to protocol-centric mainly because it fits well into the routing-instance model, and it is easier to map from the VRF-centric to the protocol-centric than the other way around due to forward references. 2. The PIM base model will augment "/rt:routing/rt:routing-instance/ rt:routing-protocols:" as opposed to augmenting "/rt:routing/ rt:routing-instance/rt:routing-protocols:/rt:routing-protocol" as the latter would allow multiple protocol instances per VRF, which does not make sense for PIM. Liu, et al. Expires January 4, 2016 [Page 7] Internet-Draft PIM YANG July 2015 module: ietf-pim-base augment /rt:routing/rt:routing-instance/rt:routing-protocols: +--rw pim +--rw graceful-restart | +--rw enabled? boolean | +--rw duration? uint16 +--rw address-family* [address-family] +--rw address-family identityref +--rw graceful-restart | +--rw enabled? boolean | +--rw duration? uint16 +--rw interfaces +--rw interface* [interface] +--rw interface if:interface-ref +--rw dr-priority? uint32 +--rw hello-interval? uint16 +--rw (hello-holdtime-or-multipler)? | +--:(holdtime) {intf-hello-holdtime}? | | +--rw hello-holdtime? uint16 | +--:(multipler) {intf-hello-multipler}? | +--rw hello-multipler? uint8 +--rw jp-interval? uint16 {intf-jp-interval}? +--rw (jp-holdtime-or-multipler)? | +--:(holdtime) {intf-jp-holdtime}? | | +--rw jp-holdtime? uint16 | +--:(multipler) {intf-jp-multipler}? | +--rw jp-multipler? uint8 +--rw propagation-delay? uint16 {intf-propagation-delay}? +--rw override-interval? uint16 {intf-override-interval}? +--rw passive? empty augment /rt:routing-state/rt:routing-instance/rt:routing-protocols: +--ro pim +--ro address-family* [address-family] +--ro address-family identityref +--ro interfaces +--ro interface* [interface] +--ro interface if:interface-ref 4.2. PIM RP module The PIM RP module contains configuration information scoped to ranges of group addresses. This does not belong in the hierarchy under any PIM mode, as it is how group ranges are assigned to PIM modes. Some of the content of the module, however, is only relevant to some modes (for example, BSR is only relevant to ASM and BIDIR). This is clarified in the module itself using "if-feature" and "when" statements. Liu, et al. Expires January 4, 2016 [Page 8] Internet-Draft PIM YANG July 2015 module: ietf-pim-rp augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--rw rp +--rw static-rp | +--rw ipv4-rp* [ipv4-addr] | | +--rw ipv4-addr inet:ipv4-address | | +--rw policy-name? string | | +--rw override? boolean {static-rp-override}? | | +--rw mode? identityref | +--rw ipv6-rp* [ipv6-addr] | +--rw ipv6-addr inet:ipv6-address | +--rw policy-name? string | +--rw mode? identityref +--rw bsr {bsr}? +--rw bsr-candidate! | +--rw (interface-or-address)? | | +--:(interface) {candidate-interface}? | | | +--rw interface if:interface-ref | | +--:(ipv4-address) {candidate-ipv4}? | | | +--rw ipv4-address inet:ipv4-address | | +--:(ipv6-address) {candidate-ipv6}? | | +--rw ipv6-address inet:ipv6-address | +--rw hash-mask-length uint8 | +--rw priority uint8 +--rw rp-candidate-interface* [interface] {candidate-interface}? | +--rw interface if:interface-ref | +--rw policy? string | +--rw mode? identityref +--rw rp-candidate-ipv4-address* [ipv4-address] {candidate-ipv4}? | +--rw ipv4-address inet:ipv4-address | +--rw policy? string | +--rw mode? identityref +--rw rp-candidate-ipv6-address* [ipv6-address] {candidate-ipv6}? +--rw ipv6-address inet:ipv6-address +--rw policy? string +--rw mode? identityref augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--ro rp 4.3. PIM-SM module This module covers Sparse Mode configuration, including PIM-ASM and PIM-SSM. Liu, et al. Expires January 4, 2016 [Page 9] Internet-Draft PIM YANG July 2015 module: ietf-pim-sm augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--rw sm +--rw asm | +--rw anycast-rp! | | +--rw ipv4 | | | +--rw ipv4-anycast-rp* [anycast-addr rp-addr] | | | +--rw anycast-addr inet:ipv4-address | | | +--rw rp-addr inet:ipv4-address | | +--rw ipv6 | | +--rw ipv6-anycast-rip* [anycast-addr rp-addr] | | +--rw anycast-addr inet:ipv6-address | | +--rw rp-addr inet:ipv6-address | +--rw spt-switch | +--rw infinity? boolean {spt-switch-infinity}? | +--rw policy-name? string {spt-switch-policy}? +--rw ssm! +--rw range-policy? string augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--ro sm 4.4. PIM-DM module This module will cover Dense Mode configuration. module: ietf-pim-dm augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--rw dm! augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family/pim-base:interfaces/ pim-base:interface: +--rw dm! augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--ro dm 4.5. PIM-BIDIR module This module will cover Bidirectional PIM configuration. Liu, et al. Expires January 4, 2016 [Page 10] Internet-Draft PIM YANG July 2015 module: ietf-pim-bidir augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--rw bidir augment /rt:routing/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family/pim-base:interfaces/ pim-base:interface: +--rw bidir! augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/ pim-base:pim/pim-base:address-family: +--ro bidir 5. PIM YANG Modules 5.1. PIM base module module ietf-pim-base { namespace "urn:ietf:params:xml:ns:yang:ietf-pim-base"; // replace with IANA namespace when assigned prefix pim-base; import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: WG Chair: Stig Venaas WG Chair: Mike McBride Editors: "; description "The module defines a collection of YANG definitions common for all PIM modes."; Liu, et al. Expires January 4, 2016 [Page 11] Internet-Draft PIM YANG July 2015 revision 2015-06-22 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature global-graceful-restart { description "Global configuration for graceful restart support."; } feature intf-hello-holdtime { description "Support configuration of interface hello holdtime."; } feature intf-hello-multipler { description "Support configuration of interface hello multipler."; } feature intf-jp-interval { description "Support configuration of interface join prune interval."; } feature intf-jp-holdtime { description "Support configuration of interface join prune holdtime."; } feature intf-jp-multipler { description "Support configuration of interface join prune multipler."; } feature intf-propagation-delay { description "Support configuration of interface propagation delay."; } feature intf-override-interval { description "Support configuration of interface override interval."; Liu, et al. Expires January 4, 2016 [Page 12] Internet-Draft PIM YANG July 2015 } feature per-af-graceful-restart { description "Per AF configuration for graceful restart support."; } /* * Identities */ /* * Groupings */ grouping global-attributes { description "A Grouping defining global configuration attributes."; uses graceful-restart-container { if-feature global-graceful-restart; } } grouping graceful-restart-container { description "A grouping defining a container of graceful restart attributes."; container graceful-restart { leaf enabled { type boolean; description "Enable or disable graceful restart."; } leaf duration { type uint16; units "seconds"; description "Maximum time for graceful restart to finish."; } description "Container of graceful restart attributes."; } } grouping interface-attributes { description "A grouping defining interface attributes."; leaf dr-priority { type uint32; Liu, et al. Expires January 4, 2016 [Page 13] Internet-Draft PIM YANG July 2015 description "DR priority"; } leaf hello-interval { type uint16; description "Hello interval"; } choice hello-holdtime-or-multipler { description "Use holdtime or multipler"; case holdtime { if-feature intf-hello-holdtime; leaf hello-holdtime { type uint16; description "Hello holdtime"; } } case multipler { if-feature intf-hello-multipler; leaf hello-multipler { type uint8; description "Hello multipler"; } } } leaf jp-interval { if-feature intf-jp-interval; type uint16; description "Join prune interval"; } choice jp-holdtime-or-multipler { description "Use holdtime or multipler"; case holdtime { if-feature intf-jp-holdtime; leaf jp-holdtime { type uint16; description "Join prune holdtime"; } } case multipler { if-feature intf-jp-multipler; leaf jp-multipler { type uint8; description "Join prune multipler"; } } } leaf propagation-delay { if-feature intf-propagation-delay; type uint16; Liu, et al. Expires January 4, 2016 [Page 14] Internet-Draft PIM YANG July 2015 description "Propagation description"; } leaf override-interval { if-feature intf-override-interval; type uint16; description "Override interval"; } leaf passive { type empty; description "Specifies that no PIM messages are sent out of the PIM interface, but the interface can be included in a multicast forwarding entry."; } } grouping per-af-attributes { description "A grouping defining per address family attributes."; uses graceful-restart-container { if-feature per-af-graceful-restart; } } /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols" { description "PIM augmentation to routing instance configuration."; container pim { description "PIM configuration data."; uses global-attributes; list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; uses per-af-attributes; container interfaces { description Liu, et al. Expires January 4, 2016 [Page 15] Internet-Draft PIM YANG July 2015 "Containing a list of interfaces."; list interface { key "interface"; description "List of pim interfaces."; leaf interface { type if:interface-ref; description "Reference to an entry in the global interface list."; } uses interface-attributes; } // interface } } // address-family } // pim } // augment /* * Operational state data nodes */ augment "/rt:routing-state/rt:routing-instance/" + "rt:routing-protocols" { description "PIM augmentation to routing instance state."; container pim { description "PIM state data."; list address-family { key "address-family"; description "Each list entry for one address family."; uses rt:address-family; container interfaces { description "Containing a list of interfaces."; list interface { key "interface"; description "List of pim interfaces."; leaf interface { type if:interface-ref; description "Reference to an entry in the global interface list."; Liu, et al. Expires January 4, 2016 [Page 16] Internet-Draft PIM YANG July 2015 } } // interface } } // address-family } // pim } // augment /* * RPCs */ /* * Notifications */ } 5.2. PIM RP module module ietf-pim-rp { namespace "urn:ietf:params:xml:ns:yang:ietf-pim-rp"; // replace with IANA namespace when assigned prefix pim-rp; import ietf-inet-types { prefix "inet"; } import ietf-interfaces { prefix "if"; } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: Liu, et al. Expires January 4, 2016 [Page 17] Internet-Draft PIM YANG July 2015 WG Chair: Stig Venaas WG Chair: Mike McBride Editors: "; description "The YANG module defines a PIM RP (Rendezvous Point) model."; revision 2015-07-01 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature bsr { description "This feature indicates that the system supports BSR."; } feature static-rp-override { description "This feature indicates that the system supports configuration of static RP override."; } feature candidate-interface { description "This feature indicates that the system supports using an interface to configure a BSR or RP candidate."; } feature candidate-ipv4 { description "This feature indicates that the system supports using an IPv4 address to configure a BSR or RP candidate."; } feature candidate-ipv6 { description "This feature indicates that the system supports using an IPv6 address to configure a BSR or RP candidate."; Liu, et al. Expires January 4, 2016 [Page 18] Internet-Draft PIM YANG July 2015 } /* * Identities */ identity rp-mode { description "The mode of an RP, which can be SM (Sparse Mode) or BIDIR (bi-directional)."; } /* * Groupings */ /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM RP augmentation."; container rp { description "PIM RP configuration data."; container static-rp { description "Containing static RP attributes."; list ipv4-rp { when "../../../address-family = 'rt:ipv4'" { description "Only applicable to ipv4 address family."; } key "ipv4-addr"; description "A list of IPv4 RP addresses."; leaf ipv4-addr { type inet:ipv4-address; description "Specifies a static RP address."; } leaf policy-name { type string; description "Static RP policy."; Liu, et al. Expires January 4, 2016 [Page 19] Internet-Draft PIM YANG July 2015 } leaf override { if-feature static-rp-override; type boolean; description "When there is a conflict between static RP and dynamic RP, setting this attribute to 'true' will ask the system to use static RP."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } } list ipv6-rp { when "../../../address-family = 'rt:ipv6'" { description "Only applicable to ipv6 address family."; } key "ipv6-addr"; description "A list of IPv6 RP addresses."; leaf ipv6-addr { type inet:ipv6-address; description "Specifies a static RP address."; } leaf policy-name { type string; description "Static RP policy."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } } } container bsr { if-feature bsr; Liu, et al. Expires January 4, 2016 [Page 20] Internet-Draft PIM YANG July 2015 description "Containing BSR (BootStrap Router) attributes."; container bsr-candidate { presence "Present to serve as a BSR candidate"; description "BSR candidate attributes."; choice interface-or-address { description "Use either interface or ip-address."; case interface { if-feature candidate-interface; leaf interface { type if:interface-ref; mandatory true; description "Interface to be used by BSR."; } } case ipv4-address { when "../../../../address-family = 'rt:ipv4'" { description "Only applicable to ipv4 address family."; } if-feature candidate-ipv4; leaf ipv4-address { type inet:ipv4-address; mandatory true; description "IP address to be used by BSR."; } } case ipv6-address { when "../../../../address-family = 'rt:ipv6'" { description "Only applicable to ipv6 address family."; } if-feature candidate-ipv6; leaf ipv6-address { type inet:ipv6-address; mandatory true; description "IP address to be used by BSR."; } } } Liu, et al. Expires January 4, 2016 [Page 21] Internet-Draft PIM YANG July 2015 leaf hash-mask-length{ type uint8 { range "0..32"; } mandatory true; description "Value contained in BSR messages used by all routers to hash (map) to an RP."; } leaf priority { type uint8 { range "0..255"; } mandatory true; description "BSR election priority among different candidate BSRs. A larger value has a higher priority over a smaller value."; } } // bsr-candidate list rp-candidate-interface { if-feature candidate-interface; key "interface"; description "A list of RP candidates"; leaf interface { type if:interface-ref; description "Interface that the RP candidate uses."; } leaf policy { type string; description "ACL policy used to filter group addresses."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } } list rp-candidate-ipv4-address { Liu, et al. Expires January 4, 2016 [Page 22] Internet-Draft PIM YANG July 2015 when "../../../address-family = 'rt:ipv4'" { description "Only applicable to ipv4 address family."; } if-feature candidate-ipv4; key "ipv4-address"; description "A list of RP candidates"; leaf ipv4-address { type inet:ipv4-address; description "IPv4 address that the RP candidate uses."; } leaf policy { type string; description "ACL policy used to filter group addresses."; } leaf mode { type identityref { base rp-mode; } description "RP mode."; } } list rp-candidate-ipv6-address { when "../../../address-family = 'rt:ipv6'" { description "Only applicable to ipv6 address family."; } if-feature candidate-ipv6; key "ipv6-address"; description "A list of RP candidates"; leaf ipv6-address { type inet:ipv6-address; description "IPv6 address that the RP candidate uses."; } leaf policy { type string; description "ACL policy used to filter group addresses."; } Liu, et al. Expires January 4, 2016 [Page 23] Internet-Draft PIM YANG July 2015 leaf mode { type identityref { base rp-mode; } description "RP mode."; } } } // bsr } // rp } // augment /* * Operational state data nodes */ augment "/rt:routing-state/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM SM state."; container rp { description "PIM RP state data."; } // rp } // augment /* * RPCs */ /* * Notifications */ } 5.3. PIM-SM module module ietf-pim-sm { namespace "urn:ietf:params:xml:ns:yang:ietf-pim-sm"; // replace with IANA namespace when assigned prefix pim-sm; import ietf-inet-types { prefix "inet"; Liu, et al. Expires January 4, 2016 [Page 24] Internet-Draft PIM YANG July 2015 } import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } import ietf-pim-rp { prefix "pim-rp"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: WG Chair: Stig Venaas WG Chair: Mike McBride Editors: "; description "The YANG module defines a sparse mode PIM model."; revision 2015-07-01 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ feature spt-switch-infinity { description "This feature indicates that the system supports configuration choice whether to trigger the switchover from the rpt to the spt."; } Liu, et al. Expires January 4, 2016 [Page 25] Internet-Draft PIM YANG July 2015 feature spt-switch-policy { description "This feature indicates that the system supports configuring policy for the switchover from the rpt to the spt."; } /* * Identities */ identity sm { base pim-rp:rp-mode; description "SM (Spars Mode)."; } /* * Groupings */ /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM SM augmentation."; container sm { description "PIM SM configuration data."; container asm { description "ASM (Any Source Multicast) attributes."; container anycast-rp { presence "Present to enable anycast RP."; description "Anycast RP attributes."; container ipv4 { when "../../../../address-family = 'rt:ipv4'" { description "Only applicable to ipv4 address family."; } description Liu, et al. Expires January 4, 2016 [Page 26] Internet-Draft PIM YANG July 2015 "IPv4 attributes. Only applicable when pim-base:address-family is ipv4."; list ipv4-anycast-rp { key "anycast-addr rp-addr"; description "A list of anycast RP setttings."; leaf anycast-addr { type inet:ipv4-address; description "IP address of the anycast RP set. This IP address is used by the multicast groups or sources to join or register."; } leaf rp-addr { type inet:ipv4-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register messages are forwarded."; } } } container ipv6 { when "../../../../address-family = 'rt:ipv6'" { description "Only applicable to ipv6 address family."; } description "IPv6 attributes. Only applicable when pim-base:address-family is ipv6."; list ipv6-anycast-rip { key "anycast-addr rp-addr"; description "A list of anycast RP setttings."; leaf anycast-addr { type inet:ipv6-address; description "IP address of the anycast RP set. This IP address is used by the multicast groups or sources to join or register."; } leaf rp-addr { type inet:ipv6-address; description "IP address of the router configured with anycast RP. This is the IP address where the Register Liu, et al. Expires January 4, 2016 [Page 27] Internet-Draft PIM YANG July 2015 messages are forwarded."; } } } } container spt-switch { description "SPT (Shortest Path Tree) switching attributes."; leaf infinity { if-feature spt-switch-infinity; type boolean; description "The receiver's dr never triggers the switchover from the rpt to the spt."; } leaf policy-name { if-feature spt-switch-policy; type string; description "Switch policy."; } } } // asm container ssm { presence "Present to enable SSM (Source-Specific Multicast)."; description "SSM (Source-Specific Multicast) attributes."; leaf range-policy { type string; description "Policy used to define SSM address range."; } } // ssm } // sm } // augment /* * Operational state data nodes */ augment "/rt:routing-state/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description Liu, et al. Expires January 4, 2016 [Page 28] Internet-Draft PIM YANG July 2015 "PIM SM state."; container sm { description "PIM SM state data."; } // sm } // augment /* * RPCs */ /* * Notifications */ } 5.4. PIM-DM module module ietf-pim-dm { namespace "urn:ietf:params:xml:ns:yang:ietf-pim-dm"; // replace with IANA namespace when assigned prefix pim-dm; import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } organization "IETF PIM Working Group"; contact "WG Web: WG List: WG Chair: Stig Venaas WG Chair: Mike McBride Editors: "; Liu, et al. Expires January 4, 2016 [Page 29] Internet-Draft PIM YANG July 2015 description "The YANG module defines a DM (Dense Mode) PIM model."; revision 2015-06-22 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ /* * Identities */ /* * Groupings */ /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM DM augmentation."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; } // Dm } // augment augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family/pim-base:interfaces/" + "pim-base:interface" { description "PIM DM augmentation to PIM base interface."; container dm { presence "Present to enable dense-mode."; description "PIM DM configuration data."; Liu, et al. Expires January 4, 2016 [Page 30] Internet-Draft PIM YANG July 2015 } // sm } // augment /* * Operational state data nodes */ augment "/rt:routing-state/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM DM state."; container dm { description "PIM DM state data."; } // dm } // augment /* * RPCs */ /* * Notifications */ } 5.5. PIM-BIDIR module module ietf-pim-bidir { namespace "urn:ietf:params:xml:ns:yang:ietf-pim-bidir"; // replace with IANA namespace when assigned prefix pim-bidir; import ietf-routing { prefix "rt"; } import ietf-pim-base { prefix "pim-base"; } import ietf-pim-rp { prefix "pim-rp"; } Liu, et al. Expires January 4, 2016 [Page 31] Internet-Draft PIM YANG July 2015 organization "IETF PIM Working Group"; contact "WG Web: WG List: WG Chair: Stig Venaas WG Chair: Mike McBride Editors: "; description "The YANG module defines a BIDIR (Bidirectional) mode PIM model."; revision 2015-06-22 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for PIM"; } /* * Features */ /* * Identities */ identity bidir { base pim-rp:rp-mode; description "BIDIR (Bidirectional) mode."; } /* * Groupings */ /* * Configuration data nodes */ augment "/rt:routing/rt:routing-instance/" Liu, et al. Expires January 4, 2016 [Page 32] Internet-Draft PIM YANG July 2015 + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM BIDIR augmentation."; container bidir { description "PIM BIDIR configuration data."; } // bidir } // augment augment "/rt:routing/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family/pim-base:interfaces/" + "pim-base:interface" { description "PIM BIDIR augmentation."; container bidir { presence "Present to enable BIDIR mode."; description "PIM BIDIR configuration data."; } // bidir } // augment /* * Operational state data nodes */ augment "/rt:routing-state/rt:routing-instance/" + "rt:routing-protocols/pim-base:pim/" + "pim-base:address-family" { description "PIM BIDIR state."; container bidir { description "PIM BIDIR state data."; } // bidir } // augment /* * RPCs */ /* * Notifications */ } Liu, et al. Expires January 4, 2016 [Page 33] Internet-Draft PIM YANG July 2015 6. TODO list In this draft, several aspects of the model are incomplete. The PIM- DM and BI-DIR modules are just placeholders for now to demonstrate the hierarchy of the model. Other things the draft will include when complete but does not yet include: o State reporting o Notifications o Neighbor configuration o Interaction with BFD protocol o Constraints (constant ranges, validation) o State-limiting and policy o Statistics. For these subjects, we will employ the same design principles of expressing a highly general model; vendors may use features and add augmentations in order to express which subsets of this general model are valid in their implementations. 7. Security Considerations The data model defined does not introduce any security implications. This draft does not change any underlying security issues inherent in [I-D.ietf-netmod-routing-cfg]. 8. IANA Considerations TBD 9. Acknowledgements The authors would like to thank Steve Baillargeon, Guo Feng, Hu Fangwei, Robert Kebler, Tanmoy Kundu, Liu Yisong, Mahesh Sivakumar, and Stig Venaas for their valuable contributions. 10. References Liu, et al. Expires January 4, 2016 [Page 34] Internet-Draft PIM YANG July 2015 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [I-D.ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", draft-ietf-netmod-rfc6087bis-03 (work in progress), June 2015. 10.2. Informative References [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011. Liu, et al. Expires January 4, 2016 [Page 35] Internet-Draft PIM YANG July 2015 [I-D.ietf-netmod-routing-cfg] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", draft-ietf-netmod-routing-cfg-19 (work in progress), May 2015. Authors' Addresses Liu Xufeng Ericsson 1595 Spring Hill Road, Suite 500 Vienna VA 22182 USA EMail: xufeng.liu@ericsson.com Pete McAllister Metaswitch Networks 100 Church Street Enfield EN2 6BQ UK EMail: pete.mcallister@metaswitch.com Anish Peter Juniper Networks Electra, Exora Business Park Bangalore, KA 560103 India EMail: anishp@juniper.net Liu, et al. Expires January 4, 2016 [Page 36]