wdiff rfc7910.original rfc7910.txt

Network Working Group
Independent Submission W. Zhou
Internet-Draft cisco
Request for Comments: 7910 Cisco Systems
Intended status:
Category: Informational February 23, June 2016
Expires: August 26, 2016

VRRP PIM
ISSN: 2070-1721

Interoperability
draft-zhou-pim-vrrp-06.txt between the Virtual Router Redundancy Protocol and PIM

Abstract

This document introduces VRRP Aware VRRP-aware PIM, a redundancy mechanism for
the Protocol Independent Multicast (PIM) to interoperate with the
Virtual Router Redundancy Protocol (VRRP). It allows PIM to track
VRRP state and to preserve multicast traffic upon failover in a
redundant network with virtual routing groups enabled. The mechanism
described in this document is based on Cisco IOS software
implementation.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 August 26, 2016.
http://www.rfc-editor.org/info/rfc7910.

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Tracking and Failover . . . . . . . . . . . . . . . . . . . . 3
3. PIM Assert Metric Auto-Adjustment . . . . . . . . . . . . . . 4
4. DF Election for BiDir Group . . . . . . . . . . . . . . . . . 4
5. Tracking Multiple VRRP Groups on an Interface . . . . . . . . 5
6. Support of HSRP . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . Informative References . . . . . . . . . . . . . . . . . . . 5
9. 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6

1. Introduction

The Virtual Router Redundancy Protocol (VRRP) [RFC5798] is a
redundancy protocol for establishing a fault-tolerant default router.
The protocol establishes a framework between network devices in order
to achieve default device failover if the primary devices becomes become
inaccessible.

PIM [RFC4601]

Protocol Independent Multicast (PIM) [RFC7761] has no inherent
redundancy capabilities and its operation is completely independent
of VRRP group states. As a result, IP multicast traffic is forwarded not
necessarily forwarded by the same device as that is elected by VRRP.
The VRRP Aware VRRP-aware PIM feature provides consistent IP multicast
forwarding in a redundant network with virtual routing groups
enabled.

In a multi-access segment (such as LAN), the elected PIM designated
router (DR)
election is unaware of the redundancy configuration, and the
elected DR and VRRP master router (MR) may not be the same router. same. In order
to ensure that the PIM DR is always able to forward a PIM Join/Prune
(J/P) message towards RP Rendezvous Point (RP) or FHR, first-hop router, the
VRRP MR becomes the PIM DR (if there is only one VRRP group). PIM is
responsible for adjusting the DR priority based on the group state.
When a failover occurs, multicast states are created on the new MR
elected by the VRRP group and the MR assumes responsibility for the
routing and forwarding of all the traffic addressed to the VRRP
virtual IP address (vIP). This ensures that the PIM DR runs on the
same router as the VRRP MR and maintains
mroute multicast routing (mroute)
states. It enables multicast traffic to be forwarded through the
VRRP MR, allowing PIM to leverage VRRP redundancy, avoid potential
duplicate traffic, and enable failover, depending on the VRRP states
in the router.

This mechanism can be safely deployed into a PIM network without
changing the behavior of other routers. When only a specific set of
routers enabled enable this feature, a user can configure PIM interfaces to
track state change state-change events of desired VRRP group(s). When a router
becomes the VRRP MR, the PIM component applies the user-defined DR
priority value to the interface in order to make it PIM DR. Other
routers will not break the functionality of this feature, as long as
their configured DR priority do does not conflict with the participating
routers. When deployed in a PIM transit network, downstream routers
should configure the static route to use vIP as the next-hop address
for PIM J/P messages in order to take advantage of this feature. If
dynamic routing is used and the next-hop address is selected by
unicast routing information as described in [RFC5294], then they these
routes cannot leverage the VRRP redundancy and failover mechanism.
These downstream routers, however, do not have to support this new
feature and there is no additional configuration or coordination
required from a manageability point of view. This mechanism does not
change any bit on the wire, and it has been implemented on Cisco IOS
software.

2. Tracking and Failover

Without the mechanisms described in this document, a PIM component
will send PIM J/P messages with the DR's IP address to upstream
routers. A GenId (Generation Identifier) in a PIM Hello message is
randomly selected when the router boots and remains the same as long
as the router is up. A PIM neighbor reboot can easily be detected if
its GenId is different from before, before; in this
case case, the PIM J/P and RP-Set RP-
Set information can be redistributed to the new rebooted neighbor. With VRRP aware
the VRRP-aware PIM mechanism enabled, the PIM component listens to
the state change state-change notifications from VRRP and automatically adjusts
the priority of the PIM DR based on the VRRP
state, state and ensures the
VRRP MR (if there is only one VRRP group) becomes the DR of the LAN.
If there are multiple VRRP groups, the DR is determined by user-configured the user-
configured priority value.

Upon failover, the PIM component triggers communication between
upstream and downstream routers in order to create mroute states on
the new VRRP MR. The PIM component sends an additional PIM Hello
message using the VRRP vIP as the source address for each active VRRP
group when a router becomes the VRRP Master. MR. The PIM Hello message with
a new GenID will trigger other routers to respond to the VRRP
failover event in the same way of as the PIM neighbor reboot event as
described in [RFC5294]. Specifically, when a downstream router
receives this PIM Hello message, it will add the source IP address
(in this case the VRRP vIP) into its PIM neighbor list, list and
immediately send triggered PIM J/P messages towards vIP. Upstream
routers will process PIM J/P messages based on the VRRP group state.

If the PIM J/P next-hop address matches the VRRP vIP, only the
current VRRP MR will process the PIM J/P messages. This allows all
PIM J/P messages to reach the VRRP group vIP and minimizes changes
and configurations at the downstream routers.

Alternatively, the implementation can choose to have all VRRP passive
routers maintain mroute states and record the GenID of the current
MR. When a passive router becomes the MR, it uses the existing
mroute states and the recorded MR GenID in its PIM Hello message.
This will avoid resending PIM J/P messages upon failover and eliminates will
eliminate the requirement of an additional PIM Hello with vIP. There
is no change in
on-wire on-the-wire behavior or in the PIM and VRRP message
format.

3. PIM Assert Metric Auto-Adjustment

It is possible that, after the VRRP Master switched MR switches from router A to B; B, A is
would still forwarding forward multicast traffic traffic, which will result in duplicate
traffic and
traffic. The PIM Assert mechanism will kick in. in because PIM Assert
with redundancy is enabled.

o If there is only one VRRP group, passive routers will send an
arbitrary penalty metric preference (PIM_ASSERT_INFINITY - 1) and
make MR the Assert winner.

o If there are multiples VRRP groups configured on an interface, the
Assert metric preference will be (PIM_ASSERT_INFINITY - 1) if and
only if all VRRP groups are in passive Passive state.

o If there is at least one VRRP group is in Active, Active state, then the
original Assert metric preference will be used. That is, the
winner will be selected between routers using their real Assert
metric preference with at least one active VRRP Group, just like as if no
VRRP is involved.

4. DF Election for BiDir Group

Change to DF Designated Forwarder (DF) offer/winner metric is handled
similarly to PIM Assert handling with VRRP.

o If there is only one VRRP group, passive routers will send a large
penalty metric preference in Offer an offer (PIM_BIDIR_INFINITY_PREF- 1)
and make MR the DF winner.

o If there are multiples VRRP groups configured on an interface,
Offer the
offer metric preference will be (PIM_BIDIR_INFINITY_PREF- 1) if
and only if all VRRP groups are in passive. Passive state.

o If there is at least one VRRP group is in Active, Active state, then the
original
Offer offer metric preference to RP will be used. That is, the
winner will be selected between routers using their real Offer offer
metric, just as if no VRRP is involved.

5. Tracking Multiple VRRP Groups on an Interface

User

A user can configure a PIM component to track more than one VRRP
groups on an interface. This allows other applications to exploit the PIM/
VRRP
PIM/VRRP interoperability to achieve various goals (e.g., load
balancing). Since each VRRP groups group that is configured on an interface
could be in different states at any moment, the DR priority is
adjusted. The PIM Assert metric and PIM Bidir BiDir DF metric should be
adjusted if and only if all VRRP groups that are configured on an
interface are in passive Passive (non-Active) states to ensure that
interfaces with all-passive VRRP groups will do not win
in DR, Assert Assert, and DF
election. In other words, the DR, Assert, and DF winner winners will be
elected among the interfaces with at least one Active active VRRP group.

6. Support of HSRP

Although there are differences between VRRP and the Hot Standby
Router Protocol (HSRP) [RFC2281] -- including the number of backup
(standby) routers, virtual IP address address, and timer intervals, intervals -- the
proposed scheme can also enable HSRP aware HSRP-aware PIM with similar failover
and the tracking mechanism described in this draft. document.

7. Security Considerations

The proposed tracking mechanism does not discuss adding
authentication to the protocols and introduces no new negative impact
or threats on security to PIM in either SSM (Source-Specific
Multicast) or ASM (Any-Source Multicast) mode. Note that VRRP
messages from malicious nodes could cause unexpected behaviors such
as multiple Masters MRs and PIM DRs DRs, which are associated with VRRP
specific VRRP-specific
security issues. To mitigate the vulnerability of frequent VRRP and
PIM DR state change from malicious attack, an implementation can
choose to enable VRRP preemption such that a higher-priority VRRP
backup router does not take over for a lower-priority MR, MR; this will
reduce the state change state-change notifications to a PIM component and
subsequent mroute state change. changes. Detailed analysis of PIM and VRRP
security is provided in [RFC5294] and [RFC5798].

8. IANA Considerations

This document has no IANA actions.

9. Acknowledgments

I would like to give a special thank you and appreciation to Stig
Venaas for his ideas and comments in this draft.

10. Informative References

[RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot
Standby Router Protocol (HSRP)", RFC 2281,
DOI 10.17487/RFC2281, March 1998,
<http://www.rfc-editor.org/info/rfc2281>.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>.

[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294,
DOI 10.17487/RFC5294, August 2008,
<http://www.rfc-editor.org/info/rfc5294>.

[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010,
<http://www.rfc-editor.org/info/rfc5798>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.

Acknowledgments

I would like to give a special thank you and appreciation to Stig
Venaas for his ideas and comments in this document.

Author's Address

Wei Zhou
cisco
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA

Email: weizho2@cisco.com zhouweiisu@gmail.com