Why Do IPv6 over MPLS?

Transcription

1 IPv6 and IPv6 VPN services over MPLS Quality Excellence for Suppliers of Telecommunications TL 9000 Certified Mark Williams 1 Why Do IPv6 over MPLS? IPv6 Layer 3 VPN Maybe have connecting members with multiple sites connected over your backbone. IPv6 L3 VPN allows them to have a single rather than multiple prefixes. Useful where the core and edge are separately managed. Perhaps for stability reasons you don t want to touch the IPv4/MPLS core. Can offer IPv6 services simply by updating the PE routers. Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) Transition mechanism. 2 1

2 Talk in a Nutshell Describe how IPv6 L3VPN and 6PE work. have been deployable and interoperable for some time now. Look at how to do multicast on L3VPN. (MVPN). Has also been deployable and interoperable for some time now. IPv6 extensions for MVPN Allows you to do IPv6 muticast on L3VPN in the same way as for IPv4. One of the last pieces in the puzzle. Imminently deployable. 3 Agenda Introduction/Overview IPv6 Layer 3 VPNs Connecting IPv6 sites over IPv4 enabled MPLS Conclusion 4 2

3 Provider-Provisioned VPN Solutions for IPv6 Networks Corporate Headquarters Intranet Shared IPv4 Infrastructure Remote Access Branch Office Mobile Users and Telecommuters Extranet Suppliers, Partners and Customers Provider-provisioned VPN solutions (PP-VPNs) Layer 2: MPLS VPNs (draft-kompella) Layer 2: VPLS (draft-kompella) for Ethernet based connections Layer 3: MPLS-based VPNs for IPv6 Extensions to RFC 2547bis to support IPv6 VPNs draft-ietf-l3vpn-bgp-ipv6 5 PP-VPNs Terminology VPN Site Customer Edge Provider Routers Provider Edge VPN A Site 1 CE PE P P PE CE Site 2 VPN A VPN B CE Site 2 CE Site 1 PE Customer Edge device: device located on customer premises Provider Edge device: maintains VPN-related information, exchanges VPN information with other Provider Edge devices, encapsulates/decapsulates VPN traffic Provider router: forwards traffic VPN-unaware VPN B 6 3

4 Agenda Introduction/Overview IPv6 Layer 3 VPN Connecting IPv6 sites over IPv4 enabled MPLS Conclusion 7 IPv6 L3 VPNs BGP/MPLS IP VPN method (2547bis) extended to support of IPv6 BGP: extended to carry labeled IPv6 routes IPv6 VPN address family LDP and RSVP: add routes to ipv4-mapped ipv6 addresses Allows route resolution of IPv6 next hops Ipv4 address of the tunnel end point is extracted from ipv4- mapped ipv6 nexthop MBGP is used for VPN route distribution MPLS is used to forward VPN packets Supported in JUNOS since 5.7R1 release 8 4

5 L3 VPN over MPLS (a la 2547bis) draft-ietf-l3vpn-bgp-ipv6 VPN A Site 1, IPv6 VPN A Site2, IPv6 VPN B Site 1, IPv4 Static Routes CE A1 PE 1 CE B1 P P P P CE A2 PE 3 PE 2 OSPF Routing CE B2 CE A3 E-BGP VPN B Site2, IPv4 VPN A Site 3, IPv6 VPN C Site 1, IPv4 CE C1 C1 VPN B Site3, IPv4 CE B3 CE C2 C2 VPN C Site 2, IPv4 9 PP-VPN: 2547bis Operational Model Overview VPN A Site 1 CE A1 P P CE A2 VPN A Site2 VPN B Site2 VPN B Site 1 PE 1 CE B1 P PE 2 PE 3 Control Flow Routing information exchange between CE and PE (any protocol) Routing information exchange between PEs (MP-BGP) LSP establishment between PEs (RSVP or LDP signaling) Data flow Forwarding user traffic between PEs through LSPs P CE A3 CE B2 VPN A Site

6 PP-VPNs for IPv6 Extensions to RFC 2547bis to support IPv6 VPNs over an IPv4 or IPv6 backbone The content of this presentation is related to an IPv4 backbone PE routers are dual stack (IPv4/IPv6) capable All CEs within an IPv6 VPN are IPv6 capable MPLS is used to forward packets over the backbone But also 2547 GRE/IP and 2547 IPSec/IP can be used VPN A IPv6 CE PE P P PE CE IPv6 VPN A VPN B IPv6 CE IPv4 or IPv6 PE CE IPv6 VPN B 11 VPN Routing and Forwarding Tables (v4 s & v6 s) VPN B Site 1 VPN A Site 1 IPv6 IPv6 Static Routes PE 1 RIPng CE B1 A is created for each site connected to the DS-PE CE A1 IPv4 P P P P VPN A Site2 CE A2 PE 3 PE 2 IPv6 OSPFv3 Routing CE B2 MP CE A3 E-BGP IPv6 IPv6 VPN B Site2 VPN A Site 3 VPN C Site 1 IPv4 CE C1 C1 VPN B Site3 CE B3 IPv6 CE C2 C2 IPv6 VPN C Site

7 VPN-IPv6 Address Family 8 Bytes Route Distinguisher (RD) Type Administrator Assigned number Subscriber IPv6 prefix (2 bytes) (variable (variable (16 bytes) length) length) VPN-IPv6 address family New BGP-4 address family identifier similar to VPN-IPv4 NLRI Route Distinguisher (RD) + Subscriber IPv6 prefix Route distinguisher disambiguates IPv6 addresses Supports the private IP address space (site-local addresses) Allows SP to administer its own numbering space VPN-IPV6 addresses are distributed through MP-iBGP over IPv4 between PEs Uses Multiprotocol Extensions for BGP4 (RFC 2283) AFI=2 for IPv6 and SAFI= 128 for MPLS labeled VPN-IPv6 PE router announces itself as BGP Next Hop using an IPv4 mapped VPN IPv6 address with RD= 0 (::ffff: IPv4 address) VPN-IPV6 addresses are used only in the control plane 13 VPN-IPv6 Address Family 8 Bytes Route Distinguisher (RD) Type Administrator Assigned number Subscriber IPv6 prefix (2 bytes) (variable length) (variable length) (16 bytes) Assigned Number Field: number assigned by the identified authority for a particular purpose Administrator Field: identifies an assigned number authority 2 Byte Type Field: determines the lengths of the other two fields Route Distinguisher unchanged for IPv6 VPNs Two values are defined for Type Field: 0 and 1 Type 0: Adm Field = 2 bytes, AN Field = 4 bytes Adm field must contain an Autonomous System Number (ASN) from IANA AN field is a number assigned by SP Type 1: Adm Field = 4 bytes, AN field = 2 bytes Adm field must contain an IPv4 address assigned by IANA AN field is a number assigned by SP 14 7

8 VPN Route Distribution PEs distribute VPN routes through MP-iBGP Route distribution is controlled by the same BGP Extended Community attributes used in RFC2547bis v4 VPNs Route Target: Identifies a set of sites to which a PE router distributes routes VPN of Origin: Identifies a set of sites and establishes the associated route as coming from one of the sites in that set Site of Origin: Identifies the specific site from which a PE router learns a route 15 Route Targets Each VPN-IPv6 route advertised through MP-IBGP is associated with a route target attribute Export policies define what targets are associated with routes Upon receipt of a VPN-IPv6 route, a PE router will decide whether to add that route to a Import policies define what routes will be added to a Route isolation between s is accomplished through careful policy administration Administrator determines the appropriate export and import target relationships 16 8

9 Exchange of Routing Information Site 2 CPE-1 PE-1 MP-iBGP session PE-2 CPE-2 Site 1 CPE-3 CPE-4 Site 1 Site 2 VPN-IPv6 route R RIPng V6 route R IPv6 address is added to the appropriate PE router converts IPv6 address to VPN-IPv6 address VPN-IPv6 address is installed into the MP-BGP routing table 17 Exchange of Routing Information Site 2 CPE-1 PE-1 MP-iBGP session PE-2 CPE-2 Site 1 CPE-3 CPE-4 Site 1 Site 2 VPN-IPv6 Route R VPN RED export label Z Next-hop PE-2 VPN-IPv6 address is advertised to other PEs Inner label Route Target Site of origin (to prevent loops) Next-hop (IPv4 mapped VPN IPv6 address) RIPng V6 route R 18 9

10 Exchange of Routing Information Site 2 VPN RED import CPE-1 PE-1 MP-iBGP session PE-2 CPE-2 Site 1 CPE-3 CPE-4 Site 1 Site 2 VPN RED import MP-iBGP VPN-IPv6 Route R VPN RED export label Z Next-hop PE-2 RIPng V6 route R Each PE is configured with import targets Import target is used to selectively incorporate VPN-IPv6 routes into s If import target matches target attribute in MP-IBGP message, route is incorporated into 19 Exchange of Routing Information VPN RED import Site 2 CPE-1 PE-1 MP-iBGP session PE-2 CPE-2 Site 1 CPE-3 CPE-4 Site 1 Site 2 VPN-IPv6 Route R BGP label (inner) label (Z)( IGP (outer) label (y) Each VPN-IPv6 route in a is associated with: Label to reach the advertised NLRI Becomes the inner label Label to reach the PE MP-iBGP Becomes the outer label VPN-IPv6 Route R VPN RED export label Z Next-hop PE-2 RIPng V6 Route R 20 10

11 Exchange of Routing Information Site 2 CPE-1 PE-1 MP-iBGP session PE-2 CPE-2 Site 1 CPE-3 CPE-4 Site 1 Site 2 RIPng/OSPFv3/MP /OSPFv3/MP-EBGP V6 Route Next-hop PE1 Each IPv6 route received in a could be advertised to the sites associated with the Via RIPng, OSPFv3 or MP-EBGP 21 Data Flow Site 2 CPE-1 PE-1 PE-2 CPE-2 Site 1 Site 1 CPE-3 CPE-4 Site 2 The LSP must be in place before forwarding data across the MPLS backbone LSPs are signaled through LDP or RSVP 22 11

12 Data Flow Site 2 Site 1 CPE-1 CPE-3 PE-1 1) Lookup route in Red FT 2) Push BGP label (Z) 3) Push IGP label (Y) PE-1 PE-2 CPE-2 Site 1 CPE-4 Site 2 V6 Route R IPv6 Route R The CE performs a traditional IPv6 lookup and sends packets to the PE The PE consults the appropriate for the inbound interface Two labels are derived from the route lookup and pushed onto the packet 23 Data Flow Site 2 Site 1 CPE-1 CPE-3 PE-1 1) Lookup route in Red FT 2) Push BGP label (Z) 3) Push IGP label (Y) PE-1 IGP label (Y) BGP label (Z) IPv6 Route R PE-2 CPE-2 Site 1 CPE-4 Site 2 V6 Route R Packets are moved through the LSP using the two-level label stack Outer IGP label Identifies the LSP to egress PE router Derived from core s IGP and distributed by RSVP or LDP Inner BGP label Identifies outgoing interface from egress PE to CE Derived from MP-IBGP update from egress PE 24 12

13 Data Flow Site 2 Site 1 CPE-1 CPE-3 PE-1 Penultimate Pop top label PE-2 CPE-2 Site 1 CPE-4 Site 2 V6 Route R BGP label (z) IPv6 Route R The outer label is removed through penultimate hop popping (before reaching the egress PE) 25 Data Flow Site 2 Site 1 CPE-1 CPE-3 PE-1 PE-2 CPE-2 Site 1 CPE-4 Site 2 V6 Route R IPv6 Route R The inner label is removed at the egress PE The native IPv6 packet is sent to the outbound interface associated with the label 26 13

14 Signaling of the mapping(vpn Label L1-a FEC for Site 2) What happens before any packet is forwarded(2)? CE CE Site 1 5 RIP, BGP, OSPF(Static) /24 4 VPN label BGP-MP VPN routes PE1 configured to put routes with RT 1000:Red in of Site 1& links the route to VPN Label L1 & L1 to outer label to PE2 BGP UPDATE MP-IBGP Update: VPN-IPv4: 1000: /24 Next Hop: PE1 Label (VPN): L1 Ext. Community: RT: 1000:Red SOI: 1000:S2 Standard BGP Attributes PE1 PE2 3 P P 2 VPN label BGP-MP VPN routes 1 Signaling Routing PE2 configured: Associate routes coming from Site 2 with: RD 1000:1 RT 1000:Red (VPN Red ) SOI 1000: S2 RIP, BGP, OSPF(Static) /24 CE Site /24 Control Plane 27 CE1 (Site 1) Route Propagation Overview 7. PE1 receives MP-IBGP Update for [L1:yyy:xxx] PE1 checks RT(s) for configured VPN membership Based on RT(s), PE1 determines that it has an attached site (Site 1, via CE1) that needs to know about this route. Note that it is the Route Targets RT (not RD yyy) that identify the VPN. PE1 places this route [L1:yyy:xxx], next-hop (PE2), Label (L1) in per-site forwarding table () for Site 1. PE1 P1 Pn PE2 3. PE2 configured to assign Route Distinguisher RD yyy to IPv4 xxx from CE2 thus creating unique extended prefix : [yyy:xxx]. Also assign SOI 4. PE2 configured to assign Target VPN Attribute(s) (Route Target--RT) to [yyy:xxx ] in CE2. RT will determine what PE routers can use this route CE2 (Site 2) CE CE CE CE 8. PE1 advertises IPv4 prefix xxx to CE1 (e.g. via EBGP) unless CE1 uses default route. Note that CE1 does not know that PE2 and CE2 exist 6. MP-IBGP update (PE2->PE1) In principle sent to all PE IBGP peers Labeled VPN-IPv4 route [L1:yyy:xxx]: VPN-IPv4 destination [yyy: xxx]. NLRI includes MPLS Label L1. Update uses PE2 s address as Next- Hop (reachable via IGP) Update Includes Route Target (RT) and Site of Origin (SOI) as extended community attributes 5. PE2 creates MPLS label L1. Label will be sent in IBGP update as part of the Multiprotocol Extensions NLRI (Network Layer Reachability Information) This label identifies xxx in Site2 Note: PE and P Routers run an IGP (e.g. OSPF, IS-IS): Each PE has IPv4 connectivity to any other PE 1. IPv4 Network xxx in Site 2 2. PE2 learns route to xxx from CE2 (e.g. via EBGP). Note: Backbone routers P1 Pn are not aware of any CErelated addresses 28 14

15 Packet Forwarding Overview S1 CE1 (Site 1) CE CE PE1 P1 LSP (Label L2) Pn PE2 CE2 (Site 2) CE CE xxxa L2 L1 xxxa L2x L1 xxxa L2n L1 xxxa xxxa 1.IPv4 Packet to destination xxxa in Site2 (e.g. network xxx, host a) 3. PE1 Forwards to PE2 based on L2 2a. PE1 does a Lookup for xxx in per-site forwarding table for Site 1 2b. Label L1 for destination xxx learned through MP-IBGP from PE2. Push L1. 2c. BGP Next hop (PE2) for route xxx (also learned through MP-IBGP from PE2) 2d. PE1 looks up IGP route to IBGP next hop (PE2). Obtains Backbone MPLS label L2 to reach PE2. Learned from IGP next-hop P1. Push L2. 4.Pop L2n, Pop L1. Forward to CE2 based on L1 -- or possibly IPv4 packet info (xxx) 29 Multi-Provider v6 VPN Same methods specified in RFC2547bis apply 1) Carrier customer is a global v6 Internet Service Provider 2) Carrier customer is another L3 v6 VPN service provider Multi-AS SP network Also known as hierarchical carrier of carriers BGP/MPLS VPNs 30 15

16 Multicast v6 VPN Junipers implementation will be based on nextgen MVPN work defined in : draft-ietf-l3vpn-2547bis-mcast draft-ietf-l3vpn-2547bis-mcast-bgp 31 Agenda Introduction/Overview IPv6 Layer 3 VPN Connecting IPv6 sites over IPv4 enabled MPLS Conclusion 32 16

17 Connecting IPv6 Islands with IPv4 MPLS IETF Draft as defined in draft-ooms-v6ops-bgp-tunnel-0x Connecting IPv6 Islands across IPv4 Clouds with BGP Also known as 6PE PEs run Dual Stack MP-BGP over IPv4 PE and CE exchanges IPv6 routes MPLS LDP/RSVP LSPs are set up using IPv4 Benefits Leverages existing MPLS infrastructure Requires IPv6 support only on PE router IPv6 IPv6 IPv4 IPv6 PE1 MPLS PE2 IPv6 33 Connecting IPv6 Islands with IPv4 MPLS PEs have MP-BGP sessions of IPv4 between them IPv6 routes are exchanged with AFI IPv6 (value 2) SAFI label (value 4) Each PE sets the nexthop of routes advertised to its own IPv4 address. PEs advertise IPv6 routes with a label value of 2 (explicit null) Packets are moved through the LSP using the two-level label stack Outer label Identifies the LSP to egress PE router Inner label is 2 Could be different in case of non Juniper PE In case of single hop LSPs, only one label (2) is pushed 34 17

18 Agenda Introduction/Overview IPv6 Layer 3 VPNs Connecting IPv6 sites over IPv4 enabled MPLS Conclusion 35 Conclusion IPv6 migration does not need MPLS but, where MPLS is deployed, it enables attractive approaches for IPv6 integration IPv6 integration approach over IPv4 MPLS, offers IPv6 deployment at marginal cost/risk: no upgrade/reconfiguration in IPv4/MPLS core IPv6 simultaneously with IPv4, IPv4 VPNs, L2 services, 36 18

19 Thank you! 37 Multicast for 2547 VPNs: A Closer Look 38 19

20 L3VPN Multicast History RFC 2547 and RFC2547bis originally did not support multicast draft-rosen-vpn-mcast Draft versions described 3 ways to enable multicast in L3VPNs Fairly vague- left many details up to implementations 39 Pertinent Specs Historical Interest (mostly) draft-rosen-vpn-mcast-06 draft-rosen-vpn-mcast-07 draft-raggarwa-l3vpn-2547-mvpn-00 draft-raggarwa-l3vpn-mvpn-vpls-mcast-00 draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt draft-ietf-l3vpn-2547bis-mcast-03 draft-ietf-l3vpn-2547bis-mcast-bgp

21 draft-rosen-vpn-mcast-06 Solution 1: Multicast Domains P2MP tunneled solution Implemented in Junos and IOS Solution 2: Multicast Never implemented Solution 3: NBMA/Ingress Replication Implemented in JUNOSe 41 draft-rosen-vpn-mcast-07 Removed Solutions 2 and 3 Filled in the details for Solution 1 Added certain features from IOS implementation For example, described SSM in the P- instance (optional), SSM SAFI (required) Not interoperable with implementations based on version

22 draft-raggarwa-l3vpn-2547-mvpn-00 Based on Rosen draft 06, Solution 1 Goal- base document of existing implementations for interoperability 43 draft-raggarwa-l3vpn-mvpn-vpls-mcast-00 Completely new solution that addresses the scalability issues with Rosen draft and draftraggarwa-l3vpn-2547-mvpn-00 Also addresses multicast in VPLS 44 22

23 draft-ietf-l3vpn-2547bis-mcast-00.txt Merged Rosen and draft-raggarwa-l3vpn-mvpnvpls-mcast-00 Originally called draft-to-become-l3vpn-2547bismcast-00.txt 45 draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt Set of requirements for MVPNs Authored primarily by FT SP input is encouraged 46 23

24 Current Implementations Rosen-06 and draft-raggarwa-l3vpn-2547-mvpn- 00 Ingress Replication Multicast Domains Default MDT only Default MDT with Data MDT Rosen-07 SSM in SP core 47 Rosen-06 Solution 3: NBMA/Ingress Replication Multicast control and data sent from PE-PE through P2P tunnels Typically, the same LSPs used by VPN unicast Traffic replicated by source s PE and sent only to PEs that send joins Implemented in JUNOSe today Called remote pim neighbors Very simple 48 24

25 MVPN Traffic Flow- Ingress Replication Traffic replicated at Source PE and sent only to PEs with receivers Can use existing PE-PE P2P MPLS LSPs PE VPN Enabled Service Provider P Router (RP) PE2 PE3 CE2 VPNA Interested Receiver Source PE4 Interested Receiver CE1 VPNA CE4 VPNA CE3 VPNA 49 Ingress Replication Benefits No flooding in the core No state in the core Much simpler in the core No PIM, no MSDP, no multicast in core Multicast over MPLS Traffic Engineering, Fast-Reroute, etc 50 25

26 Ingress Replication Disadvantages Any P2P solution will be inefficient as fanout increases Potential that packets will be sent multiple times over the same physical interface Replication done logically, not physically Worse-case traffic per S,G? N-1streams where N = number of PE routers in the VPN Unavoidable consequence of using multiple logical interfaces over a single physical interface Just like GRE, VLAN, ATM, FR 51 Rosen-06 Solution 1: Multicast Domains For simplicity, just make routers in the Provider network think they are on a LAN by creating a P2MP Tunnel Tunnel is called Default MDT Default MDT is just a P2MP GRE tunnel Tunnel destination is a multicast group PIM in the core is used to route this GRE tunnel 52 26

27 Multicast Domains Solution PE routers all think they are on a LAN PIM runs in the Core. There is one multicast group in the core per VPN. Each PE which is a member of the VPN joins that VPN multicast group. This results in one P2MP tunnel from each PE to all other PEs in the same VPN Tunnel encap is GRE PE Provider Network P PE All s in a VPN have the Illusion that they are connected by a fake LAN PE 53 Multicast Domains Solution Fake LAN (Really a VPN multicast group in the core) PIM neighbors R R Listeners Source Regular PIM running in the treats the core as a giant LAN and follows the normal PIM procedures for LANs. R Listeners 54 27

28 MVPN Traffic Flow- Multicast Domains P2MP tunnels deliver traffic to all PEs in the VPN PEs with no receivers discard traffic PE VPN Enabled Service Provider P Router Default MDT Join PE2 Join PE3 CE2 VPNA Join Data Interested Receiver Source Data Join PE4 Data Join Interested Receiver CE1 VPNA CE4 VPNA CE3 VPNA 55 Multicast Domains- Details PIM must run in the core Provider PIM instance for creating MDT interfaces PE P2MP GRE endpoint per - MDT interfaces By default, all control and data sent over a single Default MDT Customer instance of PIM between PE-CE Traffic sent to all PEs with a member of the same VPN 56 28

29 Multicast Domains in Junos Interoperable with Cisco All PEs require a tunnel (or LS/AS) Pic to handle the GRE encap P-RP supported in PE or P routers C-RP in a PE supported Supported in JUNOSe Multicast Domains, Default MDT only Perpetual flooding of mcast data to all PEs with a VPN member Most efficient when there are few prunes IE, when most CEs have at least one receiver Like the old dense mode assumption Simple (relatively) Efficient when there are many low data rate groups Scalability of Provider PIM instance P routers support N groups, where N is # of VPNs With SPT (SSM or ASM), this means N x M state in the core, where M is the number of PEs with a VPN member With shared trees (ASM or Bidir), there is only N state in the core 58 29

30 Default MDT Disadvantages Broadcasting data across your core to all PEs in a VPN may be undesirable Sub-optimal for high data rate groups with sparsely distributed receivers Scaling issues in data plane because of unwanted flooding 59 Alternative: Adding Data MDTs Instead of one MDT per, use multiple MDTs One MDT for control (default), dynamically create new MDT s for data groups in the VPN Each high data rate VPN group creates a new data MDT Low data rate groups remain on default MDT Provides optimal data forwarding for high data rate groups Uses UDP signalling between PEs to establish and switch to Data MDT Data MDTs initially described in early Rosen drafts in vague terms, details left up to the implementation In Rosen-07, UDP signalling protocol specified Supported in IOS and Junos

31 S1,G1 MVPN Traffic Flow- Multicast Domains with Data MDT If traffic exceeds threshold, create a new P2MP tunnel that goes only to PEs with interested receivers S1,G2 S2,G3 S3,G4 Join Default MDT P Router Data MDT 1 PE VPN Enabled Service Provider Data MDT 3 Join Data MDT 2 PE4 PE2 Join PE3 CE2 VPNA Join Join Some Interested Receivers Some Interested Receivers Sources CE1 VPNA Some Interested Receivers CE4 VPNA CE3 VPNA 61 Data MDT Disadvantages Each group in the C-VPN could create state in the provider network Provider routers support M x N x O state, where N is the number of VPNs, M is the number of PEs with a VPN member and O is number of groups per VPN (when using SPT) Each group in the C-VPN could create a new MDT interface on the PEs MT is a logical interface - only a finite number of interfaces can be supported on one router Complexity of when to create a new data MDT 62 31

32 Data MDT Disadvantages, cont. Receiving PEs that are unable to join the data MDT will be blackholed- no feedback mechanism informing the Source-PE that all receiving PEs successfully switched If receiving PE might not have resources available to create a data MDT interface If data MDT signalling messages are lost- using an unreliable protocol If receiving PE doesn t build and switchover to data MDT fast enough, it will lose packets If for any reason, the receiving PE is unable to join the data MDT No packets and no warning!! 63 Data MDT Scalability Concerns Breaks the scalability model for 2547 Would you want to maintain customer unicast VPN routes in your P routers? Even worse with multicast because these are groups, not routes Groups are host-created Scaling issues in control plane because of potential for state explosion 64 32

33 Rosen-07: SSM in the SP Core Rosen-07 introduced an optional way to use SSM-only in the P-instance using MBGP SSM is optional, but the MBGP SAFI that enables it is required Junos supports ASM (PIM-SM) in P-instance of PIM Cisco supports ASM and SSM in P-instance Q. Isn t SSM better? A. Normally yes, but not in this case 65 SSM vs. ASM in Core End result in SSM: Shortest Path Trees End result in ASM: Shortest Path Trees What s different? How you got there! SSM source discovery Application-based BGP ASM source discovery Network-based RP Issue is not SSM vs. ASM BGP vs. RP providing source discovery 66 33

34 BGP vs. RP BGP New SAFI to discover PEs in the VPN Send (S,G) joins to those PEs RP Uses same RP/MSDP infrastructure deployed on the Internet for 5+ years All PEs join the same VPN-group Which is simpler? Neither! They are just different! 67 SSM Note Juniper is one of the strongest proponents of SSM Juniper coauthor of draft SSM is vastly simpler because of application layer source discovery But there is no application layer in routers - so you need BGP Myth: SSM simplifies P-instance Reality: No, complexity is just moved from RP to BGP SSM is ideal for nearly all multicast applications Exception: many-to-many, device discovery- Default MDTs!! Default MDT is ideal for ASM model Data MDT is ideal for SSM model ASM allows you to use shared trees to reduce state 68 34

35 Scaling Multicast Domains 2 choices for deployment: One has data plane scalability issues (floods everywhere) One has control plane scalability issues(creates potentially unbounded state) Pick your poison! Is there a better way??? 69 MVPN: Is there a better way? Well, it depends!! 70 35

36 MVPN: What s the Problem? 3 Dimensions to consider: Data Rate- how big is the multicast stream? State- how much routing state do the routers have to keep? Fanout- how many PE routers have a receiver connected? You can only have 2!! but 2 out of 3 ain t bad 71 MVPN: What s the Problem with P2MP? Any P2MP solution will have to compromise between Data Rate and State 2 extremes: Either flood all streams to all PEs or create a separate tree for each customer multicast stream Or some mix thereof Problem occurs with any P2MP mechanism, including GRE and MPLS 72 36

37 MVPN: What s the Problem with P2P? Replication Not efficient if there is a dense distribution of PEs with interested receivers 73 Simple Comparison of 3 Dimensions of MVPNs Data Rate State Fanout Default MDT Bad Good Great Data MDT Good Bad Great Ingress Replication Great Great Bad A perfect solution does not exist But a mix of options can be used to address each VPN based on need Toolbox approach 74 37

38 Other Problems with Existing Solutions PIM neighbors (# of VPNs per PE) x (# of PEs with a site in the VPN) By comparison, unicast requires only 1 BGP session between each PE (or less with route reflectors) PIM State P routers must maintain state proportional to the # of VPNs Worsens significantly when you add Data MDT PIM Join/Prune processing PIM is a soft state protocol Data MDT no feedback for MDT creation mentioned earlier 75 Example Take an example with 1,000 CEs per PE (1,000 VPNs per PE), with 100 sites per VPN on average, and total of 10,000 VPNs per Service Provider PE control plane state Number of PIM neighbors per PE = 1,000 * 100 = 100,000 PE control plane processing 30 second (default) PIM Hello interval 100,000/30 = 3,300 PIM Hello packets per second State in the SP core Default MDT with SPTs: 100 * 10,000 = 1,000,000 trees Far worse when you add Data MDT 76 38

39 Where does this leave us? The scaling properties of the multicast component of BGP/MPLS VPNs are noticeably inferior to the scaling properties of the unicast component of BGP/MPLS VPNs Applies to both Rosen drafts and draft-raggarwal3vpn-2547-mvpn-00 More work required to improve scalability of MVPN To bring it closer to the scalability of the unicast component of BGP/MPLS VPNs But SPs want to offer Multicast VPN service today 77 A Next Gen MVPN Solution draft-raggarwa-l3vpn-mvpn-vpls-mcast-00 described a new set of mechanisms to address each of the issues with Rosen and base draft-raggarwa-l3vpn mvpn-00 2 solutions: P2MP solution- P2MP GRE/LSPs P2P solution- Ingress Replication 78 39

40 MVPNng- P2MP GRE/LSPs PIM neighbors- use BGP to eliminate hello processing PIM state- aggregate trees PIM Join/Prune processing- add refresh reduction to PIM (similar to RSVP) Data MDT feedback- RSVP provides feedback Can transmit on both default and data trees Stop forwarding on default tree only after there are no interested PEs Make before break similar to SPT switchover 79 Aggregate Trees Allow one SP multicast Tree to be shared across multiple VPNs Can be setup using PIM-SM Requires an inner label to demultiplex a particular VPN Upstream label allocation by the root of the tree A flexible tool to reduce state in the SP network A PE may receive un-necessary traffic Put MVPNs on par with unicast 2547 State in the SP network doesn t grow proportional to the number of VPNs Use BGP signaling 80 40

41 Aggregate Data Trees A flexible tool to create separate trees for a set of customer groups to avoid flooding To reduce/eliminate unwanted flooding, create aggregate data trees Analogous to Data MDT, but can be shared by multiple VPNs Setup using PIM-SSM with BGP signaling Requires an inner label to demultiplex a particular VPN Upstream label allocation by the root of the tree 81 P2MP MPLS Can be used to setup Aggregate Tree and Aggregate Data Trees Can provide Traffic Engineering Fast Reroute RSVP provides feedback to prevent blackholes when moving to Aggregate Data Trees 82 41

42 MVPNng- Ingress Replication PIM neighbors- use BGP to eliminate hello processing No flooding, state, PIM, MSDP in the core 83 Multicast in VPLS Currently uses ingress replication, but floods to ALL PEs with VPLS members Absolute worst case guaranteed at all times draft-raggarwa-l3vpn-mvpn-vpls-mcast-00 also described new mechanisms to better support multicast in a VPLS Add IGMP/PIM snooping to current ingress replication solution to eliminate unwanted flooding Adds the Aggregate [Data] Tree mechanisms to VPLS to support a P2MP solution Use IGMP/PIM snooping for Aggregate Data Trees Maximize machinery across MVPN and VPLS multicast 84 42

43 A Happy Ending: Consensus Rosen-draft and draft-raggarwa-l3vpn-mvpn-vpls-mcast-00 were merged and presented at IETF in March 2005 Latest version: draft-ietf-l3vpn-2547bis-mcast-03 New draft retains all the components of the 2 drafts as options P2P/P2MP MPLS (via RSVP-TE) and P2MP GRE (via PIM- SM, PIM-SSM or BiDir) supported for PE-PE tunnels BGP for autodiscovery, PIM refresh redux, aggregate trees VPLS section removed Broad support from L3VPN WG, Juniper and Cisco 85 Backwards Compatibility New mechanisms described in draft-ietf-l3vpn- 2547bis-mcast-00 exist as ships in the night with existing mechanisms New or existing features are applied on a per-vpn basis 86 43

44 Scaling MVPNs Low Data High Data Rate Groups Rate Groups Number of VPNs 100 Groups per VPN Fanout Simplicity Default MDT Data MDT Ingress Replication Aggregate [Data] Trees 87 What s Available Today JUNOSe Ingress Replication Rosen-06 Junos Rosen-06 Data MDT (per Rosen-07) C-MSDP in VR/ P2MP LSPs (non-mvpn) 88 44

45 MVPN Roadmap draft-ietf-l3vpn-2547bis-mcast-00 /VPLS will be a phased rollout BGP for neighbor discovery P2MP LSPs for VPLS P2MP LSPs for MVPN Ingress Replication Aggregate [Data] Trees PIM refresh reduction VPLS- PIM/IGMP snooping What do you want? 89 Thank you!

46 MVPN Config in Junos: P-instance Frighteningly simple to configure Troubleshooting is the hard part interfaces { lo0 { unit 0 { family inet { address /32 { } } unit 1 { description "Required for each ; must be routable in the VPN"; family inet { address /32; } } } } protocols { /* P-instance of PIM */ pim { rp {static { /* P-RP */ address ; } } interface all { mode sparse; version 2; } } } 91 MVPN Config in Junos: C-instance routing-instances { foo { instance-type vrf; interface so-0/0/0.0; interface lo0.1; protocols { pim { vpn-group-address ; } } } } rp { static { /* C-RP */ address ; } } interface lo0.1 { mode sparse; } interface so-0/0/0.0 { mode sparse; } 92 46

47 Troubleshooting MVPNs in Junos First verify that P-instance is working properly show pim neighbors instance foo and make sure that mt- interfaces are up and all PE neighbors are seen If not, P-instance is broken Troubleshoot the VPN-group address and make sure all PEs are joined and forwarding correctly show pim join <vpn-group> extensive show multicast route group <vpn-group> extensive 93 Troubleshooting MVPNs in Junos If P-instance is OK (mt- interfaces are up to all PEs and neighbors seen across mt- interfaces), troubleshoot C-instance show pim neighbors instance foo show pim join extensive instance foo show multicast route extensive instance foo Everything else works just like plain old multicast 94 47