Global Table Multicast with BGP-MVPN Procedures
draft-zzhang-l3vpn-mvpn-global-table-mcast-00

Network Working Group                                              Zhang
Internet-Draft                                                  Giuliano
Intended status: Informational                          Juniper Networks
Expires: January 13, 2014                                        Pacella
                                                                 Verizon
                                                                Schiller
                                                                  Google
                                                           July 12, 2013

            Global Table Multicast with BGP-MVPN Procedures
           draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt

Abstract

   This document describes a way to implement Global Table Multicast,
   aka Internet Multicast, using BGP encodings and procedures for MVPN
   as specified in [RFC6514].

   No protocol modification/extension is required.  This is purely for
   informational and clarifying purposes only.

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 January 13, 2014.

Copyright Notice

   Copyright (c) 2013 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

Zhang, et al.           Expires January 13, 2014                [Page 1]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

   carefully, as they describe your rights and restrictions with respect
   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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Considerations for GTM with BGP-MVPN . . . . . . . . . . .  6
     3.2.  IBGP session between MBRs and non-MBRs . . . . . . . . . .  6
     3.3.  Non-BGP UMH Routes or BGP UMH routes not originated by
           the MBRs . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Zhang, et al.           Expires January 13, 2014                [Page 2]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

1.  Introduction

   [RFC6513] and [RFC6514] specify procedures and encodings to implement
   Multicast for L3VPNs (MVPN).  [RFC6513] specifies general concepts
   and procedures that apply to PIM-based and/or BGP-based C-Multicast
   State Signaling (referred to PIM-MVPN and BGP-MVPN respectively), and
   [RFC6514] specifies BGP procedures and encodings used by both PIM-
   MVPN and BGP-MVPN.

   While [RFC6513] and [RFC6514] assume the context of VPN, they can be
   used to implement Global (vs. VRF) Table Multicast as well, without
   any protocol modification/extension, even though the RFCs do not
   explicitly mention it.

   Consider a provider network in which the "core" part of it uses MPLS
   P2MP LSPs or Ingress Replication over either P2P LSPs (with RSVP-TE)
   or MP2P LSPs (with LDP) instead of PIM to carry multicast traffic
   among the MPLS Border Routers (MBRs) of the core.  Those MBRs run PIM
   on interfaces connected to other routers outside the core.

   This document describes how Global Table Multicast can be implemented
   using BGP-MVPN procedures.  We start with a simple reference scenario
   below, and also discuss one slightly different scenario and another
   special one.

   With Global Table Multicast (GTM) implemented by BGP-MVPN procedures,
   most of the features/characteristics of BGP-MVPN apply, including
   scaling, aggregation, flexible choice of provider tunnels, wild-card
   S-PMSI, support for PIM-DM/ASM/SSM/Bidir as PE-CE multicast protocol,
   support for both IPv4 and IPv6 with IPv4 infrastructure, support for
   unsolicited flooded data, including support for BSR as RP-to-group
   mapping protocols, etc.  While it is different from the GTM procedure
   specified in [seamless-mcast], the two can co-exist.

   In the rest of the document, the term MBR (MPLS Border Router) is
   used to denote a router that runs BGP-MVPN procedures for Global
   Table Multicast, analogous to a PE in a true VPN Environment.  In
   other words, MBRs border the BGP-MVPN domain, which could even be
   inter-AS.

Zhang, et al.           Expires January 13, 2014                [Page 3]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

2.  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].

Zhang, et al.           Expires January 13, 2014                [Page 4]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

3.  Operation

   In the simplest reference scenario, PIM runs between the MBRs and
   their adjacent non-MBRs, and the MBRs advertise to each other Reverse
   Path Forwarding (RPF) routes to multicast sources via iBGP (with or
   without RRs in the middle) with Next Hop set to themselves.  The
   routes are learned from routers outside of the core via eBGP or IGP.
   Note that with BGP-MVPN, the RPF routes are referred to as UMH
   (Upstream Multicast Hop) Routes.  In this document the two terms are
   used interchangeably.

   Conceptually and functionally, those MBRs resemble MVPN PEs:
   connections to other routers outside the core can be treated as PE-CE
   interfaces and MVPN procedures can run among the PEs (i.e., MBRs) for
   Discovery, Tunnel Binding, and Multicast State Signaling.

   RFC 6514 specifies that MCAST-VPN I/S-PMSI A-D routes and Source
   Active A-D routes carry certain Route Targets, allowing them to be
   imported into appropriate VRFs.  By default, the Route Targets are
   the same as for unicast routing, but any configured set of Route
   Targets can be used.  For GTM using procedures in this document,
   Route Targets are used to associate the A-D routes with GTM the same
   way as a configured set of Route Targets are used as specified in RFC
   6514.  By default, an (auto-)configured Route Target is used: an IPv4
   Address Specific Extented Community with both the Global and Local
   Administrative Fields being 0.

   RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher
   (RD).  For GTM, it SHOULD be possible to configure an RD that is used
   only for MCAST-VPN A-D routes for the global table.  The RD can be
   defaulted to a special 64-bit all-zero value (denoted as RD 0:0).
   Note that RD 0:0 is not valid as a VRF RD, and unlike in
   [seamless-mcast] the use of RD 0:0 per this docuement does not modify
   the semantics of any BGP route in which it appears.  Obviously, while
   using RD 0:0 per this document, the GTM procedures specified in
   [seamless-mcast] cannot be used for the global table.

   Unlike in VPN case, the unicast routes in global table are not
   advertised with RDs.  As a result, for C-multicast routes, the above
   mentioned configured RD value (including the special RD 0:0) is used
   when the originating MBR and the Upstream MBR is in the same AS.  For
   comparison, RFC 6514 specifies in section 11.1.3 that the RD of the
   VPN-IP route is used.

   Additionally, due to the lack of RD in the unicast route
   advertisements, an egress PE may not receive all advertisements from
   all the MBRs that a multicast source or RP is multi-homed to.  This
   may be the case even when BGP add-path is used.  As a result, the

Zhang, et al.           Expires January 13, 2014                [Page 5]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

   Single Forwarder Selection procedure in RFC 6513 may not guarantee
   that all egress MBRs select the same Upstream MBR.  Therefore,
   procedures in Section 9.1.1 of RFC 6513 MUST be used to ensure that
   an egress PE only forward traffic sent by the Upstream MBR that it
   selects.

   When an MBR advertises UMH routes via BGP over the core, it attaches
   a VRF Route Import Extended Community and Source AS Extended
   Community. as specified in Section 7 of RFC 6514.  When constructing
   the C-multicast Import RT as specified in Section 7 of [RFC6514], it
   is RECOMMENDED that the Local Administrator field is set to 0, though
   an implementation MAY use any value that can uniquely associate it to
   the global routing table (vs. a VRF).

3.1.  Considerations for GTM with BGP-MVPN

   The following should be considered when using BGP-MVPN for GTM.

   o  As mentioned above, Single Forwarder Selection procedure cannot be
      used.  This is a limitation when multiple MBRs may be the Upstream
      MBR for the same source or RP.

   o  There are potentially many more MBRs for GTM than PEs for a
      particular VPN.  As a result, use of inclusive tunnels should be
      avoided (or with fan-out reduced by using tunnel segmentation as
      specified in [seamless-mcast]).

   o  Internet providers often make extensive use of BGP communities
      (ie, adding, deleting, modifying communities throughout a
      network).  As such, care should be taken to avoid deleting or
      modifying the VRF Route Import Extended Community and Source AS
      Extended Community.

3.2.  IBGP session between MBRs and non-MBRs

   In the simple reference scenario above, it is assumed that the MBRs
   learn UMH routes from non-MBRs via eBGP or IGP.  This assumption
   helps illustrate the analogy to a true VPN environment.  In a
   different deployment scenario, the MBRs could have learned the UMH
   routes over iBGP sessions to non-MBRs.  If the MBRs act as RRs and
   reflect the UMH routes to other MBRs with polices to attach VRF Route
   Import Extended Community and Source AS Extended Community, BGP-MVPN
   procedures can still be used as described earlier.  Even if the MBRs
   do not act as RRs, the scenario could be considered analogous to what
   [RFC6368] describes.  As long as MBRs re-advertise those UMH routes
   with the above mentioned communities, BGP-MVPN procedures can be used
   as described earlier.  Note that they do not even need to use the
   push/pop procedures in [RFC6368] - the only requirement is for the

Zhang, et al.           Expires January 13, 2014                [Page 6]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

   MBRs to re-advertise the routes learned over iBGP sessions from non-
   MBRs to other MBRs over iBGP sessions.

3.3.  Non-BGP UMH Routes or BGP UMH routes not originated by the MBRs

   With true MVPN, the PEs advertise the UMH routes themselves as VPN-IP
   routes, and attach a VRF Route Import Extended Community that has the
   C-multicast Import RT value for the VRF associated with the routes.
   The VRF Route Import Extended Community is extracted by egress PEs
   and attached to their C-Multicast Routes as Route Target Extended
   Community to control the distribution to and importation by relevant
   upstream PEs.

   With Global Table Multicast, in both the simple reference scenario
   and the above mentioned variance, the MBRs do (re-)advertise the UMH
   routes as required for BGP-MVPN.  However, in other situations, it is
   possible that the UMH routes are not advertised by the MBRs via BGP
   at all, hence they may not carry the VRF Route Import Extended
   Community.

   Consider the following example:

      |---- Site 1 -------|

                EBGP
      src----R3------R1/CE1 -------MBR1/PE1
                        \         /|
                        |\       / |
                        | \IBGP /  |
                        |  \   /   |
                        |   \ /    |
                        |    X     |
                        |   / \    |
                        |  /   \   |
                        | /mesh \  |
                        |/       \ |
                        /         \|
      rcv----R4------R2/CE2 -------MBR2/PE2
                EBGP

      |---- Site 2 -------|

   There is a full-mesh of IBGP sessions among provider routers R1/MBR1/
   MBR2/R2.  EBGP sessions run between R3/R1 and between R4/R2.  MBR1/
   MBR2 run BGP-MVPN procedures for Global Table Multicast.  R1 learns
   of BGP route to the source from R3 and advertises it to MBRx/R2.

Zhang, et al.           Expires January 13, 2014                [Page 7]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

   Because R1 does not run MVPN, MBR2's route to the source (learned
   from R1 instead of MBR1) does not have the VRF Route Import Extended
   Community.  Therefore, it would not be able to correctly attach a
   Route Target Extended Community corresponding to MBR1 in its
   C-Multicast Routes.

   To handle that situation, MBR2 performs the following recursively to
   potentially identify the Upstream MBR and derive a VRF Route Import
   Extended Community.  Note that the route in the following procedure
   is either the UMH-eligible route for the source itself, or the route
   to the Next Hop of the BGP route in the previous recursion.

   o  If the route is a BGP route with a VRF Route Import Extended
      Community, that VRF Route Import Extended Community is used.

   o  If the route is a BGP route without a VRF Route Import Extended
      Community, get the route to the Next Hop and recurse.

   o  If the route is an IGP route with a RSVP-TE LSP as next hop, and
      the LSP endpoint is a MBR (MBR1 in the above example) that
      advertises an Intra-AS I-PMSI or an S-PMSI A-D route, a VRF Route
      Import Extended Community is constructed as MBR_addr:0 to be
      associated with the UMH-eligible route, where the MBR_addr is the
      Originating Router's IP Address of the Intra-AS I-PMSI or S-PMSI
      A-D route.

   Constructing the VRF Route Import as MBR_addr:0 by an egress MBR in
   the above special situation explains why it is RECOMMENDED that the
   Local Administrator is set to 0 when an upstream MBR constructs its
   C-Multicast Import RT - the zero value is a special value agreed on
   apriori by all (vs. a local value that is normally picked by the
   upstream MBR and signaled via the VRF Route Import Extended
   Community).

   If the above procedure does not produce a usable VRF Route Import
   Extended Community, then the UMH route is considered a local route
   (vs. a remote route that is associated with an Upstream MBR).  If the
   UMH is indeed remote (over the core) but considered as local by the
   above procedure, then the above scenario will obviously not work.

   Note that the above procedure is necessary only if the MBRs (that run
   MVPN procedures) do not advertise the UMH routes via BGP and include
   VRF Route Import Extended Community in such routes.  The egress MBRs
   can obtain/derive the VRF Route Import Extended Community as long as
   the UMH-eligible route is or resolves recursively to one of the
   folllowing:

Zhang, et al.           Expires January 13, 2014                [Page 8]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

   o  A BGP route that carries a VRF Route Import Extended Community
      (this route could even be to an MBR and advertised by the MBR
      itself).  Or,

   o  An IGP route with a RSVP-TE LSP as next hop, and the LSP endpoint
      matches the Originating Router's IP Address of an Intra-AS I-PMSI
      or S-PMSI A-D route.

Zhang, et al.           Expires January 13, 2014                [Page 9]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

4.  Security Considerations

   This document raises no new security issues.  Security considerations
   for the base protocols are covered in [RFC6514], [RFC4601], and
   [RFC5294].

Zhang, et al.           Expires January 13, 2014               [Page 10]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

5.  IANA Considerations

   This document has no IANA considerations.

   This section should be removed by the RFC Editor prior to final
   publication.

Zhang, et al.           Expires January 13, 2014               [Page 11]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

6.  Acknowledgements

   The authors would like to thank Rahul Aggarwal, Yakov Rehkter and
   Eric Rosen for their comments and suggestions.

Zhang, et al.           Expires January 13, 2014               [Page 12]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6513]  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
              VPNs", RFC 6513, February 2012.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, February 2012.

   [RFC6625]  Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu,
              "Wildcards in Multicast VPN Auto-Discovery Routes",
              RFC 6625, May 2012.

7.2.  Informative References

   [RFC6368]  Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
              Yamagata, "Internal BGP as the Provider/Customer Edge
              Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
              RFC 6368, September 2011.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC5294]  Savola, P. and J. Lingard, "Host Threats to Protocol
              Independent Multicast (PIM)", RFC 5294, August 2008.

   [seamless-mcast]
              Rekhter, Y., "Inter-Area P2MP Segmented LSPs",
               draft-ietf-mpls-seamless-mcast-06.txt.

Zhang, et al.           Expires January 13, 2014               [Page 13]
Internet-Draft    Global Table Multicast with BGP-MVPN         July 2013

Authors' Addresses

   Jeffrey Zhang
   Juniper Networks
   10 Technology Park Dr.
   Westford, MA  01886
   US

   Email: zzhang@juniper.net

   Lenny Giuliano
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Email: lenny@juniper.net

   Dante J. Pacella
   Verizon
   Verizon Communications
   22001 Loudoun County Parkway
   Ashburn, VA  20147
   US

   Email: dante.j.pacella@verizonbusiness.com

   Jason Schiller
   Google
   1818 Library Street
   Suite 400
   Reston, VA  20190
   US

   Email: jschiller@google.com

Zhang, et al.           Expires January 13, 2014               [Page 14]