70 likes | 189 Views
Requirement for Multicast MPLS/BGP VPN Partitioning draft-mnapierala-mvpn-part-reqt-02. IETF 72 Maria Napierala. About the draft. Contains MVPN requirements not present in RFC4834 Reflects experience of a service provider with large offering of MVPN service to customers.
E N D
Requirement for Multicast MPLS/BGP VPN Partitioningdraft-mnapierala-mvpn-part-reqt-02 IETF 72 Maria Napierala
About the draft • Contains MVPN requirements not present in RFC4834 • Reflects experience of a service provider with large offering of MVPN service to customers
Support of Multiple Upstream PEs for the same C-Flow S/RP S/RP | | PE1 PE2 | | ------------------------------ | VPN Backbone | ------------------------------ | | PE3 PE4 | | R1 R2 • Allow multiple PEs to be the entry points for the same C-flow, with each egress PE/mVRF for that C-flow receiving traffic from only one of those upstream PEs • This feature is necessary for proper support of anycast RP and anycast sources; it also supports various kinds of load balancing and/or multicast traffic engineering • PE3/R1 wants receives (S,G) or (*,G) traffic only from PE1 • PE4/R2 wants receives (S,G) or (*,G) traffic only from PE2
Preserve MVPN Customer Traffic Patterns • Don't create or maintain any customer-visible (S,G) or (S,G,RPTbit) states that would not exist in the C-network if MVPN were not being used • Example: • R1 switches to Shortest Path Tree for (S,G) traffic (but R2 does not) • MVPN switches (S,G) traffic to SPT for both R1 and R2 • Traffic flows S-PE2-BB-PE3/PE4 • R1 prunes itself from (*,G) • (S,G) tree should not be maintained in customer network RP S | | PE1 PE2 | | ------------------------------ | VPN Backbone | ------------------------------ | | PE3 PE4 | | R1 R2
Support of PIM-Bidir in MVPN • MVPN solution for C-Bidir should not rely on all mVRF's in a given MVPN to either have common routing view or to reach a common routing view to C-RPA in time to prevent packet looping • Should be able to force all PEs to select the same upstream PE for a given BIDIR-PIM C-RPA, but must not require that to be the case • Support source-only branches
What is new in -02 version • Made several editorial and organizational changes to the document • Added more description on anycast-sourcing in section 4 • Clarified requirements for preserving customer multicast traffic patterns in section 5
Current status, Next steps • Thank you for discussion and comments on the mailing list • The main point of discussion on the mailing has been whether to accept requirement beyond those included in RFC4834 – would like the WG to reach a consensus