A Reset on Softwire Mesh Multicast

Mingwei XuYong Cui

CERNET, ChinaChris Metz, Cisco

IETF76 Meeting, HiroshimaNov 2009

Why?

• RFC4925 and Softwires Charter state multicast is a requirement

• Operators have expressed requirements for multicast solution

• Softwire Mesh Unicast methods defined. Where is the Multicast?– Is section 11 of RFC5565 sufficient?

• Imminent IPv4 run-out; need to complete Softwires Mesh functions (include multicast)

Softwire Mesh Multicast

I-IP Backbone

E-IP

AFBR

AFBRAFBR

E-IPE-IP

AFBR

E-IPS

R R

I-IP TreeE-IP Tree

Softwire Mesh Multicast Framework

• 1:1 Mapping (Internet Multicast Model)– one E-IP tree maps to one I-IP tree– I-IP core multicast state scales linearly with E-IP client

multicast state

• “mVPN-like” – I-IP core multicast state scales less than linearly with E-IP

client multicast state– AFBR routers act like PE routers supporting one VPN– Techniques outlined in L3VPN Multicast docs

Use-Cases and MethodsNumber E-IP I-IP Mapping Methods Comments

1. IPv6 IPv4 (and MPLS)

1:1 • PIM RPF Vector• Inter-AFBR

signaling (PIM or BGP)

Need details

2. IPv4 IPv6 1:1 • Algorithmic IPv4-to-IPv6 mapping at AFBR

Need details

3. IPv6 IPv4 (and MPLS)

N:1 • Employ L3VPN multicast techniques

mVPNv6 implementations exist

4. IPv4 IPv6 N:1 • Employ L3VPN multicast techniques

Lower priority

Summary and Suggested Next Steps

• There is unfinished work – Softwire Mesh Multicast

• Suggested Next Steps– Focus on 1:1 Use-Cases– Document these use-cases and add more details

on protocol and vehicle functions and behaviors