A YANG data model for Protocol-Independent Multicast (PIM)
draft-mcallister-pim-yang-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Xufeng Liu , Pete McAllister , Anish Peter | ||
| Last updated | 2015-07-03 | ||
| Replaced by | draft-ietf-pim-yang, draft-ietf-pim-yang, RFC 9128 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mcallister-pim-yang-00
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
<CODE BEGINS>
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: <http://tools.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
WG Chair: Stig Venaas
<mailto:stig@venaas.com>
WG Chair: Mike McBride
<mailto:mmcbride7@gmail.com>
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
*/
}
<CODE ENDS>
5.2. PIM RP module
<CODE BEGINS>
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: <http://tools.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
Liu, et al. Expires January 4, 2016 [Page 17]
Internet-Draft PIM YANG July 2015
WG Chair: Stig Venaas
<mailto:stig@venaas.com>
WG Chair: Mike McBride
<mailto:mmcbride7@gmail.com>
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
*/
}
<CODE ENDS>
5.3. PIM-SM module
<CODE BEGINS>
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: <http://tools.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
WG Chair: Stig Venaas
<mailto:stig@venaas.com>
WG Chair: Mike McBride
<mailto:mmcbride7@gmail.com>
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
*/
}
<CODE ENDS>
5.4. PIM-DM module
<CODE BEGINS>
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: <http://tools.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
WG Chair: Stig Venaas
<mailto:stig@venaas.com>
WG Chair: Mike McBride
<mailto:mmcbride7@gmail.com>
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
*/
}
<CODE ENDS>
5.5. PIM-BIDIR module
<CODE BEGINS>
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: <http://tools.ietf.org/wg/pim/>
WG List: <mailto:pim@ietf.org>
WG Chair: Stig Venaas
<mailto:stig@venaas.com>
WG Chair: Mike McBride
<mailto:mmcbride7@gmail.com>
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
*/
}
<CODE ENDS>
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]