61st IETF Washington DC November 2004 BGP/MPLS IP Multicast VPNs draft-yasukawa-l3vpn-p2mp-mcast-00.txt Seisho Yasukawa (NTT) Shankar Karuna (Motorola) Sarveshwar Bandi (Motorola) Adrian Farrel (Old Dog)

61st IETF Washington DC November 2004 Motivations Establish a solution framework for IP Multicast VPNs which can provide QoS guarantees and reliable IP multicast services while giving the SP enough network operation & management capabilities. – Focus is multicast VPN not multicast VPLS Scalable architecture – Avoid overhead of PIM adjacency maintenance in or across the P- core – Avoid suboptimal IP multicast distribution Shortest paths – Within P-core – Across entire customer network Replication as late as possible – Avoid data tree switch-over (shared to source-based) over P-core Easy & flexible operation – Control and manage VPN customer’s IP multicast traffic distribution using provider’s facilities. – Introduce QoS guarantees & TE (Explicit route indication, FRR etc) capabilities

61st IETF Washington DC November 2004 Basic network model Adopt BGP/IP MPLS VPNs network model. Each CE is a multicast routing (PIM) adjacency of an attached PE router. Already use BGP for VPN membership discovery Extend BGP use for exchange of IP multicast routing information Establish P2MP TE based MDTs to forward IP multicast data over P-core. Preserve two important features – Separation of customer’s multicast control and forwarding plane in the P- core. – Distribution of customer’s multicast routing information via provider’s routing facility. Source/DR CE RP CE Receiver P PE C-IPmcast network C-IPmcast network C-IPmcast network Provider IP/MPLS network PIM adjacency MVRF PIM adjacency BGP (IPmcast membership discovery & routing info) P2MP TE based MDT PE

61st IETF Washington DC November 2004 Source/DR CE Receiver Proxy-Source/RP P Proxy-RP Proxy-Source/RP Proxy-Source/RP model All PEs which are members of a VPN act as proxy-Source/RPs. Each PE which acts as proxy-Source/RP terminates customer’s PIM messages, this enables independent PIM network operation within each customer site. P2MP TE based MDT interconnects PEs so that each downstream PE can receive IP multicast data via the MDT. – Note that the P-core connectivity is a separate issue It is possible to use any tunneling transport over the P-core (e.g. P2P MPLS TE, GRE) P2MP MPLS TE is an optimization in the P-core Independent PIM network Provider IP/MPLS network PE Receiver Independent PIM network

61st IETF Washington DC November 2004 Exchanging IP multicast register information Use MDT-SAFI to discover PEs of same VPN. The provider’s group address advertised in this SAFI is used to map the default MDT to a VPN Introduce Source Active (SA) SAFI to announce the activation of a particular customer’s IP multicast data stream. The provider’s group address advertised in this SAFI is used to map a data MDT to a VPN Introduce JOIN SAFI to announce the interest of a particular PE to join/prune a particular customer’s IP multicast data stream | | | RD (8 octets) | | PE's IPv4 address | | (4 octets) | | Provider's Group-address | | (4 octets) | |Customer's Source-address| | (4 octets) | |Customer's Group-address | | (4 octets) | | | | RD (8 octets) | | PE's IPv4 address | | (4 octets) | |Customer's Source-address| | (4 octets) | | Customer's Group-address| | (4 octets) | SA SAFI JOIN SAFI

61st IETF Washington DC November 2004 Source CE#1 CE#2 CE#4 Receiver P PE#1 P-MPLS network CE#3 Receiver PE#2 PE#3 PE#4 MVRF PIM-SM operation example MP-BGP(MDT-SAFI) PIM register message MP-BGP (SA-SAFI) Register stop message Join(*,G) MP-BGP (JOIN-SAFI) Source specific Join message Join(S,G) Configuring MVRFs on PE triggers exchange of MDT-SAFI information Default MDT: Each PE sets up P2MP tunnel to other PEs of the same VPN Interested receivers send their joins to the PEs (the RP for this site)

61st IETF Washington DC November 2004 Default MDT creation DRPE1 PE2 CE MP-BGP(MDT-SAFI[RD, PE1, p-G1]) Path Resv Default P2MP LSP to MVRF mapping MP-BGP(MDT-SAFI[RD, PE2, p-G2]) Path Resv Default P2MP LSP to MVRF mapping

61st IETF Washington DC November 2004 PIM-SM operation example DRPE1 PE2 CE Register message MP-BGP(SA-SAFI[RD, PE1, p-G,c-S,c-G]) Join(*, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-G]) Source-specific Join Register stop message Register message Register stop message Join(*, G) IP Mcast Data (S,G) IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G) Switch to Data P2MP (set P2MP with p-G announced in SA-SAFI) Path Resv Data P2MP LSP to MVRF mapping IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G)

61st IETF Washington DC November 2004 PIM-SSM operation example DRPE1 PE2 CE Join(S, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-G]) Join(S,G) IP Mcast Data (S,G) IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G) Switch to Data P2MP MP-BGP(SA-SAFI[RD, PE1, p-G’,c-S,c-G]) Path Resv Data P2MP LSP to MVRF mapping IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G) Ingress PE can figure out interested receiver PEs

61st IETF Washington DC November 2004 Characteristics Can support PIM-SM/PIM-SSM with same model. Support Data-MDT - SA SAFI sends Data-MDT information - After ingress PE receives JOIN SAFIs, the PE can establish Data-MDT dynamically to interested PEs. - That is, add receivers to P2MP TE LSP Support Multiple topologies of MDT. - P2MP tree - MP2MP tree (Needs stitching P2P LSPs with a P2MP LSP) - Support for other tunnel technologies (e.g. GRE) Supports Multi-AS operation Supports same RD operation as unicast rfc2547bis. Enforce policy operation by RT. SP can manage/monitor VPN customer’s IP multicast distribution. - Monitor VPN customer’s Mcast distribution by RR - Control Mcast traffic distribution pattern within a core by P2MP TE. Enable stable & scalable operation - Tree transition (Shared tree to source specific tree) - Transition does not propagate across the provider core.

61st IETF Washington DC November 2004 OPEN issues Applicability to PIM-DM and PIM-BIDIR. Optimize Default/Data P2MP tree operation - Number of Default P2MP trees can be reduced. - A lot of combinations exist when multiple Mcast flows share Default/Data P2MP tree. - Possibility to introduce further aggregation Details of protection mechanism for multi-homing. Details of multi-provider operation.

61st IETF Washington DC November 2004 Next steps Revise the draft to resolve open issues. Need WG’s input for polishing up this solution especially in following areas. - Is P2MP TE MPLS applicable to MVPN? - Agreement to introduce Proxy-Source/RP method to enhance scalability and manageability of Multicast IP VPNs. Offer these mechanisms as input to the development of a future Multicast IP VPN solution – Cooperate with other solution teams to Find common ground Develop a single solution for the WG