8/3/2019 l3vpn-1

1/21

Multicast in L3VPNs

Bruce Davie1

bsd@cisco.com

draft-ietf-l3vpn-2547bis-mcast-03.txt

1. Not a draft co-author, or a multicast expert

8/3/2019 l3vpn-1

2/21

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 proposedsolutions

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

8/3/2019 l3vpn-1

3/21

1draft-rosen-vpn-mcast-08.txt

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

8/3/2019 l3vpn-1

4/21

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

8/3/2019 l3vpn-1

5/21

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-customerstate in P-routers

PE-routers exchange customer routing information using PIM

Contrast to BGP for unicast

Customer multicast group addresses need not be uniqueSame as 2547/4364

8/3/2019 l3vpn-1

6/21

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

8/3/2019 l3vpn-1

7/21

Customer B

Default MDT

239.192.10.2

Customer B

CE

Customer B

CE

PE PE

Customer B

CE

PE

Default Multicast Distribution Tree

PE routers build a default MDT in the global table for each mVRFusing standard PIM procedures

All PEs participating in the same mVPN join the sameDefault MDT

Every mVRF must have a Default MDT

MDT group addresses are defined by the providerUnrelated to the groups used by the customer

Data MDTs may be created for high BW sources

8/3/2019 l3vpn-1

8/21

Default Multicast Distribution Tree

Default MDT is used as a permanent channel for PIM controlmessages 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

Customer BCustomer B

Default MDTDefault MDT

239.192.10.2239.192.10.2

Customer B

CE

Customer B

CE

PE PE

Customer B

CE

PE

Multicast TunnelInterface

Customer BCustomer B

Default MDTDefault MDT

239.192.10.2239.192.10.2

Root

Leaf

8/3/2019 l3vpn-1

9/21

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

8/3/2019 l3vpn-1

10/21

PMSI: P-Multicast Service Interface

New terms introduced to decouple tree from service

A PE delivers packet to PMSI, then all the requiredPEs will get than packet and known which MVPN itbelongs 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 toselected PEs

8/3/2019 l3vpn-1

11/21

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

8/3/2019 l3vpn-1

12/21

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

8/3/2019 l3vpn-1

13/21

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

8/3/2019 l3vpn-1

14/21

Autodiscovery

The process of discovering all the PEs with membersin 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, andwhether aggregation is supported

May contain a tunnel ID

Can also be used to discover set of PEs interested ina given group (to enable S-PMSI creation)

8/3/2019 l3vpn-1

15/21

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 PEsthat 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 forhigh BW or sparse customer groups

New draft also allows a tunnel to be shared amongmultiple mVPNs

Better aggregation, less optimality

Requires a de-multiplexing field (e.g., MPLS label)

Utility of aggregation depends on amount of congruence andtraffic volume

8/3/2019 l3vpn-1

16/21

PE-PE Routing Exchange

In draft-rosen, C-PIM instances exchange PIMmessages 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

A

dvertisement contains essentially the same info as a PIMjoin or prune (source, group, PE sending the message)

RDs are used to disambiguate customer multicast group andsource addresses

BGP route reflectors may be used

8/3/2019 l3vpn-1

17/21

Inter-AS

Old (draft-rosen) approach: tunnel spans multiple

ASes

Undesirable fate-sharing, must agree on tunnel type

New draft allows another approach: may splicetunnels from different ASes

Allows each AS to build its tunnels independently of

otherASes

Scaling now independent of number of PEs in otherASes

8/3/2019 l3vpn-1

18/21

Inter-AS Overlay Tunnel

For a given MVPN, each AS independently buildsan intra-AS tunnel

In addition, an overlay tunnel that spans multipleASes is built

Each PE announces its MVPN membership info tothe ASBRs with iBGP

An ASBR announces the AS MVPN membership tootherASBRs (in otherASes) using eBGP

This enables an AS-level spanning tree to be builtamong the set ofASes with members in this MVPN Inter-AS tunnels spliced to intra-AS tunnels

8/3/2019 l3vpn-1

19/21

Inter-AS Tunnels

ASBR1ASBR2

CustomerA CustomerA

ASBR3

CustomerA

CustomerA

Intra-AS tunnels

Inter-AS tunnels

8/3/2019 l3vpn-1

20/21

Otherissues

RPF establishment

PEs need to know who theirRPF PE is for a given route

Duplicate detection

Multihomed sites and switching from shared to source treecan 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

8/3/2019 l3vpn-1

21/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