base specification for multicast in bgp/mpls vpns draft-raggarwa-l3vpn-2547-mvpn-00.txt
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
Base Specification for Multicast in BGP/MPLS VPNs
draft-raggarwa-l3vpn-2547-mvpn-00.txt
Rahul AggarwalJuniper Networks
Slide 2
Agenda
• Motivation• Solution
– Multicast routing protocol in the SP core
– Inter-AS considerations
• Differences with rosen-7• Issues
• Motivation• Solution
– Multicast routing protocol in the SP core
– Inter-AS considerations
• Differences with rosen-7• Issues
Slide 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
• 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 4
Tradeoffs: replication vs state
• 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
Efficiency with respect Efficiency with respectto traffic replication to state in the SP
Slide 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
• Balance between the state in the SP core and efficient multicast replication
• A PIM-SM shared tree in the core per MVPN
Slide 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
• 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 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
• 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 8
Discussion: PIM C-Join/Prune/Assert Neighbor Address
• 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
First approach: Second approach:
Need WG feedback to decide on one approach
Slide 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
• 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 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
• 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 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
• 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 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
• 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 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
• 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 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
• 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 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
• 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 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
• 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 17
BGP Free Core for MVPN
• 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
Multicast operations: Unicast operations:
Bottom line: BGP free core brings less benefits for multicast, as compared to unicast routing for 2547 VPNs
Slide 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
• 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 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…
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 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
• 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 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
• 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 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
• 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