Network Working Group I. Wijnands Internet-Draft Y. Cai Intended status: Standards Track Cisco Systems, Inc. Expires: April 20, 2010 October 17, 2009 PIM neighbor reduction for transit LAN's. draft-wijnands-pim-neighbor-reduction-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2010. Copyright Notice Copyright (c) 2009 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 Wijnands & Cai Expires April 20, 2010 [Page 1] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract PIM establishes a neighbor relationship with other routers directly connected to it on startup. Networks that are LANs or behave like a LAN, potentially create many PIM neighbors depending on how many routers are attached to it. If such a LAN is also a transit network (no directly connected source or receiver), many of the PIM procedures don't apply. This proposal describes a procedure to reduce the amount of neighbors established over a transit LAN. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reducing the number of PIM neighbors . . . . . . . . . . . . . 3 3. Bidir support . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Generation ID Hello option . . . . . . . . . . . . . . . . . . 4 5. Unknown PIM J/P encoding . . . . . . . . . . . . . . . . . . . 5 6. Deployment strategy . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Contributing authors . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Wijnands & Cai Expires April 20, 2010 [Page 2] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 1. Introduction PIM sends hello messages to discover other PIM enabled routers that are directly connected on a particular interface and form a PIM neighbor relationship with them. Various PIM procedures depend on having a PIM neighbor elected as Designated Router (DR), like for PIM register messages [RFC4601] and processing IGMP reports [RFC4604]. Most of these procedures are specific to either directly connected receivers or senders and do not apply to transit networks. Networks that are LANs or behave like a LAN (Mi-PMSI) [I-D.ietf-l3vpn-2547bis-mcast] create as many PIM neighbors as there are PIM enabled routers directly connected to that LAN. For networks where the sources and/or RPs are only in few locations, which is a very typical deployment, it's very likely that many of these PIM neighbors are never used as a target in any PIM J/P message. Combined with the fact that on transit networks there are no directly connected receivers or senders, having a PIM neighbor relationship with all the PIM routers over a transit LAN network seems unnecessary. It is however still useful to have a PIM neighbor relationship with PIM routers that are used as target in the PIM Join or Prune (J/P) messages. We'll discuss these later in this draft. The proposal is to not form any PIM neighbor relations at startup, but create PIM neighbors dynamically on demand. Only PIM routers forwarding multicast data or on the path to the RP will be seen as a PIM neighbor. Other PIM routers on that LAN that act as receivers will stay passive and not form neighbor relationships. This will significantly reduce the number of PIM neighbors established over a LAN network where there are more passive receivers than there are senders. Networks that have directly connected senders and/or receivers are outside the scope of this draft. 1.1. Conventions used in this document 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 RFC 2119 [RFC2119]. 1.2. Terminology 2. Reducing the number of PIM neighbors PIM uses a unicast RIB to lookup the path to an upstream router for a particular Source or Rendezvous-Point (RP) [RFC4601]. The result of that lookup provides a directly connected next-hop that is used as the target in a PIM J/P message. [RFC4601] currently states that this next-hop also needs to be a PIM neighbor in order to send a PIM Wijnands & Cai Expires April 20, 2010 [Page 3] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 J/P to it. However, whether you're not sending a PIM message because it is not a PIM neighbor or this upstream router is unable to parse the join, functionally does not make a big difference. The multicast tree can't be formed and traffic is interrupted. This draft proposes to send a PIM J/P to a target upstream router even if it is not a PIM neighbor. We also propose that a router accepts the PIM J/P and processes it as if it was received from a PIM neighbor. In most multicast deployments it is very likely that a next-hop for a source and an RP is also a PIM enabled router, so this is not considered to be a big issue. However, we do want to form a one-way PIM neighbor relationship with the target upstream router. If a PIM router has a desire to send a PIM J/P to a non-PIM neighbor U, we propose to take one bit out of the PIM Join/Prune header 'Reserved' range and set it to 1 before we send the J/P packet. We call this bit the 'Hello Request' bit. A router that receives a PIM J/P with the 'Hello Request' bit on, sends a PIM hello out over the interface the PIM J/P was received on. The other routers on the LAN will receive the PIM hello and MAY form a one-way PIM neighbor relationship with U. A router that receives the Hello from U and has no interest in it MAY ignore the Hello to limit the amount of neighbor state. In the next PIM J/P the 'Hello Request' bit will be off because the PIM neighbor is known by the router sending the Join. Router U will continue to send periodic PIM Hello's out the interface as long as there is at least one downstream router joined over that interface for either a (*,G) or (S,G) state. 3. Bidir support The support for PIM Bidir [RFC5015] on a LAN depends on the election of the Designated Forwarder (DF). The DF election mechanism has a few dependencies on PIM neighbors. [RFC5015] section 3.5.5 also describes a PIM Hello dependency on the DF election. For that reason routers that are bidir capable and a Candidate DF will send out a PIM Hello over that LAN. A PIM neighbor relationship will be established among the candidate DF routers. Note that a candidate DF router on a LAN is a router that has an RPF interface towards the RPA that is NOT on that same LAN. Please see [RFC5015] section 2.1 and 3.5.2 for details. It is expected that there are few Candidate DF routers and it's very likely these routers are already on the path to the RPA for the Sparse-Mode groups. We don't expect this procedure to add to the number of PIM neighbors that is etablished over that LAN. 4. Generation ID Hello option PIM routers may use the generation ID in a PIM hello to make Wijnands & Cai Expires April 20, 2010 [Page 4] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 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. 5. Unknown PIM J/P encoding PIM routers that receive PIM J/P messages from other routers parse the J/P to do either Join suppression or Prune override procedures as documented in [RFC4601]. If a PIM router is unable to parse the J/P message due to an unknown encoding (possible due to PIM Join attributes ([RFC5384]), the override/suppression procedures will not work. If this situation occurs a router should fall back to sending periodic Hello messages to indicate to other routers on that LAN which options it's supports. This feature works best if all the routers support a similar PIM Hello option set. If a router detects a PIM hello from an other router with an unknown option the network administrator MUST be notified in a rate limited fashion. 6. Deployment strategy The PIM Hello reduction feature can be enabled on a subset of routers on a LAN as follows. If it is known in advance by the network administrator which routers are candidate upstream targets for a PIM J/P, because Source(s) or RP's are reachable via these routers, these routers should be enabled with this PIM hello reduction feature last. By not enabling these routers with this feature they will continue to send out periodic Hello's and all downstream router that don't support this feature will work as normal. The other routers on the LAN can be enabled with this feature which will result in not sending out periodic Hello's and reduce the number of PIM neighbors on that LAN. If it is not known by the network administrator which routers are candidate targets, all the routers connected to that LAN must be capable of this feature before it can be enabled. 7. Security Considerations For securing PIM J/P messages please see the security section in Wijnands & Cai Expires April 20, 2010 [Page 5] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 [RFC4601]. 8. IANA considerations This document requests the reservation of a bit from the PIM Join/ Prune header reserved field. This bit field is called 'Hello Request' bit. 9. Acknowledgments Thanks to Stig Venaas, Eric Rosen and Maria Napierala for their comments on the draft. 10. Contributing authors Below is a list of the contributing authors in alphabetical order: Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 USA E-mail: ycai@cisco.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium E-mail: ice@cisco.com 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Wijnands & Cai Expires April 20, 2010 [Page 6] Internet-Draft PIM neighbor reduction for transit LAN's October 2009 Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008. 11.2. Informative References [I-D.ietf-l3vpn-2547bis-mcast] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work in progress), July 2008. Authors' Addresses IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium Email: ice@cisco.com Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose CA, 95134 USA Email: ycai@cisco.com Wijnands & Cai Expires April 20, 2010 [Page 7]