MVPN Update Continued work on both architecture draft and BGP-MVPN draft Seeing “light at end of tunnel” ☺ Progress since last time: Carrier’s carrier procedures specified Inter-AS procedures written Single Forwarder Selection procedures written Procedures for use of MSDP to avoid tree switching Refined definition of “MVPN”, to make it clear that some sites may be receive-only and some may be transmit only Arch. and BGP encoding drafts now aligned July 14, 2006 IETF 66, L3VPN WG

Issues to be Discussed Today Change: Eliminating (S,G,R) prunes New (work in progress): Support of C-bidir trees Use of MP2MP P-LSPs July 14, 2006 IETF 66, L3VPN WG

Eliminate (S,G,R) Prunes from BGP Control Plane Very desirable, reduces state and complexity Two Alternative Methods: MSDP-based: Every C-RP uses MSDP to announce Active Sources to at least one PE Coordinated switch: when one PE switches from (C-*,C-G) to (C-S,C-G), force others to do so as well Both methods use BGP-based Source Active messages, already defined. July 14, 2006 IETF 66, L3VPN WG

MSDP-Based Method Each C-RP talks MSDP to a PE Some variations, such as co-location and anycast RP PEs use BGP to tell each other of active sources When a PE has PIM Join(*,G) state from a CE, the PE instead joins all the (S,G)’s If MSDP message has piggybacked data packet, send it over default I-PMSI, if possible Prevents “first packet loss” Does add some complications to the procedures for handling packets received on MI-PMSI Optional July 14, 2006 IETF 66, L3VPN WG

Coordinated Switch Method CE switches to (S,G) CE sends Join(S,G) to upstream PE PIM neighbor That PE uses BGP to send (S,G) Join That Join is received by PE connected to source PE connected to source sends BGP-based Source Active message Other PEs switch to (S,G) as well because they receive the Source Active message Ingress PE on (C-*,C-G) (PE connected to site that has RP) sends PIM (S,G,R) prune to upstream CE neighbor But no BGP-based (S,G,R) prune messages July 14, 2006 IETF 66, L3VPN WG

Support for C-Bidir Trees Assuming unidirectional P-Tunnels PIM Bidir has complex forwarding rules depending on whether packet is received from up- or downstream Must carefully define how a PE determines whether a given packet is traveling upstream or downstream PIM Bidir fundamentals: choose single Designated Forwarder for packets from upstream on each “link” We have BGP-based procedures for this choice We can discard packets that come from upstream but from the wrong transmitter Transmitter always known when unidirectional P-tunnels are used July 14, 2006 IETF 66, L3VPN WG

Choose one Ingress PE For this slide, assume everything is intra-AS Choose one PE to be ingress PE for the C-tree Procedures already defined Other PEs must not transmit packets arriving from upstream If some wrong PE does do so, PEs receiving packets arriving from upstream from wrong PE must discard them As long as P-trees are unidirectional, can always tell who transmitted a given packet, can discard if transmitter is “wrong” July 14, 2006 IETF 66, L3VPN WG

Multi-AS C-Bidir Choose “Root AS” Need to define procedures Previous slide applies within root AS At border routers, discard packets from upstream which aren’t from proper root AS Root AS can always be identified, as there are distinct unidirectional tunnels from each ingress AS July 14, 2006 IETF 66, L3VPN WG

MP2MP LSPs as Intra-AS Tunnels For every multicast flow: Single ingress PE must be designated transmitter of packets traveling downstream We have procedures to choose a single ingress PE For safety’s sake we want an egress PE to discard packets arriving from wrong ingress PE Therefore it must be possible to identify packets on the LSP by their transmitters Really a matter of aggregating P2MP tunnels into an MP2MP tunnel Dependency on work in progress in MPLS WG July 14, 2006 IETF 66, L3VPN WG

MP2MP LSPs Aggregating Segments of Inter-AS Tunnels Inter-AS Tunnels are always P2MP Intra-AS segments of Inter-AS tunnels are therefore inherently P2MP Within a single AS, we would like to aggregate all these segments (for a given MVPN) into a single MP2MP LSP Dependency on MPLS context-label procedures (work in progress) to identify transmitting ASBR, with upstream-assigned label identifying the particular inter-AS tunnel (i.e, the root AS of that tunnel) July 14, 2006 IETF 66, L3VPN WG

BGP-MVPN Update draft-raggarwa-l3vpn-2547bis-mcast-bgp-02.txt The following slides list the main changes July 14, 2006 IETF 66, L3VPN WG

New Auto-Discovery (AD) Route Types S-PMSI AD route To switch traffic for one or more <C-S, C-Gs> to a S-PMSI. Switching to S-PMSI described in terms of the S-PMSI AD route Different AD route types for I-PMSI AD and S-PMSI AD July 14, 2006 IETF 66, L3VPN WG

New Auto-Discovery (AD) Route Types… Source Active AD route Used to advertise active sources for the scheme that co-locates a C-RP on a PE This scheme described in terms of the SA AD route Used to advertise an active source to force all PEs to switch to the C-source tree from the C-shared tree, when one PE switches from the C-source tree to the C-shared tree Procedures for choosing a single forwarder PE when switching from RPT to SPT described July 14, 2006 IETF 66, L3VPN WG

C-Multicast Routing Protocol Added procedures for mLDP as a C-multicast routing protocol For Carrier’s Carrier July 14, 2006 IETF 66, L3VPN WG

C-Multicast Routes C-multicast route dampening Dampening of C-mcast prunes May cause a PE to receive unwanted traffic Dampening of C-mcast joins May result in join latency for the first join Dampening of leaf AD routes C-multicast route aggregation Clarified C-multicast route aggregation by RR and also by an ASBR July 14, 2006 IETF 66, L3VPN WG

Next Steps Procedures for using MSDP or PIM Anycast RP between C-RP and PE based scheme Procedures for using BGP or RSVP-TE as the PE-CE protocol for Carrier’s Carrier model are for further study July 14, 2006 IETF 66, L3VPN WG