Multicast in L3VPNs

1
Multicast 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
2
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?
• Attempts to make me look ignorant will be frowned
  upon

3
Agenda

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

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

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

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

8
Default 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

9
Limitations 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

10
PMSI 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

11
Types 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

12
Supporting 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

13
Mappings 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

14
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)

15
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
• 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

16
PE-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

17
Inter-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

18
Inter-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

19
Inter-AS Tunnels
Customer A
Customer A
ASBR1
ASBR2
Customer A
ASBR3
Intra-AS tunnels
Customer A
Inter-AS tunnels
20
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

21
Conclusions

• 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