idnits 2.17.1 draft-zhou-pim-vrrp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2016) is 2984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Zhou 3 Internet-Draft cisco Systems 4 Intended status: Informational February 23, 2016 5 Expires: August 26, 2016 7 VRRP PIM Interoperability 8 draft-zhou-pim-vrrp-06.txt 10 Abstract 12 This document introduces VRRP Aware PIM, a redundancy mechanism for 13 the Protocol Independent Multicast (PIM) to interoperate with Virtual 14 Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state 15 and to preserve multicast traffic upon failover in a redundant 16 network with virtual routing groups enabled. The mechanism described 17 in this document is based on Cisco IOS software implementation. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Tracking and Failover . . . . . . . . . . . . . . . . . . . . 3 55 3. PIM Assert Metric Auto-Adjustment . . . . . . . . . . . . . . 4 56 4. DF Election for BiDir Group . . . . . . . . . . . . . . . . . 4 57 5. Tracking Multiple VRRP Groups on an Interface . . . . . . . . 5 58 6. Support of HSRP . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 10. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Virtual Router Redundancy Protocol (VRRP) [RFC5798] is a redundancy 68 protocol for establishing a fault-tolerant default router. The 69 protocol establishes a framework between network devices in order to 70 achieve default device failover if the primary devices becomes 71 inaccessible. 73 PIM [RFC4601] has no inherent redundancy capabilities and its 74 operation is completely independent of VRRP group states. As a 75 result, IP multicast traffic is forwarded not necessarily by the same 76 device as is elected by VRRP. The VRRP Aware PIM feature provides 77 consistent IP multicast forwarding in a redundant network with 78 virtual routing groups enabled. 80 In a multi-access segment (such as LAN), PIM designated router (DR) 81 election is unaware of the redundancy configuration, and the elected 82 DR and VRRP master router (MR) may not be the same router. In order 83 to ensure that the PIM DR is always able to forward PIM Join/Prune 84 (J/P) message towards RP or FHR, the VRRP MR becomes the PIM DR (if 85 there is only one VRRP group). PIM is responsible for adjusting DR 86 priority based on the group state. When a failover occurs, multicast 87 states are created on the new MR elected by the VRRP group and the MR 88 assumes responsibility for the routing and forwarding of all the 89 traffic addressed to the VRRP virtual IP address (vIP). This ensures 90 the PIM DR runs on the same router as the VRRP MR and maintains 91 mroute states. It enables multicast traffic to be forwarded through 92 the VRRP MR, allowing PIM to leverage VRRP redundancy, avoid 93 potential duplicate traffic, and enable failover, depending on the 94 VRRP states in the router. 96 This mechanism can be safely deployed into a PIM network without 97 changing the behavior of other routers. When only a specific set of 98 routers enabled this feature, user can configure PIM interfaces to 99 track state change events of desired VRRP group(s). When a router 100 becomes VRRP MR, PIM component applies the user-defined DR priority 101 value to the interface in order to make it PIM DR. Other routers 102 will not break the functionality of this feature, as long as their 103 configured DR priority do not conflict with the participating 104 routers. When deployed in PIM transit network, downstream routers 105 should configure static route to use vIP as next-hop address for PIM 106 J/P messages in order to take advantage of this feature. If dynamic 107 routing is used and next-hop address is selected by unicast routing 108 information as described in [RFC5294], then they cannot leverage the 109 VRRP redundancy and failover mechanism. These downstream routers, 110 however, do not have to support this new feature and there is no 111 additional configuration or coordination required from manageability 112 point of view. This mechanism does not change any bit on the wire, 113 and it has been implemented on Cisco IOS software. 115 2. Tracking and Failover 117 Without the mechanisms described in this document, a PIM component 118 will send PIM J/P with DR's IP address to upstream routers. A GenId 119 in PIM Hello message is randomly selected when the router boots and 120 remains the same as long as the router is up. A PIM neighbor reboot 121 can easily be detected if its GenId is different from before, in this 122 case PIM J/P and RP-Set information can be redistributed to the new 123 rebooted neighbor. With VRRP aware PIM mechanism enabled, PIM 124 component listens to the state change notifications from VRRP and 125 automatically adjusts the priority of the PIM DR based on the VRRP 126 state, and ensures VRRP MR (if there is only one VRRP group) becomes 127 the DR of the LAN. If there are multiple VRRP groups, the DR is 128 determined by user-configured priority value. 130 Upon failover, PIM component triggers communication between upstream 131 and downstream routers in order to create mroute states on the new 132 VRRP MR. PIM component sends an additional PIM Hello message using 133 the VRRP vIP as the source address for each active VRRP group when a 134 router becomes VRRP Master. The PIM Hello message with new GenID 135 will trigger other routers to respond to the VRRP failover event in 136 the same way of PIM neighbor reboot event as described in [RFC5294]. 137 Specifically, when a downstream router receives this PIM Hello 138 message, it will add the source IP address (in this case the VRRP 139 vIP) into its PIM neighbor list, and immediately send triggered PIM 140 J/P messages towards vIP. Upstream routers will process PIM J/P 141 based on VRRP group state. If PIM J/P next-hop address matches VRRP 142 vIP, only the current VRRP MR will process the PIM J/P messages. 144 This allows all PIM J/P to reach the VRRP group vIP and minimizes 145 changes and configurations at the downstream routers. 147 Alternatively, implementation can choose to have all VRRP passive 148 routers maintain mroute states and record the GenID of current MR. 149 When a passive router becomes MR, it uses the existing mroute states 150 and the recorded MR GenID in its PIM Hello message. This will avoid 151 resending PIM J/P messages upon failover and eliminates the 152 requirement of additional PIM Hello with vIP. There is no change in 153 on-wire behavior or in the PIM and VRRP message format. 155 3. PIM Assert Metric Auto-Adjustment 157 It is possible that, after VRRP Master switched from A to B; A is 158 still forwarding multicast traffic which will result in duplicate 159 traffic and PIM Assert mechanism will kick in. PIM Assert with 160 redundancy is enabled. 162 o If only one VRRP group, passive routers will send arbitrary 163 penalty metric preference (PIM_ASSERT_INFINITY - 1) and make MR 164 the Assert winner. 166 o If there are multiples VRRP groups configured on an interface, 167 Assert metric preference will be (PIM_ASSERT_INFINITY - 1) if and 168 only if all VRRP groups are in passive state. 170 o If there is at least one VRRP group is in Active, then original 171 Assert metric preference will be used. That is, winner will be 172 selected between routers using their real Assert metric preference 173 with at least one active VRRP Group, just like no VRRP is 174 involved. 176 4. DF Election for BiDir Group 178 Change to DF offer/winner metric is handled similarly to PIM Assert 179 handling with VRRP. 181 o If only one VRRP group, passive routers will send a large penalty 182 metric preference in Offer (PIM_BIDIR_INFINITY_PREF- 1) and make 183 MR the DF winner. 185 o If there are multiples VRRP groups configured on an interface, 186 Offer metric preference will be (PIM_BIDIR_INFINITY_PREF- 1) if 187 and only if all VRRP groups are in passive. 189 o If there is at least one VRRP group is in Active, then original 190 Offer metric preference to RP will be used. That is, winner will 191 be selected between routers using their real Offer metric, just as 192 no VRRP is involved. 194 5. Tracking Multiple VRRP Groups on an Interface 196 User can configure PIM component to track more than one VRRP groups 197 on an interface. This allows other applications to exploit the PIM/ 198 VRRP interoperability to achieve various goals (e.g., load 199 balancing). Since each VRRP groups configured on an interface could 200 be in different states at any moment, the DR priority is adjusted. 201 PIM Assert metric and PIM Bidir DF metric if and only if all VRRP 202 groups configured on an interface are in passive (non-Active) states 203 to ensure that interfaces with all-passive VRRP groups will not win 204 in DR, Assert and DF election. In other words, DR, Assert, DF winner 205 will be elected among the interfaces with at least one Active VRRP 206 group. 208 6. Support of HSRP 210 Although there are differences between VRRP and Hot Standby Router 211 Protocol (HSRP) [RFC2281] including number of backup (standby) 212 routers, virtual IP address and timer intervals, the proposed scheme 213 can also enable HSRP aware PIM with similar failover and tracking 214 mechanism described in this draft. 216 7. Security Considerations 218 The proposed tracking mechanism does not discuss adding 219 authentication to the protocols and introduces no new negative impact 220 or threats on security to PIM in either SSM or ASM mode. Note that 221 VRRP messages from malicious nodes could cause unexpected behaviors 222 such as multiple Masters and PIM DRs which are associated with VRRP 223 specific security issues. To mitigate the vulnerability of frequent 224 VRRP and PIM DR state change from malicious attack, implementation 225 can choose to enable VRRP preemption such that a higher-priority VRRP 226 backup router does not take over for a lower-priority MR, this will 227 reduce the state change notifications to PIM component and subsequent 228 mroute state change. Detailed analysis of PIM and VRRP security is 229 provided in [RFC5294] and [RFC5798]. 231 8. IANA Considerations 233 This document has no IANA actions. 235 9. Acknowledgments 237 I would like to give a special thank you and appreciation to Stig 238 Venaas for his ideas and comments in this draft. 240 10. Informative References 242 [RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot 243 Standby Router Protocol (HSRP)", RFC 2281, 244 DOI 10.17487/RFC2281, March 1998, 245 . 247 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 248 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 249 Protocol Specification (Revised)", RFC 4601, 250 DOI 10.17487/RFC4601, August 2006, 251 . 253 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 254 Independent Multicast (PIM)", RFC 5294, 255 DOI 10.17487/RFC5294, August 2008, 256 . 258 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 259 Version 3 for IPv4 and IPv6", RFC 5798, 260 DOI 10.17487/RFC5798, March 2010, 261 . 263 Author's Address 265 Wei Zhou 266 cisco Systems 267 Tasman Drive 268 San Jose, CA 95134 269 USA 271 Email: weizho2@cisco.com