80 likes | 281 Views
Supporting IP Multicast over VPLS draft-serbest-l2vpn-vpls-mcast-02.txt. Suresh Boddapati Venu Hemige Sunil Khandekar Vach Kompella Marc Lasserre Rob Nath Ray Qiu Yetik Serbest. Problem Definition. Objective Do not send traffic to sites without receivers
E N D
Supporting IP Multicast over VPLSdraft-serbest-l2vpn-vpls-mcast-02.txt Suresh Boddapati Venu Hemige Sunil Khandekar Vach Kompella Marc Lasserre Rob Nath Ray Qiu Yetik Serbest
Problem Definition • Objective • Do not send traffic to sites without receivers • Keep core P routers stateless (Multicast) • Reduce BW waste • Constraints • In VPLS, ingress replication is required • Note: There is no layer-3 adjacency (e.g., PIM) between a CE and a PE
Comments Addressed in v02 • Comment: Snooping at PWs overwhelms PEs • IGMP snooping • Proposal: PEs to do IGMP proxy • PIM Snooping • Proxy behavior is used with PIM snooping on the PEs to reduce the amount of PIM traffic forwarded upstream • The ideal solution would be for the C-Routers implementing PIM-refresh reduction. But at least in the near-term, providers cannot rely on C-routers to have this feature. • Proposal: Rate limit the PIM JP and Hello refresh messages at down stream PEs • Some details on the next slide • Is employed only when PIM-refresh reduction is inactive. • Is fairly light-weight and simple. • The idea here is to send out the Hello/JP messages less frequently (definable by certain parameters and changing the Holddown timer) to ease the burden of PIM snooping on upstream PEs • PIM-refresh reduction should be friendly to PIM snooping, otherwise, PIM Snooping will not work when refresh reduction is active.
Comments Addressed in v02 (Cont.) • Proposal to overcome the burden of PIM Snooping in the core • The PEs are configured to not exceed a threshold (tx_threshold) which represents the aggregate amount of PIM refresh traffic that can be generated in the core • For every PIM JP PDU received by a PE from the access side, the PE will modify the holdtime to a large value (possibly even infinity) before sending out into the core • The holdtime, call it “core_holdtime”, can be configured OR can be adaptively computed based on the number of entries the PE has. • So the refresh rate is roughly 1/3rd the core_holdtime. • The PE will forward refreshes that it receives from the access side into the core only if the refresh timer has expired. Otherwise, it is simply dropped. • To take care of the possibility of JP PDUs getting lost, a robustness variable R (like in IGMP) is configured for the VPLS instance (possibly even per PW). This simply means that the PE will propagate the initial Joins R times into the core instead of only once.
Comments Addressed in v02 (Cont.) • Comment: Should include IPv6 considerations • Done. • Comment: Should elaborate the cases where both IGMP and PIM snooping are necessary • Defined/Included macros • Included data forwarding rules accordingly • Comment: What if uni-directional tree is used for VPLS instead of full-mesh PWs? BIDIR-PIM snooping will have problems. • Out of scope. Current VPLS uses full-mesh PWs.
Additions in v02 • Defined an LDP TLV to flush snooping state to solve duplicate traffic situations • To trigger Assert mechanism
Next Steps • Please comment • WG document?