1. March 21, 2006L3VPN WG 1 MVPN Update New version of “bgp encoding” draft –BGP update syntax and semantics reworked to reflect current thinking –Inter-AS proposal fleshed out in detail Arch. draft not yet updated, to be done “shortly” This presentation will discuss: Changes from last rev Selected interesting topics Remaining open issues

2. March 21, 2006L3VPN WG 2 BGP Attributes for Unicast VPN- IPv4 Routes Extended communities to identify: –AS of origin –VRF of origin (including PE of origin) These are used for “RPF Lookup” when PE received C-Join from a CE –Root IPv4 address looked up in VRF –Get source AS for inter-AS trees (later) –Get address of upstream PE

3. March 21, 2006L3VPN WG 3 MCAST-VPN Address Family One AF, but multiple route types C-Multicast (C-M) Routes convey customer multicast routes (from within a VPN) Auto-Discovery (A/D) Routes convey information to set up MVPN infrastructure in the backbone: –Find other PEs and /or ASes of a given MVPN –Bind MVPN to default PMSI (I-PMSI) –Bind individual streams to S-PMSI –Bind PMSI to tunnel –A few other uses having to do with P-tunnel setup and/or binding of multicast streams to P-tunnels

4. March 21, 2006L3VPN WG 4 Intra-AS A/D Routes for Auto- Discovery NLRI : –RD of originating VRF –IP address of originating router Attributes : –RTs controlling route distribution –PMSI tunnel attribute, identifying default I-PMSI mechanism Enough info to set up “receiver-initiated join” type tunnels Other tunnel types may require additional BGP-based protocol based on “leaf a/d routes” –For aggregate trees, upstream-assigned MPLS label specified N.B.: Two intra-AS A/D routes are never comparable

5. March 21, 2006L3VPN WG 5 Other Uses of Intra-AS A/D Routes Bind to an S-PMSI –Include in the NLRI –Without binding applies to entire MVPN Active Source Advertisement (for “PE as RP” schemes) –Include in NLRI –Omit PMSI Tunnel Attribute

6. March 21, 2006L3VPN WG 6 C-M Routes Types: –Source tree join –Shared tree join –Prune source off shared tree Route type is part of NLRI –Different route types never comparable Claim: –with these route types, all PIM operations can be represented by BGP updates or withdraws

7. March 21, 2006L3VPN WG 7 C-M Routes NLRI: –“Reverse” RD RD from the VPN-IPv4 address of the root of this C-tree Slightly different procedure used for inter-AS –/32 Source (omitted in shared tree joins) –/32 Group Attributes: –RTs to control route distribution –Route Import target, identifying a particular PE as the “upstream PE”

8. March 21, 2006L3VPN WG 8 No “Originating PE” in C-M Routes Different PEs joining same C-tree generate comparable routes RRs and ASBRs install and redistribute just one such Upstream PE or ASBR sees 1 “join” per C-tree, need not do “explicit tracking” of receiving PEs (unless needed for P-tunnel type) RR is leveraged to allow PEs get effect of join suppression, without need to do join caching and prune override Control plane allows NBMA procedures which have some aspects of PIM LAN procedures and some aspects of PIM P2P procedures.

9. March 21, 2006L3VPN WG 9 Inter-AS Inter-AS Tunnel rooted at the source AS –Other ASs are nodes on this inter-AS tunnel Inter-AS Tunnel comprises “segments” –AS-AS tunnel segments that connect ASs together on the inter-AS tunnel –Intra-AS tunnel segment used by an AS to deliver traffic to PEs/ASBRs within an AS on the inter-AS tunnel Distinct from intra-AS trees A PE/ASBR receives traffic on a single intra-AS segment or AS-AS segment of the inter-AS tunnel

10. March 21, 2006L3VPN WG 10 Inter-AS MVPN Auto-Discovery Inter-AS Auto-discovery routes –granularity of –advertised by ASBRs –Aggregate intra-AS Auto-discovery information with granularity of –AS specific RD –All ASBRs within an AS configured with same AS specific RD Propagation of Inter-AS Auto-discovery routes from the source AS to other ASs leads to the creation of the inter-AS tunnel

11. March 21, 2006L3VPN WG 11 Inter-AS Tunnel Creation Inter-AS tunnels constructed by stitching tunnel segments –intra-AS tunnel segments stitched with AS-AS tunnel segments –Independent P-Tunneling technology per AS MVPN that is present in N ASes would result in N inter-AS P-tunnels (one per AS, not one per PE) –To improve scalability multiple intra-AS tunnel segments within an AS could be aggregated into a single intra-AS P-tunnel using upstream labels

12. March 21, 2006L3VPN WG 12 Inter-AS Tunnel Creation: Intra-AS Segment No intra-AS segment in source AS In other ASes, intra-AS segment is triggered when an ASBR receives an A/D route from an EBGP neighbor –ASBR readvertises this route in IBGP Also carries the intra-AS tunnel segment if the ASBR does not need to know the leaves ELSE Intra-AS Tunnel segment is advertised after learning the leaves –Other PEs/ASBRs are free to pick different upstream ASBRs Join the respective intra-AS tunnel segment Originate leaf AD routes if the upstream ASBR needs to learn the leaves

13. March 21, 2006L3VPN WG 13 Inter-AS Tunnel Creation: AS-AS Segment Interconnect adjacent ASBRs on the Inter- AS Tunnel When an ASBR receives an route from an EBGP peer it sends back a leaf A/D route –Carries a downstream assigned MPLS label –Tunnel segment identifier set to ingress replication

14. March 21, 2006L3VPN WG 14 Inter-AS C-M Routing Exchange MVPN PE-PE C-M Routing Exchange –Aggregation of MVPN Routing Information Granularity of Inter-AS MVPN C-M Routing Info is propagated by egress PE towards the source AS and the source PE –Propagates using the reverse path of the inter-AS auto- discovery routes, i.e. route No flooding –No Receiver (S, G) state in the ASBR forwarding plane

15. March 21, 2006L3VPN WG 15 Inter-AS… Control plane exchange between ASes only at ASBRs or RRs Use RT Constrain to limit distribution of auto- discovery routes and C-M routes Support of all three options for inter-AS unicast

16. March 21, 2006L3VPN WG 16 Topics: “Shared Tree” State join(*,G) and prune(S,G,R) –PIM sends single message saying “I want to join (*,G), but not for sources S1, S2, S3” –BGP handles these as 4 separate routes (not necessarily 4 separate updates) –The BGP-to-PIM state machine has some massaging to do: For a given G, PIM needs to react to the complete set of BGP join(*,G) and prune(S,G,R) states Not 1-1 corresp. between PIM & BGP messages

17. March 21, 2006L3VPN WG 17 What Replaces PIM Asserts If C-S multi-homed to several PEs in same AS, force all PEs to choose same upstream PE for given C-S –absolutely required for segments of inter-AS tree –presupposes different RD at each PE –selection not based on BGP-installed route Discard data on C-S tree if received on tunnel from “wrong” upstream PE and/or tunnel If a PE receives from both (C-*,C-G) and (C-S,C- G), need more: –Force all PEs to join C-S tree (using “leaf” a/d routes)

18. March 21, 2006L3VPN WG 18 C-Protocols that use Flooding BSR and other flooding-based protocols –Require default MI-PMSI –treat as data sent over default MI-PMSI –do not try to absorb into BGP control plane

19. March 21, 2006L3VPN WG 19 PEs, RPs, and MSDP Goal: –Enable removal of PIM-SM complexity in backbone No shared trees among sites No switching from shared trees, no pruning sources from shared trees, etc. Less control plane overhead, less state More stable traffic pattern in backbone –But don’t require each PE to be an RP Proposal: –PE runs MSDP with local RPs –PEs use BGP to advertise active sources Intermediate between “fully transparent” and “outsource your RPs”

20. March 21, 2006L3VPN WG 20 Dampening C-M Routes PE multicast routing rate of change is not directly proportional to terminal behavior: –After the first (S,G) Join, subsequent Joins for same (S,G) do not cause backbone signaling PE multicast routing rate of change depends on application Still, PEs may have to support a high rate of C-M route changes, causing PE-PE protocol load C-M route dampening is a possible solution –Principle: waiting before propagating a C-M routing change –Timers may increase with a backoff algorithm –May it hurt latency ? Only in some cases (see next slide)

21. March 21, 2006L3VPN WG 21 Dampening C-M Routes Dampening C-M ''prunes'' –Won't increase leave-latency perceived by the CE or end user –Can be done aggressively Dampening C-M “joins” only hurts the “first join” in the MVPN Where to dampen? –on the receiver-side PE, before propagating –on a route reflector

22. March 21, 2006L3VPN WG 22 Future Work Carrier’s Carrier Details for support of Bidir C-trees –DF forwarder election Use of MP2MP LSPs as P-tunnels for intra-AS tunnels and intra-AS segments of inter-AS tunnels BGP on the CE-PE link for multicast routes? –not transparent, but no worse than for unicast