Multicast in L3VPNs - PowerPoint PPT Presentation

About This Presentation
Title:

Multicast in L3VPNs

Description:

... Can t leverage p2mp RSVP-TE, mLDP PE-PE exchange of C-routes using per-customer PIM instances Inter-AS challenges PMSI: ... – PowerPoint PPT presentation

Number of Views:48
Avg rating:3.0/5.0
Slides: 22
Provided by: BruceD151
Learn more at: https://www.ietf.org
Category:
Tags: l3vpns | multicast | pmsi

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com