63rd IETF Paris August 2005 Requirements for Multicast Support in Virtual Private LAN Services draft-kamite-l2vpn-vpls-mcast-reqts-00.txt Yuji Kamite (NTT Communications) Yuichiro Wada (NTT Communications) Yetik Serbest (SBC) Thomas Morin (France Telecom) Luyuan Fang (AT&T)

63rd IETF Paris August 2005 Overview Motivation –Multicast scalability issue Technical challenges in existing VPLS -- emerging expectation toward multicast application today –Various solutions are proposed Need requirement documentation as a basis This drafts is to: –Clarify issues in multicast VPLS –Describe specific requirements in multicast VPLS –Guide multicast VPLS solution design

63rd IETF Paris August 2005 Multicast Challenges in VPLS (1/2) Issue AIssue A: Replication to non-member site –Multicast concerned (broadcast case is inevitable) for Customer: Access line Bandwidth waste for SP: Over provisioning / PE performance Access L2 NW Joined Source CE PE No Member Not needed VPLS No Member

63rd IETF Paris August 2005 Multicast Challenges in VPLS (2/2) Issue BIssue B: Replication of PWs on shared physical path –Multicast and Broadcast concerned both for Customer: (No problem) for SP: Over provisioning / PE performance Access L2 NW Source CE PE Not needed VPLS

63rd IETF Paris August 2005 Summary of Requirements General Requirements –SHOULD solve Issue A, Issue B or both Unknown unicast is out of scope –Treat data packets (not control packets!) SHOULD support a way to provide customer's IP multicast MAY consult Layer-3 information (typically snooping), but allow static or other Layer-2 control protocol approaches too SHOULD simply flood control packets (e.g. BPDUs) Customer Requirements Layer-2/Layer-3 protocol Multicast domain (reachability scope) QoS, SLA etc. Service Provider Requirements Scalability OAM (multicast-specific points) H-VPLS etc.

63rd IETF Paris August 2005 Remaining Issues Major open questions (written inside the draft): –Requirement level of Issue A and B SHOULD solve A, B or both (current version) / MUST solve A, B or both (stronger better?) / MUST A, SHOULD B / SHOULD A, MUST B (different level?) Others –Which PE-CE protocols are consulted (PIM, IGMP etc.) … Feedback welcome: –Is this the right approach? –Application considerations (use cases)? –Any other specific requirements?

63rd IETF Paris August 2005 Next Steps Enhance the document with more feedback –We already incorporated various contributors’ opinions, but still need more comments on the mailing list Propose to adopt this as a WG document