Multicast Signaling using BGP IETF 64 Nov 2005 Gargi Nalawade gargi@cisco.com Nidhi Bhaskar nidhi@cisco.com Pranav Mehta pmehta@cisco.com

PE-PE signaling for Multicast VPNs Multicast VPN PE-PE signaling exists with PIM LAN procedures Push for having the PE-PE signaling for non-LAN based approach Latter requires procedures for PIM Join/Prune, binding (among other things) Push for using BGP for the purpose Aim to describe the required protocol changes and analyze the impact on BGP/PIM

Enhancements required in BGP Multicast PE-PE (Overlay) SAFI RT/RD Import/Export Filtering PIM/BGP Interaction Inter-AS No extensions for Unicast Reachability. Rely on existing VPNv4 Unicast for that.

New SAFI – Multicast Overlay SAFI NLRI - {RD:G:Flags:S/RP:U-PE:D-PE} Flags : RPT Bit, WC Bit D-PE Optional, Label Optional. Update from D-PE to U-PE : RD:G:Flags:S/RP:U-PE:D-PE Update from U-PE: RD:G:Flags:S/RP:U-PE, Inner-Label Tunnel Identifier carried as Attribute

Transit for VPN SSM - BGP BGP Update: RD:232.1.1.1:SPT:1.1.1.1:PE-4:PE-2 BGP Update: RD:232.1.1.1:SPT:1.1.1.1:PE-4:PE-2 RR PE-1 PIM-V4 VRF JOIN: 1.1.1.1, 232.1.1.1 e0 e1 PIM-V4 VRF JOIN: 1.1.1.1, 232.1.1.1 BGP Update: RD:232.1.1.1:SPT:1.1.1.1:PE-4 Label=200, FEC=FEC200 PE-2 CE-2 Receiver1 PE-4 CE-4 Source = 1.1.1.1 PE-3 e0 CE-3 Receiver2

Route-Targets/RD RTs are carried as in Unicast VPNv4. Cleaner to define new RTs for multicast. RD, “traditionally” multicast uses U-PE’s RD.

BGP- Issue w/ Re-using unicast RTs PE-2 Red VRF: RD2 Import RT: RT1 Export RT: RT2 Blue VRF: RD3 Import RT:RT1 Export RT:RT3 P PE-1 Red VRF: RD1 Import RT:RT2 Export RT:RT1 e0 e1 PE-2 CE-Y Source=2.2.2.2 PE-1 CE-X Host = 1.1.1.1 PE-3 e0 PE-2 Unicast imports reachability for 1.1.1.1 into Red and Blue VRF. When host 1.1.1.1 joins towards 2.2.2.2 ->We don’t want join imported into both Red and Blue table. CE-Z Receiver2

BGP - Filtering Attach U-PE as Attribute for filtering J/P NLRI. Or Assign an RT per upstream PE… Use ORF/RT-Constrain to filter Tunnel Binding/RP Mappings. Filtering further to keep binding state only along multicast tree is not specified.

PIM/BGP Interaction PIM Join or Prune is not part of NLRI. S/RP,G Join is NLRI MP_REACH. S/RP,G Prune is NLRI MP_UNREACH. S,G,RPT Prune is NLRI MP_REACH. S,G,RPT Join is NLRI MP_UNREACH PIM Mode is not encoded in NLRI. RP Mappings carried via separate BGP SAFI. Can combine into same SAFI if necessary. RD:Flags:G/mask:RP

BGP Inter-AS Multicast specific “aggregation”. No need to carry forward tracked downstream PEs from one AS to another. “RPF lookup” to find Upstream ASBR. Tunnel/Binding information updated at ASBR.

ABSR Exchange VPNv4 Routes - Option B Update Sent to PE1: PE1:G:SSM:S:ASBR1 Update Sent to ASBR1: ASBR1:G:SSM:S:Label100:FEC-Y Update sent to ASBR2: ASBR2:G:SSM:S:PE2 Update sent to PE2: ASBR2:G:SSM:S:Label20:FEC-X vpnv4 RD:S NH=PE1 vpnv4 RD:S NH=ASBR1 ASBR2 Update to ASBR1: ASBR1:G:SSM:S:ASBR2:Label10 vpnv4 RD:S NH=ASBR2 ASBR1 ASBR2 PE1 AS 2 PE2 AS 1 next-hop-self towards iBGP neighbors CE1 CE2 CE3 CE4 S

BGP Futures/Open Issues BGP will not restrict Binding state to multicast tree. New functions in BGP like aggregating D-PE, U-PE based filtering, RPF lookup on ASBR and probably others. Not enough bits to encode SAFI length for IPv6!! RR Stores 1 multicast route as N*NLRI where N is #of D-PEs interested in stream. Some PIM updates are full-state. Will need careful mapping of PIM states to BGP updates and state machine. Need better understanding of the number of multicast streams and the rate at which they churn. Extensions to support Bidir-PIM/BSR, PIM Asserts