PIM Z. Zhang Internet-Draft Juniper Networks Intended status: Informational K. Patel Expires: April 21, 2016 Cisco Systems October 19, 2015 Protocol Dependent Multicast Signaling draft-zzhang-pim-pds-00 Abstract This document describes a general idea of multicast signaling based on extensions to unicast protocols. 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 RFC2119. 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 April 21, 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 Zhang & Patel Expires April 21, 2016 [Page 1] Internet-Draft pim-pds October 2015 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BGP Based PIM-PDS . . . . . . . . . . . . . . . . . . . . . . 3 3. IGP Based PIM-PDS . . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Motivation Protocol Independent Multicast (PIM) has been the prevailing multicast protocol for many years. Despite its success, it has two drawbacks: o Complexity originated from RPT/SPT switchover and data driven nature for PIM-ASM. o Periodical protocol state refreshes due to the soft state nature. While PIM-SSM removes the complexity of PIM-ASM, there have not been a good way of discovering sources, limiting its deployment. PIM-Port (PIM over Reliable Transport) solves the soft state issue, though its deployment has also been limited. Partly because of the complexity concern, some Data Center operators have been avoiding deploying multicast in their networks. Data Center operators are also inclined to reduce the number of routing protocols as much as possible, to reduce operational complexity and expenses. For example, with [draft-ietf-rtgwg-bgp- routing-large-dc], BGP is used as the only routing protocol, w/o any IGPs. Some other data centers may still choose to run traditional IGPs, but in either case, it may be desired to not run another protocol for multicast purposes. PIM builds multicast distribution trees from the receiver ends towards the sources or Rendezvous Points. Traffic flows from the sources/RPs towards receivers in the reverse direction of unicast traffic from receivers towards the sources/RPs, hence the term Zhang & Patel Expires April 21, 2016 [Page 2] Internet-Draft pim-pds October 2015 Reverse Path Forwarding. With PIM, the term "protocol indpendent" comes from the fact that, the routes used for RPF purpose can be learned from any protocol, unlike in DVMRP case where the RPF routes are distributed via DVMRP itself, or in MOSPF case where OSPF routes are used to build the trees. Without changing the principle of multicast tree building based on the reverse path routes learned from any protocol, the tree building and maintenance do not have to rely on PIM protocol messages. Rather, it could be done by extensions to whatever unicast protocols used, so that only one protocol needs to be operated in a network. For that, we introduce a new flavor of PIM - Protocol Dependent Signaling (PIM-PDS). The following sections discussed two options at very high level. Detailed specifications are out scope of this introductory document. 2. BGP Based PIM-PDS BGP-MVPN [RFC 6514] uses BGP to signal VPN customer multicast state over provider networks. It removes the above mentioned problems, and the deployment experiences have been encouraging. [draft-ietf-bess- mvpn-pe-ce] adapts the concept of BGP-MVPN to PE-CE links, and [draft-zzhang-bess-bgp-multicast] extends it further to general topologies, so that it can deployed in any network where BGP is running, or can be run, throughout or on most routers. In a nut shell, [draft-zzhang-bess-bgp-multicast] is PIM with BGP based join/prune signaling, and BGP based source discovery in case of ASM. The same RPF procedures as in PIM are used for each router to determine the RPF neighbor for a particular source or RPA (in case of Bidirectional Tree). Except in the Bidirectional Tree case, no (*,G) join is used - LHR routers discover the sources for ASM and then joins towards the sources directly. 3. IGP Based PIM-PDS Both MOSPF [RFC 1584] and recent IGP Mutlicast Architecture [draft- yong-rtgwg-igp-multicast-arch] are based on flooding multicast membership information everywhere, even though the information is only needed on the relevant multicast distribution trees. As a result, the scaling is severely limited. With PIM-PDS, IGP link- scoped flooding can be used tree construction and maintenance - the receiver interest is only signaled towards the sources/RPs, and merging/aggregation will happen along the way. Zhang & Patel Expires April 21, 2016 [Page 3] Internet-Draft pim-pds October 2015 4. Security Considerations This document only describes high level concepts and does not attempt to address possible security issues. Separate documents, if written, would address those. 5. Acknowledgements 6. References 6.1. Normative References [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, . 6.2. Informative References [I-D.ietf-bess-mvpn-pe-ce] Patel, K., Rosen, E., and Y. Rekhter, "BGP as an MVPN PE- CE Protocol", draft-ietf-bess-mvpn-pe-ce-00 (work in progress), April 2015. [I-D.ietf-rtgwg-bgp-routing-large-dc] Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for routing in large-scale data centers", draft-ietf-rtgwg- bgp-routing-large-dc-02 (work in progress), April 2015. [I-D.yong-rtgwg-igp-multicast-arch] Yong, L., Weiguo, H., Eastlake, D., Qu, A., Hudson, J., and U. Chunduri, "IGP Multicast Architecture", draft-yong- rtgwg-igp-multicast-arch-01 (work in progress), November 2014. [I-D.zzhang-bess-bgp-multicast] Zhang, J. and K. Patel, "BGP Based Multicast", draft- zzhang-bess-bgp-multicast-00 (work in progress), October 2015. [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, DOI 10.17487/RFC1075, November 1988, . Zhang & Patel Expires April 21, 2016 [Page 4] Internet-Draft pim-pds October 2015 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, DOI 10.17487/RFC1584, March 1994, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . Authors' Addresses Zhaohui Zhang Juniper Networks EMail: zzhang@juniper.net Keyur Patel Cisco Systems EMail: keyupate@cisco.com Zhang & Patel Expires April 21, 2016 [Page 5]