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,
              <http://www.rfc-editor.org/info/rfc4601>.

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,
              <http://www.rfc-editor.org/info/rfc1075>.






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,
              <http://www.rfc-editor.org/info/rfc1584>.

   [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,
              <http://www.rfc-editor.org/info/rfc6514>.

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]