Beruflich Dokumente
Kultur Dokumente
draft-ietf-l3vpn-2547bis-mcast-03.txt
Overview
Aiming to encourage more involvement in multicast L3VPN work by providing user-friendly overview of problem space Focus more on problems that the current proposed solutions Hard questions will be deflected to draft authors
Likewise questions such as why did you choose to design it that way?
Agenda
L3VPN MulticastMotivation
Customers with IP multicast traffic would like to use MPLS VPN services RFC 2547/4364 only addresses unicast As usual, multicast makes the problem harder
Difficult to achieve same scalability as unicast
Based on draft-rosen-vpn-mcast-08.txt Many similarities to unicast, and some differences CE-routers maintain PIM adjacency with PE-router only
Similar concept to 2547/4364 VPNs
Multicast domain is a set of multicast-enabled VRFs (mVRFs) that can send multicast traffic to each other
e.g., VRFs associated with a single customer
Maps all (S, G) that can exist in a particular VPN to a single (S, G) group in the P-network
This is the Multicast Distribution Tree (MDT) Amount of P-state is a function of # of VPNs rather than # of (S, G)s of all customers This is not as good as unicast, but better than the alternative
Customer B CE
Customer B CE
Customer B CE
PE routers build a default MDT in the global table for each mVRF using standard PIM procedures All PEs participating in the same mVPN join the same Default MDT Every mVRF must have a Default MDT MDT group addresses are defined by the provider
Unrelated to the groups used by the customer
Customer B CE
Customer B CE
Customer B CE
Default MDT is used as a permanent channel for PIM control messages and low bandwidth streams Access to the Default MDT is via a Multicast Tunnel Interface A PE is always a root (source) of the MDT A PE is also a leaf (receiver) to the MDT rooted on remote PEs
Limitations of draft-rosen
all all
Unidirectional, selected PEs can transmit to all PEs Unidirectional, selected PEs can transmit to selected PEs
Inclusive: contains all the PEs for a given MVPN Selective: contains only a subset of PEs of a given MVPN Aggregate
Carries traffic for more than one MVPN May be either inclusive or selective
PIM (any flavor) MPLS (mLDP or p2mp RSVP-TE) Unicast tunnels with ingress PE replication
Can map multiple PMSIs onto one tunnel (aggregation) Encaps a function of tunnel, not service Single provider can mix and match tunnel types
Default MDT
MI-PMSI, instantiated by PIM Shared Tree or set of PIM Source Trees
Data MDT
S-PMSI, instantiated by PIM Source Tree
Autodiscovery
The process of discovering all the PEs with members in a given MVPN Similar to RFC4364, but:
New address family MCAST-VPN Contains address of the originating PE Contains tunnel attribute to specify what sort of tunnel (e.g. PIM-SSM, mLDP, etc.) can be supported by this PE, and whether aggregation is supported
May contain a tunnel ID
Can also be used to discover set of PEs interested in a given group (to enable S-PMSI creation)
Aggregation
Conflicting goals
Scale: Minimize P-router state Use as few trees as possible Optimality: Send traffic at most once on each link, and only to PEs that need it Use a tree for each customer multicast group
In draft-rosen, C-PIM instances exchange PIM messages over the MDT as if it were a LAN
Per-customer PIM peering among the PEs By contrast, one BGP instance carries all customer unicast routes among PEs PIM Hellos can be eliminated, but Join/Prunes remain
Inter-AS
New draft allows another approach: may splice tunnels from different ASes
Allows each AS to build its tunnels independently of other ASes Scaling now independent of number of PEs in other ASes
For a given MVPN, each AS independently builds an intra-AS tunnel In addition, an overlay tunnel that spans multiple ASes is built Each PE announces its MVPN membership info to the ASBRs with iBGP An ASBR announces the AS MVPN membership to other ASBRs (in other ASes) using eBGP This enables an AS-level spanning tree to be built among the set of ASes with members in this MVPN
Inter-AS tunnels spliced to intra-AS tunnels
Inter-AS Tunnels
Customer A Customer A
ASBR1
ASBR2
Customer A ASBR3
Other issues
RPF establishment
PEs need to know who their RPF PE is for a given route
Duplicate detection
Multihomed sites and switching from shared to source tree can lead to a PE getting duplicate packets draft proposes means to address this
C-RP Engineering
RP location in customer sites may cause hairpin PEs may act as outsourced C-RPs PEs may speak MSDP to C-RPs
Conclusions