1 / 22

Base Specification for Multicast in BGP/MPLS VPNs draft-raggarwa-l3vpn-2547-mvpn-00.txt

Base Specification for Multicast in BGP/MPLS VPNs draft-raggarwa-l3vpn-2547-mvpn-00.txt. Rahul Aggarwal Juniper Networks. Agenda. Motivation Solution Multicast routing protocol in the SP core Inter-AS considerations Differences with rosen-7 Issues. Motivation.

darius-pitts
Download Presentation

Base Specification for Multicast in BGP/MPLS VPNs draft-raggarwa-l3vpn-2547-mvpn-00.txt

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. Base Specification for Multicast in BGP/MPLS VPNsdraft-raggarwa-l3vpn-2547-mvpn-00.txt Rahul Aggarwal Juniper Networks

  2. Agenda • Motivation • Solution • Multicast routing protocol in the SP core • Inter-AS considerations • Differences with rosen-7 • Issues Slide 2

  3. Motivation • Document minimal set of procedures to build inter-operable implementations of MVPNs • Focus on mandatory procedures • Document procedures implemented across multiple vendors • That are known to be inter-operable across multiple vendors • Procedures defined are not necessarily new • Based on prior specifications – rosen-6 • Clearly document the procedures • To facilitate multi-vendor inter-operable implementations Slide 3

  4. A CE multicast data packet must reach only the PEs that have receivers on the path to the multicast group Must not be unnecessarily replicated Requires multicast tree in the service provider for every customer multicast group Potentially unbounded state in the SP core An ingress PE replicates the multicast packet and unicast tunnels it to each egress PE Minimal state in the SP core Tradeoffs: replication vs state Efficiency with respect Efficiency with respect to traffic replication to state in the SP Slide 4

  5. Solution: middle ground • Balance between the state in the SP core and efficient multicast replication • A PIM-SM shared tree in the core per MVPN Slide 5

  6. Multicast Routing in the SP Core • PIM-SM MUST be supported in the SP core • See more on why PIM-SM is MUST later… • Use of other multicast routing protocols in the SP core (eg PIM-SSM, PIM-DM, PIM-Bidir) is optional • therefore is outside the scope of the base spec Slide 6

  7. Switching from Shared Tree to Source Specific MD Trees • PIM-SM allows ONE shared tree per MD/VPN in the SP core • Rooted at the RP • To reduce state in the SP core an implementation SHOULD provide • A knob to control the RP joining the MD tree rooted at the source PE • A knob to control the PEs joining the MD tree rooted at the source PE Slide 7

  8. BGP next-hop of the unicast VPN routes Typically the PE loopback address in the provider address space Issue: Customer PIM neighbor address may overlap with the PE loopback address An interface address in the VPN address space Issue: Needs to be injected as a unicast VPN route. Must not overlap with a customer route Discussion: PIM C-Join/Prune/Assert Neighbor Address First approach: Second approach: Need WG feedback to decide on one approach Slide 8

  9. Inter-AS Considerations • 2547 Option A is supported • 2547 Option C is supported • BGP-free core may require extensions that are outside the scope of this document • 2547 Option B is not supported • In option B the BGP next-hop is rewritten • RPF address determination procedures rely on the BGP next-hop -> support for Option B requires additional mechanism in BGP Slide 9

  10. PIM-SM inter-AS Considerations:Same Provider • Single Service Provider consisting of multiple ASs • The provider can share RPs between ASs • MSDP is NOT required • MD address co-ordination across providers is a non-issue – the same provider Slide 10

  11. PIM-SM inter-AS Considerations:Different Providers • Option A of 2547 inter-AS operations: • No MD address co-ordination required • No sharing of RPs across providers required • Options B and C of 2547 inter-AS operations: • Requires MD address co-ordination across providers • Requires either sharing RPs across providers, or MSDP • Additional co-ordination required by MVPN should be viewed in the context of the total amount of coordination/cooperation required to provide 2547 VPN services Slide 11

  12. Differences between draft-raggarwa and draft-rosen-7 • Draft-raggarwa requires PIM-SM as the multicast protocol in the SP core • Draft-rosen-7 requires PIM-SSM as the multicast protocol in the SP core Slide 12

  13. Why PIM-SM in the SP Core ? • PIM-SM requires only a single (shared) tree per MVPN in the SP core • PIM-SSM requires more than a single tree per MVPN in the SP core (more on this later…) • PIM-SM supports Inter-provider operation • PIM-Bidir procedures are not clear • PIM-SSM does simplify MD address allocation, but at the cost of requiring a provider to maintain state in the P routers that depends on the number of PEs in the other providers • PIM-SM is widely implemented and deployed Slide 13

  14. Differences between draft-raggarwa and draft-rosen-7 • Draft-raggarwa documents the minimal set of required procedures that are implemented and interoperable across multiple vendors • Draft-Rosen-7 includes additional mechanisms: • Support for Option B inter-AS operations • PIM-SSM in the SP core • BGP Free Core • Data MDTs • Need WG discussion on which of these additional mechanisms should be mandatory, and which should be optional • Needs WG discussion on the specifics of these mechanisms Slide 14

  15. Differences between draft-raggarwa and draft-rosen-7 • Inter-AS option B • Not documented in draft-raggarwa • as there are no multi-vendor interoperable implementations • Documented in draft-rosen-7 • Need further WG discussion on whether it should be mandatory or optional • Requires additional mechanism in BGP (either the Connector attribute, or the Original Next Hop attribute) • Need further WG discussion on this Slide 15

  16. Differences between draft-raggarwa and draft-rosen-7 • Discovery for PIM-SSM • Documented in draft-rosen-7 • PIM-SSM is used both for the default MDT and Data MDT • Two discovery mechanisms: • BGP based discovery when PIM-SSM is used for default MDT • (new) UDP based protocol when PIM-SSM is used for Data MDT • Why is one mechanism not sufficient ? • If PIM-SSM in the SP core is optional, then discovery mechanism(s) for PIM-SSM should be optional as well Slide 16

  17. Gain applies solely to inter-AS operation Eliminates the need for P routers in one AS to maintain the routes to the PEs in other ASs Gain applies to both intra-AS and inter-AS operations Eliminates the need to maintain any VPN routes in the P routers BGP Free Core for MVPN Multicast operations: Unicast operations: Bottom line: BGP free core brings less benefits for multicast, as compared to unicast routing for 2547 VPNs Slide 17

  18. BGP Free Core for MVPN… • Put the savings in proper perspective • Saving is small compared to: • P router maintaining VPN related state: Per VPN granularity multicast trees with PIM-SM • Even more state with PIM-SSM as in draft-rosen-7 • Maintenance of this state by PIM which uses periodic refreshes (default every 30 secs) • One could have BGP in the core to support MVPN while still keep the core free of any unicast VPN routing information • Hence procedures for BGP free core for MVPNs should be optional Slide 18

  19. Solution: Issues Several fundamental issues common to both the solution proposed in draft-raggarwa and draft-rosen-7: • PE Control plane state • Number of PIM neighbors per PE = (number of VPNs per PE * average number of sites per VPN) • PE Control plane processing • Periodic PIM Hello from all the PIM neighbors • Periodic PIM Joins from PIM neighbors • State in the SP core • Proportional to the number of VPNs when PIM-SM shared trees are used as in draft-raggarwa • Proportional to the number of VPNs * average number of sites per VPN when PIM-SSM is used for Default MDT as in rosen-7 • PIM SSM for Data MDT adds more state… Slide 19

  20. Solution: Issues… • 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 • PIM-SM for Default MDT: 10,000 trees • PIM-SSM for Default MDT: 100 * 10,000 = 1,000,000 trees Slide 20

  21. 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 draft-raggarwa and draft-rosen-7 • Mandating PIM-SSM for default MDT, as in rosen-7, only makes this worse • 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 • Progress the minimal set of required procedures • Continue to evolve the basic MVPN architecture • Let us not jump on the optional feature bandwagon too fast Slide 21

  22. Conclusion • Minimal set of mandatory procedures must be documented • Reflecting "working code" of multiple vendors is desirable • Do not preclude optional features. But let us clearly separate optional from mandatory. • Continue to improve the scalability of the MVPN solutions • Request to be a WG document Slide 22

More Related