Internet DRAFT - draft-kurapati-dynamicrp-bgpmvpn

draft-kurapati-dynamicrp-bgpmvpn







L3VPN                                                        P. Kurapati
Internet-Draft                                              M. Rodrigues
Intended status: Standards Track                             K. Windisch
Expires: November 25, 2013                              Juniper Networks
                                                                 S. Asif
                                                               AT&T LABS
                                                            May 24, 2013


                Dynamic RP encodings in BGP based MVPNs
                draft-kurapati-dynamicrp-bgpmvpn-00.txt

Abstract

   PIM Group-to-RP mappings are distributed dynamically using protocols
   such as BSR or Auto-RP.  The BGP-MVPN specification provides for this
   information to be encapsulated in an I-PMSI or S-PMSI provider tunnel
   between the PEs in an MVPN environment.  Since this is control
   information, it is desirable to signal this information in BGP
   between PEs, similar to carrying other customer control state such as
   C-Multicast routes.  This document specifies the mechanisms and
   procedures to carry bootstrap information via BGP to provide true
   control and data plane separation.

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 November 25, 2013.

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



Kurapati, et al.       Expires November 25, 2013                [Page 1]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   (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
   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.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Unified BGP based control plane . . . . . . . . . . . . .   4
     3.2.  Manageability at a common provider location . . . . . . .   4
     3.3.  Avoiding unnecessary Provider Tunnels . . . . . . . . . .   4
   4.  MCAST-VPN-BSR NLRI  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  BSR Parameters NLRI . . . . . . . . . . . . . . . . . . .   5
     4.2.  BSM Group Parameters NLRI . . . . . . . . . . . . . . . .   6
     4.3.  BSM RP Parameters NLRI  . . . . . . . . . . . . . . . . .   7
     4.4.  BSR-BGP Path Attribute  . . . . . . . . . . . . . . . . .   8
   5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Handling Bootstrap messages . . . . . . . . . . . . . . .   9
       5.1.1.  Data for BSR Parameters Route . . . . . . . . . . . .   9
       5.1.2.  Fragmented BSMs . . . . . . . . . . . . . . . . . . .  10
       5.1.3.  Mappings arriving in different BGP UPDATES  . . . . .  10
     5.2.  Mapping individual groups to RP . . . . . . . . . . . . .  11
     5.3.  Triggered BSMs by egress PE . . . . . . . . . . . . . . .  11
     5.4.  Reverse Path Forwarding for Dynamic RP advertisements . .  11
     5.5.  Interoperation with tunneled BSR  . . . . . . . . . . . .  12
     5.6.  Route Targets for Group-to-RP mapping routes  . . . . . .  13
     5.7.  BSR multihomed  . . . . . . . . . . . . . . . . . . . . .  13
   6.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Originating Group-to-RP Mapping route for bootstrap
           messages received on a VRF  . . . . . . . . . . . . . . .  13
     6.2.  Handling changes in BSR messages  . . . . . . . . . . . .  14



Kurapati, et al.       Expires November 25, 2013                [Page 2]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


       6.2.1.  Missing RP or Group mapping entry . . . . . . . . . .  14
       6.2.2.  Missing BSM . . . . . . . . . . . . . . . . . . . . .  15
       6.2.3.  Change of Elected BSR . . . . . . . . . . . . . . . .  16
     6.3.  Receiving Group-to-RP Mapping routes for BSR  . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  18
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     10.1.  Normative Reference  . . . . . . . . . . . . . . . . . .  18
     10.2.  Informative Reference  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   In PIM-SM [RFC4601], the Group-to-RP mapping information is
   distributed dynamically through methods such as BSR [RFC5059] or
   Auto-RP.  When multicast is deployed in an VPN environment, PEs in
   the provider space need to carry this information transparently
   across its core so that CEs in all the sites can access this RP
   information.  MVPN specification [RFC6513] defined a mechanism in
   section 5.3.4 where the BSR messages can be transmitted in the
   provider space over PMSI tunnels.  However, carrying control messages
   like BSR in the data tunnels is not always desirable.  BGP encodings
   in BGP-MVPN specification [RFC6514] already define mechanisms to
   carry C-Multicast route information in BGP.  This document specifies
   carrying BSR Group-to-RP mapping information through BGP.  Auto-RP
   mechanism is out of scope for this specification.

2.  Terminology

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

   This document uses the following terms:

   "MVPN"

   "Multicast in MPLS/BGP IP VPNs" [RFC6513] includes two different
   methods, BGP and PIM, for exchanging customer's multicast control
   information.  This document only deals with BGP for exchanging the
   customer multicast control information.  MVPN in the following
   sections refers to BGP-MVPN.

   "C-Multicast routes"

   MVPN customer's multicast routing information that is carried in BGP
   is referred in this document as C-Multicast routes.



Kurapati, et al.       Expires November 25, 2013                [Page 3]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   "RP-Set"

   RP-Set is the Group-to-RP mapping information distributed by BSR.

3.  Motivation

3.1.  Unified BGP based control plane

   In BGP based MVPN, PE Auto Discovery and the exchange of PIM Join/
   Prune state, are a part of the customer multicast control plane and
   are accomplished via advertisements of BGP MVPN NLRI.  BSR/Auto-RP
   protocols also carry a type of customer multicast control
   information.  Carrying them in BGP is not only logical but also gives
   a unified BGP based control plane to carry all the Customer space
   control messages.

3.2.  Manageability at a common provider location

   A provider of MVPN services would be interested to know the
   customer's RP topology and the detailed mappings.  This information
   will be critical for operations to troubleshoot and/or manage
   customer's multicast deployments.  Like the C-Multicast routes,
   obtaining this information at a centralized location like a BGP
   Route-Reflector is desired.  In the current MVPN specifications, if a
   provider wants such information, it needs to be obtained from the
   customer VRFs on all PE's importing these customer VRF's.  More so,
   obtaining this information on each PE through intervals is prone to
   information lost between intervals, especially with soft-state
   control protocols like PIM.  Since the RP-Set information is not a
   control message passed through BGP, obtaining this information is not
   possible through BGP Route Reflector.

3.3.  Avoiding unnecessary Provider Tunnels

   With the current specification, the RP-Set is carried via PMSI
   tunnels.  There may be deployments which uses only S-PMSI.  Carrying
   BSR information through S-PMSI implies creating tunnels just to carry
   control information.  Also, if the BSR is located at the receiver-
   only site, an S-PMSI tunnel needs to be created with the PE at
   receiver site as root.  This PE needs to create an S-PMSI tunnel with
   bursty source just for distributing control message which was
   otherwise not required to be setup as it is a receiver-only PE.









Kurapati, et al.       Expires November 25, 2013                [Page 4]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


4.  MCAST-VPN-BSR NLRI

   This document defines a new NLRI called the MCAST-VPN-BSR NLRI.  The
   format of the MCAST-VPN-BSR NLRI is identical to what is defined in
   BGP-MVPN [RFC6514]

         +-------------------------------------+
         |   Route Type (1 octet)              |
         +-------------------------------------+
         |   Length (1 octet)                  |
         +-------------------------------------+
         |   Route Type specific (variable)    |
         +-------------------------------------+



   The following 3 Route Types are defined for MCAST-VPN-BSR NLRI.

      1 - BSR Parameters

      2 - BSM Group parameters

      3 - BSM RP Parameters

   The MCAST-VPN-BSR NLRI is carried in BGP [RFC4271] with an AFI of 1
   or 2 and a SAFI of MCAST-VPN-BSR.  In order for two BGP speakers to
   exchange MCAST-VPN-BSR NLRIs, they must use a BGP Capabilities
   Advertisement to ensure that they both are capable of properly
   processing such an NLRI.  This is done as specified in [RFC4760], by
   using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and
   a SAFI of MCAST-VPN-BSR.

4.1.  BSR Parameters NLRI

   A BSR Parameters Route Type specific MCAST-VPN-BSR NLRI consists of
   the following:

         +-------------------------------------+
         |   RD   (8 octets)                   |
         +-------------------------------------+
         |   len of BSR Address (1 octet)      |
         +-------------------------------------+
         |   BSR Address (Variable length)     |
         +-------------------------------------+
         |   Hash Mask Length (1 octet)        |
         +-------------------------------------+
         |   BSR Priority (1 octet)            |
         +-------------------------------------+



Kurapati, et al.       Expires November 25, 2013                [Page 5]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


         |   Originating PE's IP Address       |
         +-------------------------------------+



   The RD is encoded as described in [RFC4364].

   BSR Address defines the Elected/Candidate BSRs IP address extracted
   from the Bootstrap message.  The field "len of BSR Address"
   determines whether it is IPv4 or IPv6.  If the value is 32, the
   corresponding IP address is an IPv4 address.  If the value is 128 it
   is an IPv6 address.

   BSR priority is a 1 octet value as defined in BSR specification
   [RFC5059].

   Hash Mask Length is a 1 octet value which is used for RP selection by
   the routers running BSR.  This value MUST be taken from the BSM and
   copied in to the BSR Parameters route by the originating router.

   Originating PE's IP Address field is set to the IP address that the
   PE places in the Global Administrator field of the VRF Route Import
   Extended Community of the VPN-IP routes advertised by the PE.  For a
   given MVPN, a single such IP address MUST be used, and that same IP
   address MUST be used as the originating PE's IP address in all route
   types of the MCAST-VPN-BSR NLRI that the PE transmits.

   The usage and details of this NLRI is discussed in "Protocol Details"
   section.

4.2.  BSM Group Parameters NLRI

   A BSM Group Parameters Route Type specific MCAST-VPN-BSR NLRI
   consists of the following:

















Kurapati, et al.       Expires November 25, 2013                [Page 6]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


      +-------------------------------------+
      |   RD   (8 octets)                   |
      +-------------------------------------+
      |   len of BSR Address (1 octet)      |
      +-------------------------------------+
      |   BSR Address (Variable length)     |
      +-------------------------------------+
      |   len of Group Address (1 Octet)    |
      +-------------------------------------+
      | Group Prefix (Encoded Group format) |
      +-------------------------------------+
      |   Originating PE's IP Address       |
      +-------------------------------------+


   Group prefix can contain IPv6 or IPv4 address.  Similar to RP
   Address, this can be determined by "len of Group Address" field.  A
   value of 32 indicates IPv4 and 128 indicates IPv6 Group prefix.  Note
   that the length only indicates the length of the Group address amd
   not the encoded group prefix.

   Encoded Group prefix format is defined in PIM-SM specification
   [RFC4601] and the same is extracted from the BSM message and is
   placed in this NLRI.  Along with the group prefix, the encoded group
   format also contains important information such as 'BiDir' and Admin
   Scope zone which needs to be carried across to the egress PEs.

   The usage and details of this NLRI is discussed in "Protocol Details"
   section.

4.3.  BSM RP Parameters NLRI

   A BSR RP Parameters Route Type specific MCAST-VPN-BSR NLRI consists
   of the following:

      +-------------------------------------+
      |   RD   (8 octets)                   |
      +-------------------------------------+
      |   len of BSR Address (1 octet)      |
      +-------------------------------------+
      |   BSR Address (Variable length)     |
      +-------------------------------------+
      |   len of RP Address (1 octet)       |
      +-------------------------------------+
      |   RP Address (Encoded unicast addr) |
      +-------------------------------------+
      |   len of Group Address (1 octet)    |
      +-------------------------------------+



Kurapati, et al.       Expires November 25, 2013                [Page 7]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


      |   Group Prefix(Encoded Group format)|
      +-------------------------------------+
      |   RP Hold Time (2 Octets)           |
      +-------------------------------------+
      |   RP Priority (1 Octet)             |
      +-------------------------------------+
      |   Originating PE's IP Address       |
      +-------------------------------------+


   RP Address is in Encoded unicast format as defined in PIM-SM
   specification [RFC4601] and the same is extracted from the BSM
   message and is placed in this NLRI.

   Hold Time is a 2 octet value in seconds, as defined in BSR
   specification [RFC5059].  It is a per RP value which is taken from
   the BSM and filled in the NLRI by the originating router.

   The usage and details of this NLRI is discussed in "Protocol Details"
   section.

4.4.  BSR-BGP Path Attribute

   This document defines and uses a new BGP attribute called the "BSR-
   BGP attribute".  This is an optional transitive BGP attribute.  The
   format of this attribute is defined as follows:

      +-------------------------------------+
      |   Fragment Tag (2 Octets)           |
      +-------------------------------------+
      |   Group Count  (1 Octet)            |
      +-------------------------------------+
      |   RP Count  (1 Octet)               |
      +-------------------------------------+


   All MCAST-VPN-BSR NLRI route types carry the BSR-BGP Path attribute.
   However, based on the route-type the corresponding fields are set.
   Fragment Tag MUST be set by all 3 route types.  The usage of Fragment
   Tag is discussed in the details section.

   BSR Parameters NLRI also sets the Group Count field indicating the
   number of Groups this BSM is carrying.  RP Count is not used by the
   originator of BSR Parameters NLRI and SHOULD be ignored by the
   receiver of BSR Parameters NLRI.

   BSM Multicast Group Parameters NLRI sets the RP Count indicating the
   number of RPs that this Group carries.  The Group Count for this NLRI



Kurapati, et al.       Expires November 25, 2013                [Page 8]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   is not set and SHOULD be ignored by the receiver of BSM MUlticast
   Group Parameters NLRI

   BSM RP parameters NLRI sets only the Fragment Tag.  Group Count and
   RP Count fields are not set by the originator and SHOULD be ignored
   by the receiver of BSM RP Parameters NLRI.

5.  Protocol Overview

   In this section, we will discuss the overview of the mechanism to
   carry BSR through BGP.  The full specification will be discussed in
   the next section.  The actual processing of BSR message is not
   changed by this specification for BSR messages sent/received on PE-CE
   links.  i.e.  the way BSR is elected based on BSM or RP selection
   procedure will continue to follow the BSR specification.  This
   document only describes how the information carried in BSR is
   redistributed into BGP at the ingress PEs, and how the remote PEs
   redistribute this information from BGP back into BSR.  The same
   applies when the PE itself is configured as C-RP or BSR for the given
   VRF.  When the PE is C-RP, the RP advertisements are unicasted to the
   elected BSR based on the BSR specification.  When the PE is
   configured as BSR for a specific MVPN VRF, it MUST originate the BSMs
   as it would normally do and send them towards CE facing interfaces.
   PE also originates MVPN-MCAST-BSR NLRIs from the RP-Set it created by
   virtue of being a BSR and advertises them to other remote PEs.

5.1.  Handling Bootstrap messages

   BSR specification can be broadly classified into 3 stages:

   (a)  BSR election

   (b)  Candidate RP advertisements

   (c)  Elected BSR (E-BSR) advertising the RP-Set information

   Candidate RP advertisements are unicasted and hence it is not
   necessary to carry them in PMSI tunnels or convert them into BGP
   routes.  On the other hand, both the empty BSMs and the BSMs sent by
   the Elected BSRs (E-BSR) needs to be converted into BGP routes.

5.1.1.  Data for BSR Parameters Route

   The Bootstrap Router (BSR) election is based on the Bootstrap Message
   (BSM) transmitted with BSR priority, by the candidate BSRs.  Whenever
   a PE receives a BSM on a PE-CE link, it needs to originate a BSR
   Parameters Route with the BSR Address and Priority extracted from the
   BSM.  The BSR election on the PEs is done based on BSR Parameters



Kurapati, et al.       Expires November 25, 2013                [Page 9]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   Route received.  BSR Parameters Route also MUST contain the BSR-BGP
   Path Attribute with Fragment-Tag and "Group Count" fields set.
   "Group Count" is the number of Group prefixes this BSM is carrying.
   The "Group Count" field is not present in the original BSR
   specification and needs to be populated by the originating PE.  The
   Fragment Tag field can be any locally generated unique value at the
   originating PE.  The usage of this field is discussed in the next
   section.

5.1.2.  Fragmented BSMs

   BSR specification also provides a way to deal with fragmentation such
   that, if number of group-to-rp mappings exceed the packet size,
   semantic fragmentation is performed.  'Fragment tag' in the BSM
   distinguishes the fragments of the same BSM.  If the fragmentation
   boundary happens to be within a group prefix, the difference of "RP
   Count" and "Frag RP Cnt" in the BSM determines how many more RPs are
   to come.  When the fragmentation boundary falls at the group prefix
   (i.e a group range is fit entirely into a BSM fragment), then there
   is no way to determine if more such fragments are coming in other
   BSMs.  An originating PE SHOULD wait for all the fragmented BSMs to
   arrive before propagating the same in BGP, if it is known that more
   fragments are coming based on "Frag RP Cnt" value.  Otherwise, the PE
   SHOULD start converting the mappings into BGP NLRIs and advertise the
   routes as soon as the first BSM is received.  The receiving PE will
   start assembling the RP-Set based on the received Group-to-RP mapping
   routes and send the resulting BSM to the CE.  In the event of
   originating PE receiving subsequent fragments of the same BSM, it
   MUST advertise "BSR Parameters" NLRI with change in BSR-BGP path
   attribute reflecting the modified "Group Count".  However, the
   existing "BSM Group Parameters" and "BSM RP Parameters" routes are
   still considered valid and the new routes are to be treated as
   incremental routes by the egress PE.  This is possible because the
   Fragment tag value is same for the new mappings in the subsequent
   fragment.  The details of this are discussed in the next section.

5.1.3.  Mappings arriving in different BGP UPDATES

   Even without fragmentation, all the Group-to-RP mappings may not fit
   a single BGP UPDATE message at the originating PE.  The NLRIs can be
   split and sent into multiple BGP UPDATE messages.  In such a
   situation, egress PEs can know whether all the mappings are recieved
   by using the "Group Count" and the "RP Count" in the "BSR-BGP" Path
   attributes present in the BSR Parameters and BSM Group Parameters
   NLRIs respectively.  BGP Graceful Restart (GR) specification
   [RFC4724] also proposes End-Of-RIB marker that can be used for non GR
   purpose.  PEs MAY use End-Of-RIB marker to indicate the completion of
   all the route updates to the peer.  The peer to the ingress PE can be



Kurapati, et al.       Expires November 25, 2013               [Page 10]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   a BGP route reflector.  If negotiated for the MCAST-MVPN-BSR family,
   a BGP peer SHOULD wait for the End-of-RIB from the peer before
   advertising it to the other clients.  Egress PE SHOULD wait for the
   End-Of-RIB marker before considering the routes for BSM Group-to-RP
   mapping calculation and informing its corresponding CEs.

5.2.  Mapping individual groups to RP

   For a router or management system to determine the RP mapping for an
   individual multicast stream, the "PIM Group-to-Rendezvous-Point
   Mapping" specification [RFC6226] requires that the following be
   evaluated in addition to any dynamic Group-to-RP mappings: source-
   specific multicast (SSM) group ranges, dense mode (DM) group-ranges,
   embedded-RP encoded in the IPv6 group address, and statically
   configured Group-to-RP mappings.  This specific Group-to-RP mapping
   given by the algorithm in RFC6226 determines the RP that a router
   would use for joining PIM shared trees or sending PIM Register
   messages for individual streams.

   In addition to the dynamic RP group-range-to-RP mappings obtainable
   from BGP, a router or management system that needs to make these
   specific group-to-RP mapping decisions for individual streams is
   assumed to have knowledge of the same information required by RFC6226
   as all the routers in the multicast domain.  Specifically, it must
   know the source-specific multicast (SSM) group ranges, dense mode
   (DM) group-ranges, embedded-RP encoded in the IPv6 group address, and
   statically configured group-range-to-RP mappings.  How it learns
   these is outside the scope of this document.

5.3.  Triggered BSMs by egress PE

   Unlike the regular BSR implementations where the BSM is flooded,
   egress PE in this implementation is acting as a proxy and generating
   BSMs.  An egress PE MUST generate BSMs periodically from the mapping
   information taken from the MCAST-VPN-BSR NLRIs.  In addition to the
   periodic BSMs, whenever there is a change in BSM mapping, a triggered
   BSM MUST be generated which will then refresh the information on the
   CE.  Ingress PE and egress PE may not be in sync with each other in
   terms of timing.  Assume that periodic BSM is sent at t=0 and it
   received a change in BGP route with one RP withdrawn.  In this case,
   an egress PE generates a new BSM without waiting for BS_Period to
   expire.  There MUST however be a minimum of BS_Min_Interval time
   between each time a BSM is sent as noted in [RFC5059].  This will
   cause an extra BSM to be generated towards the CE whenever there is a
   change in Group-to-RP mapping in the egress PE.

5.4.  Reverse Path Forwarding for Dynamic RP advertisements




Kurapati, et al.       Expires November 25, 2013               [Page 11]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   BSR relies on variations of Reverse Path Forwarding (RPF) to ensure
   that advertisement messages do not loop through the network.  RPF
   delivery semantics must also be maintained across the BGP-MVPN
   service provider core for dynamic RP advertisements encoded in BGP.

   The BGP NLRI to be defined for dynamic RP advertisements includes a
   Originating PE's IP address field which can be used by PEs receiving
   advertisements via BGP to conduct RPF checks when handling these
   advertisements.  When a PE receives the MCAST-VPN-BSR NLRI for a
   particular MVPN from some other PE, the PE accepts the message only
   if the 'Originating PE's IP address' field is the selected upstream
   PE for the IP address of the Bootstrap router.  Otherwise, the PE
   simply discards the update.

5.5.  Interoperation with tunneled BSR

   In order for this specification to be incrementally deployable in a
   network, PEs that implement this specification must be able to
   interoperate with PEs that do not.  Such PEs that are not capable of
   advertising dynamic RP information in BGP will send tunneled BSR
   messages.

   For example, it is possible that a BSR router could be multihomed to
   multiple PEs, some of which advertise dynamic RP mappings in BGP and
   some of which encapsulate the native packets.  In such a topology,
   it's possible that each of the PEs connecting the site of the BSR
   sender will forward the redundant advertisements for the same sender
   to the other PEs across the core via the different protocol
   mechanisms.  Further, it is possible that different senders are
   connected to PEs with differing capabilities and unique
   advertisements will arrive from the core at PEs via different
   protocol mechanisms.

   In these scenarios in which there are non-capable PEs in the network,
   PEs sending dynamic RP advertisements via BGP may also choose to
   encapsulate the same advertisements as native BSR packets tunnel via
   the PMSIs of the BGP-MVPN for delivery to receiving PEs that are not
   capable of handling the dynamic RP advertisements from BGP.  However,
   when it is known that ALL PEs are capable of dynamic RP
   advertisements in BGP, PEs should filter multicasted BSR messages
   such that they are not encapsulated in PMSI tunnels.

   PEs receiving dynamic RP advertisements from the service provider
   core must apply RPF rules to the received advertisements regardless
   of the mechanism of delivery.  Propagation of native BSR encapsulated
   advertisements by receiving PEs enabled for dynamic RP advertisements
   in BGP should occur as if these advertisements were received from
   BGP, and as specified in this document.



Kurapati, et al.       Expires November 25, 2013               [Page 12]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


5.6.  Route Targets for Group-to-RP mapping routes

   By default the Group-to-RP mapping routes SHOULD have the same Route
   Targets as the VPN-IP unicast routes towards BSR/Mapping Agent/C-RP
   carried in these routes.  An implementation SHOULD allow to modify
   the default via configuration.  With the use of Route Target
   Constraint [RFC4684], the distribution of these routes can be
   controlled to only those PEs who have the RT configured.

5.7.  BSR multihomed

   When a BSR is multihomed, say to two PEs, both the PEs will originate
   the MCAST-VPN-BSR NLRIs.  In such a case, egress PEs SHOULD take the
   NLRIs from the PE based on single forwarder selection procedure
   described in section 9.1.2 of [RFC6513].

6.  Protocol Details

6.1.  Originating Group-to-RP Mapping route for bootstrap messages
      received on a VRF

   When a PE router receives a BSM message on its CE facing interface
   that is the RPF towards the BSR or configures an RP locally and is
   the elected BSR, the router will add the mappings to the local copy
   of Group-to-RP set.  The PE router will then form BGP NLRIs as
   mentioned in the previous section based on the received BSR message.
   The PE router will determine if there were any previous
   advertisements from the same BSR and if there is any change in the
   BSM content.  If the routes are already advertised and is not changed
   as a result of the BSR message, then the same is not re-advertised in
   BGP.  Refer to section 3.4 of BSR specification [RFC5059] for
   forwarding the received BSR messages.  Unless the BSR implementation
   requires a particular BSM to be blocked, BSR messages needs to be
   forwarded via BGP to the egress PEs.

   In the case where a new BSR has come up, it generates a BSM with
   empty content.  In such a case, only a "BSR Parameters" route is
   generated by the PE with BSR address and priority fields filled.
   Even if the BSR which sent empty BSM is not a preferred BSR (the
   current EBSR is better), "BSR Parameters" NLRI MUST be generated with
   this BSR address and sent to the remote PEs in order to maintain
   consistency with the BSR implementation.  The local BSR
   implementation will take care of chosing the right BSR.








Kurapati, et al.       Expires November 25, 2013               [Page 13]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   If a PE is rebooted or newly added, it may receive a BSM with "No-
   Forward" bit set or a unicasted BSM from the CE to which it formed
   PIM neighborship.  In either case, PE MUST originate the required
   NLRIs from the BSM and forward the same to the remote PEs.  There is
   no need to carry "No-Forward" bit in BGP for this scenario.

   As discussed in Section 5.1.2, if the BSM is fragmented and if the
   fragmentation boundary is at at group prefix, there is no way to tell
   whether more fragments will arrive.  Hence, the BSR routes are
   advertised as soon as the BSM is received.  If another BSM is
   received with same "Fragment Tag" field at a later time, the BSR
   implementation treats this as part of the same BSM that was received
   earlier.  Hence, these BSMs are converted to the respective BSR NLRIs
   and advertised to the BGP peers.

6.2.  Handling changes in BSR messages

   A PE router may need to withdraw a Group-to-RP mapping for which it
   has originated an advertisement based on several conditions.  If a
   BSM is received from a CE with a holdtime of zero for the mapping, or
   if a local PE is BSR and an RP is unconfigured, then the
   advertisement MUST be withdrawn immediately.  In addition, scenarios
   such as a BSM missing an RP mapping entry or missing BSMs entirely
   may necessitate withdrawal of advertised mappings.  A change may also
   happen to a group, where a new group may get added or existing group
   may be removed.  These needs to be propagated accordingly through
   BGP.

6.2.1.  Missing RP or Group mapping entry

   Assume a scenario where a given Group prefix had 100 RPs in the
   received BSM from a BSR.  In the next periodic update after BS_Period
   interval, only 99 RPs are present for that group.  This can happen
   when an RP did not go down gracefully (i.e, it did not advertise with
   Hold Timer = 0).  The BSR implementation on the PE will continue to
   keep the RP mapping until the "RP Hold Time" expires.  However, this
   needs to be communicated via BGP.

   In this scenario, originating PE will continue to keep the "BSR
   Parameters" route unchanged.  The "BSM Group Parameters" route for
   the respective group is re-advertised with change in the "RP Count"
   value in the BSR-BGP path attribute.  "Fragment Tag" field in the
   path attribute MUST NOT be changed.  Along with that, the respective
   "BSM RP Parameters" route (Type-3) MUST be withdrawn.

   Egress PE receiving a changed Type-2 route (BSM Group Parameters)
   MUST wait until the RP count matches before generating the BSM
   towards the CE with this change.  In case the "End-Of-RIB" is



Kurapati, et al.       Expires November 25, 2013               [Page 14]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   negotiated, this check SHOULD be performed only after the "End-Of-
   RIB" is received.  The RP will not be removed from the local group-
   to-rp mapping table until the RP hold time expires.  BSM that is
   advertised towards the CE is changed to reflect the missing RP.  This
   scenario also handles any out of sequence messages arising.  For
   example, if Type-3 (BSM RP Parameters) withdrawal comes before the
   changed Type-2 (BSM Group Parameters), the RP count check would fail
   making the egress PE wait until the update is complete.

   Another scenario to consider is when a RP for a group is removed and
   a new RP is added.  In this case, the "RP Count" remains same, but
   the BSM RP Parameters route (Type-3) corresponding to old RP is
   withdrawn, and Type-3 for new RP is advertised.  Even if these two
   arrive in two different BGP updates, the corresponding checks at
   egress PE will ensure that a BSM is triggered only when the Type-3s
   for the group is matched with the RP count in the corresponding BSM
   Group Parameters route (Type-2).

   Consider another scenario where initially the Group Count was 100.
   The new BSM received has the same Group Count, but one group removed
   and a new group added.  In this situation, an ingress PE need not
   generate a new "BSR Parameters" (Type-1) route since the group count
   did not change.  For the group which was removed from the BSM, the
   corresponding Type-2 route and its Type-3 routes MUST be withdrawn
   and a new BSM Group parameters route (Type-2) route with its RP
   parameters route (Type-3) MUST be advertised.  At the egress PE, as
   soon as the Type-2 withdrawal comes, all the corresponding RP entries
   (Type-3) are placed as inactive and MUST not be considered,
   irrespective of whether a withdrawal for those routes are received or
   not.  However, PEs SHOULD keep those routes until the actual
   withdrawals arrive.  The "Group Count" and its "RP Count" per group
   are to be matched before BSM is generated towards the CE.

   Lastly, consider a scenario where a new Group is added over the
   existing entries.  In this case, the "BSR Parameters" route is re-
   advertised with modified "Group Count" value, keeping the "Fragment
   Tag" same.  Along with that, "BSM Group Parameters" route and "BSM RP
   Parameters" route are generated for the new Group and RPs.  Again,
   the egress PE MUST wait for the values to match before generating the
   BSM towards egress.

6.2.2.  Missing BSM

   Like missing a particular mapping, missing an entire BSM can also
   happen due to several reasons.  It could be that the BSR went down
   ungracefully or BSM is missed due to congestion.  BSR specification
   [RFC5059] defines a timer BS_Timeout (defaults to 2*BS_Period + 10
   seconds) before declaring a BSR as dead and electing a new BSR.



Kurapati, et al.       Expires November 25, 2013               [Page 15]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   While most of the scenarios are taken care by the local BSR
   implementation on the PEs, we need to handle communicating the
   missing BSM between the PEs through BGP.  In the scenario of missing
   BSM, the corresponding "BSR Parameters" (Type-1) route is withdrawn,
   however the corresponding "BSM Group Parameters" route (Type-2) and
   "BSM RP Parameters" route (Type-3) entries MUST NOT be withdrawn by
   the ingress PE.

   Egress PE receiving a withdrawn "BSR Parameters" route (Type-1) MUST
   still keep the corresponding Type-2 and Type-3 entries.  However, it
   MUST NOT advertise the BSM to the CE without the Type-1 route
   present.  As soon as the Type-1 is withdrawn, BS_Timeout period has
   to be started at the egress and upon its expiry, all the Type-2 and
   Type-3 entries MUST be deleted.

   Say the egress has generated BSM at t=0.  At t=1 BS_Period expired at
   ingress PE and ingress PE did not get the periodic BSM.  So, it
   withdraws type-1 (BSR Parameters).  Egress PE has already generated
   BSM just before the type-1 withdrawal was received.  The egress PE
   skips the next periodic BSM towards the CE.  But CE is "off" by
   BS_Period interval by now.  Once the BS_Timeout expires, egress PE
   removes all the type-2 and type-3 entries.  CEs connected to egress
   PE will remove the same, a whole BS_Period later.  Hence, to avoid
   this issue, once the BS_Timeout expires,an egress PE MUST generate a
   new BSM towards CE with RP hold time set to "0" for all the type-2
   and type-3 entries.  This will make the CEs in sync with the the PEs.
   After generating the BSM, PE removes all the Type-2 and Type-3
   entries as stated above.

   After the BSR is timed out (after BS_Timeout), when a new BSM comes
   from the same BSR, a new "Fragment Tag" MUST be generated by the
   ingress PE.

6.2.3.  Change of Elected BSR

   As per the BSR specification [RFC5059], when a preferred BSM is
   received, the current 'Elected BSR' will transfer its state to
   'Candidate BSR' and forward the received BSM.  All the routers will
   also change the elected BSR based on the preferred BSM.  When an
   originating PE's local bootstrap module elects a new BSR, all the old
   Group-to-RP mapping entries advertised by the previous BSR MUST be
   withdrawn.









Kurapati, et al.       Expires November 25, 2013               [Page 16]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


6.3.  Receiving Group-to-RP Mapping routes for BSR

   The PEs receiving the BGP Group-to-RP Mapping route NLRIs will act as
   a proxy.  First step is to check if the received routes are valid.
   If the "Fragment Tag" present in the "BSR Parameters" route does not
   match with the "BSM Group Parameters" (Type-2) and "BSM RP
   Parameters" (Type-3) routes, then those entries are considered
   invalid.  Similarly, if the len of BSR/RP/Group Address field
   contains any value other than "0","32" or "128" it MUST be considered
   as a malformed message and MUST be discarded.  The PE MUST also run a
   RPF check for the BSR IP address and see if the originating PE
   address is the router through which the BSR is reachable.  If the
   preferred route to the BSR is through the core, RPF check is done as
   per the MVPN upstream multicast hop (UMH) selection described in MVPN
   specification [RFC6513].  If the advertising PE is not the PE
   matching UMH selection, or if the preferred route to the BSR is
   through one of the CE interfaces, the RPF check fails and the routes
   MUST be ignored.

   The receiving PE collects the Group-to-RP mapping routes per BSR IP
   address and makes an entry in its BSR Group-to-RP mapping table.
   From the Group-to-RP mapping per BSR, the egress PE forms a BSM
   message.  In order to generate the BSM message, the PE need to
   construct certain fields such as Checksum which is not available in
   the advertised NLRIs.

   Unlike CE PIM routers, the PE receiving Group-to-RP mapping routes
   via BGP will not receive periodic soft-state refreshes of the
   mappings every BS_Period.  The receiving PE MUST generate periodic
   BSMs every BS_Period as specified in the BSR RFC [RFC5059].  When
   there is a change in the corresponding Group-to-RP mapping routes, a
   fresh BSM MUST be triggered after the calculation of "Group Count"
   and "RP Count" matches.  Egress PE MUST also ensure that there is a
   minimum period of BS_Min_Interval between each time a BSM is sent
   towards the CE as noted in BSR specification [RFC5059].

   When a "BSR Parameters" (Type-1) route is received with "Group Count"
   as 0, the PE MUST treat it as an empty BSM.  An empty BSM MUST be
   formed and sent to the CEs with other relevant fields populated.
   Other aspects of electing a BSR based on the BSR priority MUST be
   same as what is specified in the BSR specification [RFC5059].

7.  Security Considerations

   Since a BSR message allows semantic fragmentation, a message can be
   very big with lot of mappings there by leading to PE generating
   several Group-to-RP mapping route NLRIs.  An implementation SHOULD be
   able to restrict the number of Groups and RP mappings allowed on a



Kurapati, et al.       Expires November 25, 2013               [Page 17]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   VRF or interface level so that the number of BGP routes generated for
   the mapping are controlled.

8.  IANA Considerations

   This document defines a new NLRI, called MCAST-VPN-BSR, to be carried
   in BGP using multiprotocol extensions.  It requires assignment of a
   new SAFI.

   This document defines a new BGP optional transitive attribute, called
   BSR-BGP.

9.  Acknowledgments

   The authors would like to thank Huajin Jeng (AT&T), Jeffrey Haas
   (Juniper), Yakov Rekhter (Juniper) and Eric Rosen (Cisco) for their
   valuable review and feedback.

10.  References

10.1.  Normative Reference

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, November 2006.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              January 2007.

   [RFC5015]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
              "Bidirectional Protocol Independent Multicast (BIDIR-
              PIM)", RFC 5015, October 2007.

   [RFC5059]  Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
              "Bootstrap Router (BSR) Mechanism for Protocol Independent
              Multicast (PIM)", RFC 5059, January 2008.





Kurapati, et al.       Expires November 25, 2013               [Page 18]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   [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.

   [RFC6515]  Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
              Addresses in BGP Updates for Multicast VPN", RFC 6515,
              February 2012.

   [RFC6226]  Joshi, B., Kessler, A., and D. McWalter, "PIM Group-to-
              Rendezvous-Point Mapping", RFC 6226, May 2011.

10.2.  Informative Reference

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

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

Authors' Addresses

   Pavan Kurapati
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA   94089
   USA

   Email: kurapati@juniper.net
   URI:   http://www.juniper.net/


   Marco Rodrigues
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA   94089
   USA

   Email: mprodrigues@juniper.net
   URI:   http://www.juniper.net/









Kurapati, et al.       Expires November 25, 2013               [Page 19]

Internet-Draft      Dynamic RP encodings in BGPMVPN             May 2013


   Kurt Windisch
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA   94089
   USA

   Email: kurtw@juniper.net
   URI:   http://www.juniper.net/


   Saud Asif
   AT&T LABS
   200 S Laurel Ave.
   Middletown, NJ   07748
   USA

   Email: sasif@att.com
   URI:   http://www.att.com/
































Kurapati, et al.       Expires November 25, 2013               [Page 20]