1 / 22

MVPN Update

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

lhathaway
Download Presentation

MVPN Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 L3VPN 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 L3VPN 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 L3VPN 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 L3VPN WG

  5. Other Uses of Intra-AS A/D Routes • Bind <S,G> to an S-PMSI • Include <S,G> in the NLRI • Without <S,G> binding applies to entire MVPN • Active Source Advertisement (for “PE as RP” schemes) • Include <S,G> in NLRI • Omit PMSI Tunnel Attribute L3VPN 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 L3VPN 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” L3VPN 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. L3VPN 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 L3VPN WG

  10. Inter-AS MVPN Auto-Discovery • Inter-AS Auto-discovery routes • granularity of <Source AS, MVPN> • advertised by ASBRs • Aggregate intra-AS Auto-discovery information with granularity of <PE, MVPN> • 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 L3VPN 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 L3VPN 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 <AS, MVPN> 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 L3VPN WG

  13. Inter-AS Tunnel Creation:AS-AS Segment • Interconnect adjacent ASBRs on the Inter-AS Tunnel • When an ASBR receives an <AS, MVPN> 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 L3VPN WG

  14. Inter-AS C-M Routing Exchange • MVPN PE-PE C-M Routing Exchange • Aggregation of MVPN Routing Information • Granularity of <AS, C-S/C-RP, C-G> • 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. <source AS, MVPN> route • No flooding • No Receiver (S, G) state in the ASBR forwarding plane L3VPN 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 L3VPN 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 L3VPN 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) L3VPN 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 L3VPN 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” L3VPN 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) L3VPN 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 L3VPN 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 L3VPN WG

More Related