1 / 7

Requirement for Multicast MPLS/BGP VPN Partitioning draft-mnapierala-mvpn-part-reqt-02

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.

tress
Télécharger la présentation

Requirement for Multicast MPLS/BGP VPN Partitioning draft-mnapierala-mvpn-part-reqt-02

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. Requirement for Multicast MPLS/BGP VPN Partitioningdraft-mnapierala-mvpn-part-reqt-02 IETF 72 Maria Napierala

  2. About the draft • Contains MVPN requirements not present in RFC4834 • Reflects experience of a service provider with large offering of MVPN service to customers

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

More Related