eric rosen (erosen@cisco) rahul aggarwal (rahul@juniper)

Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 1

Multicast in BGP/MPLS VPNs

draft-ietf-l3vpn-2547bis-mcast-00.txtand

draft-raggarwa-l3vpn-2547bis-mcast-bgp-00.txt

Eric Rosen ([email protected])

Rahul Aggarwal ([email protected])

2Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

MVPN Improvements

Scalability:

• Control plane: reduce overhead needed to maintain state

• Data plane:

• more aggregation

• Tunnels on per-VPN or coarser basis

Control Integration: reuse general L3VPN mechanisms?

More optimality in data plane

• Less aggregation, but less scalable.

Eliminate requirement for MI-PMSI-based control

More flexibility in choosing tunneling technologies

Inter-AS Architecture


Tensions Scale vs. Optimality, duh!

• More accepted in unicast rtg than in mcast rtg

“Known to Work” vs. “Being Invented Now”

Control: integration vs. optimization

Data vs. Control Plane

• Which is bottleneck??

Multicast has unpredictable demands

Dogma


Non-Goals Generic Improvements to Multicast

Technology

• Welcome, but not our focus

Solutions for non-L3VPN environments


Data Plane MI-PMSI Elimination? Data MI-PMSI makes it easier to handle:

• Dense Mode

• Flooding-based applications

• Transparent when MI-PMSI is in place

• Require special measures otherwise

• E.g.:, BSR


Multi-Homed Sources and Duplicate Traffic

PE3 wants <S1,G> via PE1, <S2,G> via PE2

PE4 wants <S1,G> via PE2, <S2,G> via PE1

Data from both streams travels both trees: duplicates

With MI-PMSI in control plane, PIM Asserts can be used to prevent this by forcing a “designated forwarder”

Need alternative

PE1 PE2

PE3 PE4 PE3 PE4

S1, S2 S1, S2


Eliminating Duplicates Option 1: PE discards streams on “wrong” tree

• Possible, with MPLS even easy

• Wastes core bandwidth (trade-off)

Option 2: All PEs must choose same ingress

• How? no unique “best route” to S

• Can waste core bandwidth, increase latency

Maybe: best of both

• Policy to force same ingress per AS only

• Not to force the same ingress across ASs (prefer intra-AS path)

• Mandatory mechanism to force dups to be discarded


Theme for BGP Work BGP: L3VPN PE-PE signaling mechanism

Prima facie advantages of using for PE-PE multicast signaling:

• Uniform control plane

• Leverage of capabilities: constrained distribution, security, summarization, inter-AS, etc.

Scaling needs to be carefully examined

Dynamics


Theme for BGP Work, 2 Don’t get carried away

• No need to suppress work on other options

• Don’t throw away “known to work” schemes

Two different functions to handle:

• Not new to BGP: auto-discovery for MVPNs, label distribution for m-tunnels, m-streams, binding streams to tunnels

• New to BGP: carrying PE-PE multicast routing, interfacing to PIM


Basic BGP Interactions1. R-state: Egress PE gets PIM J/P from CE,

instantiates state: "(S,G)receivers"

2. Distribute R-state based on RTs for VPN.

• Design issue: mapping PIM J/Ps to updates and withdraws, not always obvious

3. S-state: many-to-one binding of R-state to P-tunnel

4. When ingress PE receives R-state, it sends PIM J/P to CE, may or may not need to create and distribute new S-state

• New S-state only needed for S-PMSI binding

• S-state distribution based on RTs for VPN


S-State Scaling, 1 How many S-states are needed?

• Minimum: one per VPN

• each VPN has a default tunnel (possibly shared with others),

• MPLS label not used for per-stream demux,

• Maximum: one per stream

• each stream individually bound to a tunnel, or

• MPLS label used for per-stream demux

• What is the rate of change of S-state?


S-State Scaling, 2 Distributing S-state (only for S-PMSI)

• Needs to be known by ingress & each egress

• Possible to restrict distribution:• only to egresses for stream, or

• to all PEs in VPN.

Trades off more information with latency and signaling overhead

S-states increased by multi-homing of sources, perhaps not significantly


R-State Scaling 1 This is the stuff that PIM usually handles

• pure PIM states rather than labels/bindings

Total # R-states:

• At egress PE, # streams

• At ingress PE, we have choices:

• One per stream per egress PE (“explicit tracking”)

• One per stream (receivers somewhere, don’t remember where)

Applies to any control protocol


R-State Scaling (Intra-AS) 2 Is explicit tracking needed?

• No in these cases:

• Default tunnels (any tunnel setup protocol)

• Selective tunnels set up via PIM or mLDP

• Yes in these cases:

• Selective tunnels set up via RSVP-TE

• “Aggregation via congruence” S-PMSIs

Should be used only when needed, as determined by head-end


R-State Scaling (Intra-AS) 3 Without explicit tracking:

• R-states can be regarded by BGP as “comparable” routes (NLRI design)

• Aggregate R-state at RR

• RR gets one per stream per PE, forwards one per stream


BGP MVPN FunctionalityIntra-AS

MVPN Auto-Discovery/Inclusive Binding

• Granularity of <PE, MVPN>

• Binding one or more MVPNs to a P-tunnel (I-PMSI)

C-multicast routing information exchange among PEs

• Granularity of <PE, C-S/C-RP, C-G>

Selective binding and switching from I-PMSI to S-PMSI

• One or more specific C-multicast streams, from one or more MVPNs, to a P-Tunnel


BGP MVPN FunctionalityInter-AS

MVPN Auto-Discovery• Aggregation of Auto-discovery information

• Granularity of <AS, MVPN> Inter-AS tunnels constructed by stitching intra-AS tunnels

• Independent P-Tunneling technology per provider MVPN PE-PE Routing Exchange

• Aggregation of R-state• Granularity of <AS, C-S/C-RP, C-G>

Routing peerings between ASs only at ASBRs or RRs Use RT Constrain to limit distribution of auto-discovery

routes and C-multicast routes Support of all three options for inter-AS unicast


BGP MVPN Inter-AS MVPN that is present in N ASs would result in N

inter-AS P-tunnels (one per AS, not one per PE)

• To improve scalability multiple intra-AS tunnel segments within an AS could be aggregated into a single intra-AS P-tunnel

• Uses auto-discovery routes

Inter-AS R-state is propagated by egress PE towards the source AS

• Propagates using the inter-AS auto-discovery routes i.e. <source AS, MVPN> route

• No flooding of R-state

• No R-state in the ASBR forwarding plane


BGP Extensions – MCAST VPN NLRI

Consists of • RD

• Src PE Address

• C-S length, C-S

• C-G length, C-G

• MPLS labels

Used for Auto-Discovery Routes• MVPN intra/inter-AS auto-discovery

• Intra-AS I-PMSI and S-PMSI binding

• Inter-AS tunnels “stitched” from intra-AS segments

Also used for C-multicast routes• Intra/Inter-AS C-multicast routing information exchange


Switching to S-PMSI Driven by PE connected to C-S

Binds (C-S, C-G) to a particular P-tree

• P-tree may be shared with other (C-S, C-G)• Sharing is not constrained by MVPN membership

Uses auto-discovery routes

Uses the same procedures as auto-discovery, except that MCAST VPN NLRI carries C-S, C-G

• Both for intra-AS and inter-AS

eric rosen (erosen@cisco) rahul aggarwal (rahul@juniper)

Documents