Title: Multicast in L3VPNs
1Multicast in L3VPNs
draft-ietf-l3vpn-2547bis-mcast-03.txt
- Bruce Davie1
- bsd_at_cisco.com
1. Not a draft co-author, or a multicast expert
2Overview
- 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? - Attempts to make me look ignorant will be frowned
upon
3Agenda
- Recap of current (deployed) state (draft-rosen1)
- See also draft-raggarwa-l3vpn-2547-mvpn-00.txt,
draft-ycai-mboned-mvpn-deploy-00.txt - Enhancements/changes in L3VPN WG draft
- Supporting multiple tree types
- Aggregation
- Carrying customer multicast routing in BGP
- Inter-AS improvements
- Note Well WG draft is a superset of draft-rosen
- i.e. deployed solutions will not be obsoleted by
new draft
1draft-rosen-vpn-mcast-08.txt
4L3VPN 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
5Multicast VPNCurrent Deployments
- 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
- P-routers do not hold (S, G) state for individual
customers - Unlike unicast, there is some per-customer state
in P-routers - PE-routers exchange customer routing information
using PIM - Contrast to BGP for unicast
- Customer multicast group addresses need not be
unique - Same as 2547/4364
6Multicast VPNCurrent State (2)
- 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 - Mapping is achieved by encapsulating C-packet
into P-packet using GRE
7Default Multicast Distribution Tree
PE
PE
PE
Customer BCE
Customer BCE
Customer BCE
- 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
- Data MDTs may be created for high BW sources
8Default Multicast Distribution Tree
PE
PE
PE
Customer BCE
Customer BCE
Customer BCE
- 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
9Limitations of draft-rosen
- At least one multicast tree per customer in core
- No option to aggregate multicast customers on one
tree - Multicast traffic is GRE (not MPLS) encapsulated
- Bandwidth and encaps/decaps cost
- Operational costdifferent mcast and unicast data
planes - PIM the only fully described way to build core
trees - Cant leverage p2mp RSVP-TE, mLDP
- PE-PE exchange of C-routes using per-customer PIM
instances - Inter-AS challenges
10PMSI P-Multicast Service Interface
- New terms introduced to decouple tree from
service - A PE delivers packet to PMSI, then all the
required PEs will get than packet and known which
MVPN it belongs to - Three types of PMSI
- MI-PMSI Multipoint Inclusive, all ? all
- All PEs of an MVPN can transmit to all PEs
- UI-PMSI Unidirectional Inclusive, some ? all
- Unidirectional, selected PEs can transmit to all
PEs - Selective S-PMSI, some ? some
- Unidirectional, selected PEs can transmit to
selected PEs
11Types of Multicast Trees
- 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
12Supporting Multiple Tree Types
- A PMSI is scoped to a single MVPN
- PMSI is instantiated using a tunnel (or set of
tunnels) - Tunnels may be
- 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
13Mappings to Old Terminology
- Default MDT
- MI-PMSI, instantiated by PIM Shared Tree or set
of PIM Source Trees - Data MDT
- S-PMSI, instantiated by PIM Source Tree
- New terminology helpful in
- Describing the complete set of options
- Allowing multiple instantiations of same service,
without changing service spec
14Autodiscovery
- 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)
15Aggregation
- 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 - Solution lots of options
- Draft-rosen has one MDT per VPN, and optional
data MDT for high BW or sparse customer groups - New draft also allows a tunnel to be shared
among multiple mVPNs - Better aggregation, less optimality
- Requires a de-multiplexing field (e.g., MPLS
label) - Utility of aggregation depends on amount of
congruence and traffic volume
16PE-PE Routing Exchange
- 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 - In new draft, BGP is proposed, as in unicast
- New AFI/SAFI
- Advertisement contains essentially the same info
as a PIM join or prune (source, group, PE sending
the message) - RDs are used to disambiguate customer multicast
group and source addresses - BGP route reflectors may be used
17Inter-AS
- Old (draft-rosen) approach tunnel spans multiple
ASes - Undesirable fate-sharing, must agree on tunnel
type - 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
18Inter-AS Overlay Tunnel
- 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
19Inter-AS Tunnels
Customer A
Customer A
ASBR1
ASBR2
Customer A
ASBR3
Intra-AS tunnels
Customer A
Inter-AS tunnels
20Other 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
21Conclusions
- WG draft builds on rosen draft without obsoleting
it - Support for more tree types, including PIM
variants, mLDP, RSVP-TE - Separation of service and mechanism
- Aggregation support
- More Inter-AS options with improved independence
- Possibility to use BGP for C-route exchange