MVPN Revisited draft-mnapierala-mvpn-rev-00

March 22 2007 IETF 68, L3VPN WG 1

MVPN Revisited

draft-mnapierala-mvpn-rev-00

IETF 68 March 2007

Maria Napierala


Summary of the Proposal• C-source is discovered based on 1st C-S packet received

on C-shared tree (PIM-SM) and on 1st (C-S, C-G) Join (PIM-SSM)

• PIM-SM C-trees are (by default) automatically triggered as SPTs by all egress PEs but there is no inter-PE RPT-to-SPT switchover initiated by C-routers

• If a source C-S is reachable via several PEs, downstream PE will choose its BGP best installed route to reach C-S. If multiple next-hops are installed the tie breaker is either highest IP address which is the default RFP selection method*

• PE joins only those tunnels that were announced by its best next hop to C-S

• Initial C-S traffic is dropped until the S-PMSI or UI-PMSI is built

* Or could be based on per multicast state load splitting but there is no standard method


New Additions

• To be added in the next version (-01) of the draft• Support of C-Shared Trees• Support of C-Bidir Trees• Support of Anycast C-RPs


Main Requirements• Multicast routing in VRF should follow its unicast routing

policy • Downstream PE should join only those tunnels that were

announced by its best next hop to C-S or C-RP– a tunnel to be used for C-S should not be created either before C-

source is discovered or after the source sends traffic natively on (C-S,C-G) state

• RPF neighbor (upstream PE) for C-S should be unique per set of VRFs with the same unicast routing policy towards the C-S– RPF neighbor selection should not include not installed BGP

routes because this might alter the expected traffic flows in MVPN

• Support of multiple RPF neighbors for Anycast C-RP is required


Main Differences from Other Proposal• C-Multicast Routing:

– Point-to-point based not LAN-based RPF neighbor selection (no DR or DR-like election procedure)

– RPF neighbor selection includes only BGP installed routes

– RPF neighbor is unique to set of VRFs with the same unicast routing policy

– PE joins only those tunnels that were announced by its best next hop to C-S or C-RP

– PIM-like support of Anycast C-RPs: any downstream PE on a single C-RPT to closest C-RP

• C-Source Discovery– does not require PEs to participate in C-RP source

discovery process – different Source Discovery for PIM-SSM and PIM-SM


Source Discovery in MVPN

• Proposed solution consists in ASM-like C-source discovery technique and results in the simplification of inter-PE multicast traffic patterns

• ASM C-source discovery process is “intercepted” by PE’s in order to extract C-source information

• Active C-sources become known in MVPN negligibly later than they would in plain ASM


Bypassing Shared Trees in MVPN

• Knowledge about active sources is used to eliminate inter-PE shared tree (RPT) to shortest path tree (SPT) switchover and to simplify PE-to-PE inter-site multicast routing – there are no inter-PE (C-S,C-G,rtp) Prune

messages • In order to eliminate inter-site RPT-to-SPT

switchover, PIM control procedures in MVPN context need to be modified. Those modifications are straightforward

• Proposed modifications of PE-to-PE multicast routing do not require changes to PIM protocol in the customer domain


Source Discovery Techniques

• Two source discovery techniques are defined, one for PIM-SM and one for PIM-SSM

• Active source C-S is discovered in MVPN when:

(PIM-SM): PE attached to C-RP receives the first (C-*, C-G) packet from C-S

(PIM-SSM): PE attached to C-S receives the first (C-S, C-G) join, either from directly connected CE or from another PE in MVPN


Source Discovery in PIM-SM – 1

• When C-RP receives PIM Register from C-S, it extracts from it multicast data packet and sends it over the shared (C-*, C-G) tree

• PE attached to C-RP “snoops” for a packet received on (C-*,C-G) and extract from it C-source address - this is no different from the last hop router extracting source address from the first packet it receives on shared tree in plain ASM procedure

• When PE attached to C-RP receives the 1st multicast packet from the source C-S over (C-*,C- G) tree it sends (C-S, C-G, rpt) Prune towards C-RP and announces the active source C-S to all PE’s in the MVPN

• PE attached to C-RP does not forward (C-*, C-G) traffic on the interface leading to SP’s core network


Source Discovery in PIM-SM – 2

• Upon receiving active C-S announcement message:– PE’s connected to C-S send tunnel announcements for

(C-S, C-G)– PE’s connected to receivers of C-G (i.e., egress PE’s)

convert (C-*, C-G) PIM Join/Prune messages received from locally attached CE’s to (C-S, C-G) PIM Join/Prune for all active sources C-S. Each egress PE will send (C-S, C-G) join to its best next-hop to C-S

• Any PE with (C-*, C-G) or (C-S, C-G) state that receives tunnel announcement for (C-S, C-G) with join the tunnel announced by its best next hop to C-S


Source Discovery in PIM-SM – 3 C-Source Becomes Inactive

• When C-S stops sending traffic (C-S, C-G) state expires on PE’s attached to C-S

• PE’s attached to C-S sent source withdrawal message for (C-S, C-G)

• Egress PE’s stop joining tunnels announced for (C-S, C-G) and remove source and tunnel information


Source Discovery in PIM-SM – 4 Dually Homed C-Receivers

• There could be scenario where a dually homed MVPN site with receiver(s) chooses a different next-hop PE depending on whether a shared (C-*,C-G) tree or source (C-S,C-G) tree is joined. In means that shared and source trees diverge at this site

• Egress PE on the C-RPT will receive (C-S,C-G,rtp) Prune message from its directly connected CE

• Egress PE on the C-RPT will prune itself off (C-S, C-G)-tree and the tunnel for (C-S,C-G) if there are no receivers for (C-*,G) or (S,G) attached to it

• Egress PE on C-SPT will join the tunnel for (C-S,C-G) if it was not joined yet


Supporting Shared Trees

• MVPN customer might require to never switch to SPT’s for a particular C-G. The information of such C-groups has to be known to SP and has to be made known to PE’s with this MVPN

• A PE attached to a C-RP for C-G will be the root of the tunnel for all sources sending to C-G


Supporting Shared Trees – 1• PE attached to C-RP, upon receiving (C-*, C-G) PIM Join

from another PE, follows normal ASM procedure• When PE attached to C-RP receives 1st multicast packet

over (C-*, C-G) tree (from any C-S), this PE forwards it to its OIL for (C-*, C-G) and announces the active group C-G and tunnel to be used for C-G traffic to all PE’s in the MVPN:– if MI-PMSI exists then the initial (C-*, C-G) packets could be sent

over this tunnel (more on this on slide 18)– if MI-PSMI does not exist and since UI-PMSI or S-PMSI tunnel for

C-G is not built yet, the initial (C-*, C-G) packets sent to the interface leading to SP’s core network will be dropped

• PE’s attached to receivers of C-G upon receiving the C-G announcement will join the tunnel announced by the best next hop to C-RP for C-G


Supporting Shared Trees – 2

• (C-S, C-G) Joins/Prunes received from any site other than the site with C-RP for C-G will be dropped at PEs

• PE attached to C-S upon receiving 1st (C-S, C-G) Join (from C-RP) announces the tunnel to be used for (C-S, C-G) traffic

• PE’s attached to C-RP joins this tunnel


Source Discovery for PIM-SM – Summary

• All (C-*, C-G) data traffic between PE’s is blocked and inter-PE RPT to SPT multicast traffic switching is eliminated

• Inter-PE (S,G,rpt) Prunes messages are eliminated

• Regardless of whether or not the traffic in C-network switched to SPT’s, PE-to-PE MVPN traffic is sent only on SPT’s

• All traffic to C-G can be kept on a shared tree if required


Source Discovery in PIM-SSM• PE attached to C-S, upon receiving 1st (C-S, C-G) Join

from another PE or from a locally attached site, announces tunnel for (C-S, C-G) traffic

• Upon receiving tunnel announcement a PE connected to receiver(s) of (C-S, C-G) joins the tunnel announced by its best next hop to C-S

• When C-S stops sending traffic then (C-S, C-G) expires on PE’s attached to C-S and those PE’s sent tunnel withdrawal message for (C-S, C-G)

• Egress PE’s stop joining tunnels announced for (C-S, C-G) and (all PE’s) remove the tunnel information


Choices for Handling Initial Packets Sent over C-RPT

• C-multicast traffic is dropped until S-PMSI is built• C-multicast traffic is dropped until UI-PMSI is built. UI-PMSI

should be announced during MVPN discovery and built upon receiving C-S active announcement message. The UI-PMSI and S-PMSI are rooted at the same ingress PE and hence there will no traffic shifts in the SP network when traffic is switched from UI-PMSI to S-PMSI

• Traffic from C-S is not dropped but sent on MI-PMSI, announced and built during MVPN discovery, until S-PMSI for C-S tunnel is announced and built– since the root of MI-PMSI might be different than the root of S-

PMSI, the C-S traffic might shift between two different tunnels– if PIM-on-LAN procedure is used for C-multicast routing the

Assert process will force the same single forwarder for entire MVPN. Hence, with PIM-on-LAN the initial C-RPT traffic cannot be sent over MI-PMSI

Since the initial traffic even if sent could be meaningless to receivers, there is no advantage in using MI-PMSI for C-traffic


Handling Multiple Equal Cost Paths to C-S/C-RP

• If there are multiple next-hops to C-S or to dynamic C-RP installed by BGP in VRF, PE with the highest IP address is chosen as the next hop*

• If there are multiple next-hops to static C-RP installed by BGP in VRF, the closest PE (based on SP network IGP cost) is chosen as a next hop and only as a tie breaker the PE with the highest IP address

• IGP cost-based next-hop selection provides PIM-like support of Anycast C-RP’s: C-receivers join the closest Anycast C-RP across SP network– PE cannot distinguish multiple next hops to C-RP due to different

Anycast C-RPs or due to static/Anycast C-RP being dually homed with equal-cost. Hence, closest distance-based next hop selection could trigger more tunnels in SP network

*Or per multicast state load splitting could be but it is not standardized


Supporting Anycast C-RPs

Static/Anycast C-RP can be supported in one of

following ways:

1. Using IGP cost in the best route selection to static C-RP (default static C-RP selection)

2. Tie breaker is always the highest IP address but VPN uses different unicast routing policies to reach different Anycast-RP’s serving C-G. This allows MVPN customer to define its Anycast C-RP selection


Supporting C-Bidir – 1• PIM Bidir chooses single Designated Forwarder

(DF) for upstream packets (away from the source) on every network segment and point-to-point link– the DF election procedure eliminates parallel downstream

paths from any RP

• Two options of supporting C-Bidir Trees– all VRFs of the same VPN have to have the same unicast

routing policy; the best next hop to C-RP is chosen as a DF for C-RP’s bidirectional groups (tie breaker is the highest IP address)

– a group of VRFs with the same unicast routing policy uses unique (across MVPN) C-RP(s) with unique (across MVPN) bidirectional groups


Supporting C-Bidir – 2

• Designated Forwarder PE upon receiving (C-*,C-G) Join from another PE announces the tunnel to be used for C-G traffic– for scalability, C-Bidir traffic should use MP2MP

tunnels in SP network (build with PIM Bidir or with MP2MP LSPs)

• If Designated Forwarder PE prunes interface leading to SP core network from its OIL for (C-*, C-G) (i.e., all remote PEs pruned themselves off (C-*, C-G) tree), this PE announces the tunnel withdrawal for C-G


Additional Requirements

• Discovery of multipoint-to-multipoint/few applications (will be added to next version of the draft)

• Tunnel aggregation – receiver tracking• Support of C-BSR and C-Auto-RP

– still require default MI-PMSI– based on refresh mechanism (every 60 sec)

Documents

MVPN Revisited draft-mnapierala-mvpn-rev-00