idnits 2.17.1 draft-wijnands-pim-neighbor-reduction-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: PIM routers may use the generation ID in a PIM hello to make downstream router trigger PIM J/P's to it. This feature is used for upstream router High Avalability (HA) and when a router or interface becomes active. Using this feature there is no need to wait for the next periodic PIM J/P interval to (re)populate the forwarding state on the upstream router. If a Router or LAN becomes active, it is allowed to send a PIM hello on that LAN interface to speed up convergence, but it SHOULD not continue to send hello's periodically. Note, it's up to the downstream router(s) to either respond to this PIM Hello or ignore it if there is no interest in this PIM neighbor. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2011) is 4826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5384' is defined on line 317, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IJ. Wijnands, Ed. 3 Internet-Draft Y. Cai 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 12, 2011 February 8, 2011 7 PIM neighbor reduction for transit LAN's. 8 draft-wijnands-pim-neighbor-reduction-02 10 Abstract 12 PIM establishes a neighbor relationship with other routers directly 13 connected to it on startup. Networks that are LANs or behave like a 14 LAN, potentially create many PIM neighbors depending on how many 15 routers are attached to it. If such a LAN is also a transit network 16 (no directly connected source or receiver), many of the PIM 17 procedures don't apply. This proposal describes a procedure to 18 reduce the amount of neighbors established over a transit LAN. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 12, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Conventions used in this document . . . . . . . . . . . . . 3 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Reducing the number of PIM neighbors . . . . . . . . . . . . . 3 76 3. Bidir support . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Generation ID Hello option . . . . . . . . . . . . . . . . . . 4 78 5. Hello suppression and options . . . . . . . . . . . . . . . . . 5 79 5.1. PIM suppress Hello option . . . . . . . . . . . . . . . . . 5 80 5.2. Backwards compatibility . . . . . . . . . . . . . . . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 82 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 84 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 7 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 PIM sends hello messages to discover other PIM enabled routers that 93 are directly connected on a particular interface and form a PIM 94 neighbor relationship with them. Various PIM procedures depend on 95 having a PIM neighbor elected as Designated Router (DR), like for PIM 96 register messages [RFC4601] and processing IGMP reports [RFC4604]. 97 Most of these procedures are specific to either directly connected 98 receivers or senders and do not apply to transit networks. Networks 99 that are LANs or behave like a LAN (Mi-PMSI) 100 [I-D.ietf-l3vpn-2547bis-mcast] create as many PIM neighbors as there 101 are PIM enabled routers directly connected to that LAN. For networks 102 where the sources and/or RPs are only in few locations, which is a 103 very typical deployment, it's very likely that many of these PIM 104 neighbors are never used as a target in any PIM J/P message. 105 Combined with the fact that on transit networks there are no directly 106 connected receivers or senders, having a PIM neighbor relationship 107 with all the PIM routers over a transit LAN network seems 108 unnecessary. It is however still useful to have a PIM neighbor 109 relationship with PIM routers that are used as target in the PIM Join 110 or Prune (J/P) messages. We'll discuss these later in this draft. 112 The proposal is to not form unessesary PIM neighbor relations by 113 creating PIM neighbors dynamically on demand. Only PIM routers 114 forwarding multicast data or on the path to the RP will be seen as a 115 PIM neighbor. Other PIM routers on that LAN that act as receivers 116 will stay passive and not form neighbor relationships. This will 117 significantly reduce the number of PIM neighbors established over a 118 LAN network where there are more passive receivers than there are 119 senders. Networks that have directly connected senders and/or 120 receivers are outside the scope of this draft. 122 1.1. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 1.2. Terminology 130 2. Reducing the number of PIM neighbors 132 PIM uses a unicast RIB to lookup the path to an upstream router for a 133 particular Source or Rendezvous-Point (RP) [RFC4601]. The result of 134 that lookup provides a directly connected next-hop that is used as 135 the target in a PIM J/P message. [RFC4601] currently states that 136 this next-hop also needs to be a PIM neighbor in order to send a PIM 137 J/P to it. However, whether you're not sending a PIM message because 138 it is not a PIM neighbor or this upstream router is unable to parse 139 the join, functionally does not make a big difference. The multicast 140 tree can't be formed and traffic is interrupted. This draft proposes 141 to send a PIM J/P to a target upstream router even if it is not a PIM 142 neighbor. We also propose that a router accepts the PIM J/P and 143 processes it as if it was received from a PIM neighbor. In most 144 multicast deployments it is very likely that a next-hop for a source 145 and an RP is also a PIM enabled router, so this is not considered to 146 be a big issue. However, we do want to form a one-way PIM neighbor 147 relationship with the target upstream router. 149 If a PIM router has a desire to send a PIM J/P to a non-PIM neighbor 150 U, we propose to take one bit out of the PIM Join/Prune header 151 'Reserved' range and set it to 1 before we send the J/P packet. We 152 call this bit the 'Hello Request' bit. A router that receives a PIM 153 J/P with the 'Hello Request' bit on, sends a PIM hello out over the 154 interface the PIM J/P was received on. The other routers on the LAN 155 will receive the PIM hello and MAY form a one-way PIM neighbor 156 relationship with U. A router that receives the Hello from U and has 157 no interest in it MAY ignore the Hello to limit the amount of 158 neighbor state. In the next PIM J/P the 'Hello Request' bit will be 159 off because the PIM neighbor is known by the router sending the Join. 160 Router U will continue to send periodic PIM Hello's out the interface 161 as long as there is at least one downstream router joined over that 162 interface for either a (*,G) or (S,G) state. 164 3. Bidir support 166 The support for PIM Bidir [RFC5015] on a LAN depends on the election 167 of the Designated Forwarder (DF). The DF election mechanism has a 168 few dependencies on PIM neighbors. [RFC5015] section 3.5.5 also 169 describes a PIM Hello dependency on the DF election. For that reason 170 routers that are bidir capable and a Candidate DF will send out a PIM 171 Hello over that LAN. A PIM neighbor relationship will be established 172 among the candidate DF routers. Note that a candidate DF router on a 173 LAN is a router that has an RPF interface towards the RPA that is NOT 174 on that same LAN. Please see [RFC5015] section 2.1 and 3.5.2 for 175 details. It is expected that there are few Candidate DF routers and 176 it's very likely these routers are already on the path to the RPA for 177 the Sparse-Mode groups. We don't expect this procedure to add to the 178 number of PIM neighbors that is etablished over that LAN. 180 4. Generation ID Hello option 182 PIM routers may use the generation ID in a PIM hello to make 183 downstream router trigger PIM J/P's to it. This feature is used for 184 upstream router High Avalability (HA) and when a router or interface 185 becomes active. Using this feature there is no need to wait for the 186 next periodic PIM J/P interval to (re)populate the forwarding state 187 on the upstream router. If a Router or LAN becomes active, it is 188 allowed to send a PIM hello on that LAN interface to speed up 189 convergence, but it SHOULD not continue to send hello's periodically. 190 Note, it's up to the downstream router(s) to either respond to this 191 PIM Hello or ignore it if there is no interest in this PIM neighbor. 193 5. Hello suppression and options 195 PIM includes options in its Hello packets. We can group these 196 options in two categories, options that are significant per neighbor 197 or per LAN. For example, the GenID option is significant to the 198 neighbor originating it, the Bidir option is significant to the LAN. 199 Options that are significant per neighbor are learned as soon as a 200 node has any interest that the neighbor. For these we don't need any 201 special procedures. However, options relevant to the LAN, like Bidir 202 capable or DR priority may not be learned because nodes on the LAN 203 may suppress their Hello's using the procedures described in this 204 draft. Its not important to know which nodes on the LAN support it 205 or not, is good enough to know that at least one node does not 206 support it. In order to discover the LAN specific options without 207 creating PIM hello neighbor relationship between all the nodes we 208 introduce the procedure below. 210 5.1. PIM suppress Hello option 212 We introduce a new PIM hello option called the PIM suppress option 213 that is included in Hello's sent on the LAN. A PIM node on the LAN 214 that receives this option in the PIM Hello (and supports it) will 215 suppress its Hello if the set of included options match the options 216 of this node. If this node has no interest in the sender of the 217 Hello, no PIM neighbor relationship is created. The option set that 218 this PIM neighbor advertised will be stored with an expire timer set 219 to the advertised PIM hello holdtime. If this option set did already 220 exist, only the option set expire timer is updated. The PIM hello 221 periodic interval timer is started at the PIM hello interval time 222 plus a random delay between 0 and 3 seconds. After the timer expires 223 a PIM Hello is originated, unless a PIM Hello with the same set of 224 options was received before the timer expired. This is similar to 225 how PIM Join suppression works. With these procedures we are 226 suppressing PIM hello's that share the same option set. Its likely 227 that the PIM nodes on the LAN have the same option set, or at least 228 have a limited set of option combinations. Below is the proposed PIM 229 Hello suppress option encoding; 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type = TDB | Length = 0 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Type indicates PIM Hello suppression is supported. 238 5.2. Backwards compatibility 240 PIM nodes on the LAN that don't understand the suppress capability 241 will obviously not suppress their Hello. They will just ignore the 242 capability and create a PIM neighbor relation with the sender. This 243 node does not expect other nodes to suppress their Hello so will 244 assume that an upstream neighbor is not enabled with PIM. This may 245 prevent PIM from sending PIM Join/Prunes. How this situation should 246 be handled depends on the PIM implementation. Some implementations 247 deployed in the field already ignore PIM neighbors for sending PIM 248 Join/Prunes. For these implementations no special procedures are 249 needed. Implementations that depend on PIM neighbors may only apply 250 Hello suppression if all the PIM nodes on that LAN support the PIM 251 suppress option. We propose the following two options to be 252 supported; 254 As soon as one PIM node on the LAN does not support the suppress 255 option all routers on the LAN will default back to sending 256 periodic PIM hello's. Routers on the LAN continue to include the 257 suppress option. As soon as all the routers on the LAN support 258 the suppress option, PIM Hello suppression will be activated. 260 PIM hello suppression is always one and will not fall back to 261 sending periodic PIM hello's. 263 6. Security Considerations 265 For securing PIM J/P messages please see the security section in 266 [RFC4601]. 268 7. IANA considerations 270 This document requests the reservation of a bit from the PIM Join/ 271 Prune header reserved field. This bit field is called 'Hello 272 Request' bit. 274 8. Acknowledgments 276 Thanks to Stig Venaas, Eric Rosen and Maria Napierala for their 277 comments on the draft. 279 9. Contributing authors 281 Below is a list of the contributing authors in alphabetical order: 283 Yiqun Cai 284 Cisco Systems, Inc. 285 170 Tasman Drive 286 San Jose, CA, 95134 287 USA 288 E-mail: ycai@cisco.com 290 IJsbrand Wijnands 291 Cisco Systems, Inc. 292 De kleetlaan 6a 293 1831 Diegem 294 Belgium 295 E-mail: ice@cisco.com 297 10. References 299 10.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 305 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 306 Protocol Specification (Revised)", RFC 4601, August 2006. 308 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 309 Group Management Protocol Version 3 (IGMPv3) and Multicast 310 Listener Discovery Protocol Version 2 (MLDv2) for Source- 311 Specific Multicast", RFC 4604, August 2006. 313 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 314 "Bidirectional Protocol Independent Multicast (BIDIR- 315 PIM)", RFC 5015, October 2007. 317 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 318 Independent Multicast (PIM) Join Attribute Format", 319 RFC 5384, November 2008. 321 10.2. Informative References 323 [I-D.ietf-l3vpn-2547bis-mcast] 324 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 325 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 326 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work 327 in progress), January 2010. 329 Authors' Addresses 331 IJsbrand Wijnands (editor) 332 Cisco Systems, Inc. 333 De kleetlaan 6a 334 Diegem 1831 335 Belgium 337 Email: ice@cisco.com 339 Yiqun Cai 340 Cisco Systems, Inc. 341 170 Tasman Drive 342 San Jose CA, 95134 343 USA 345 Email: ycai@cisco.com