Subject: mboned: Possible Multicast Get Together at RIPE 52

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Apr 2006 08:43:18 -0400

Hello;

If there are enough Mboned members (or potential members) going to  
RIPE-52, we
could get together to discuss the status of Mboned, plans for going  
forward, and brainstorm
anything of interest.

I am especially interested in reaching people who are doing multicast  
and who may not be currently involved in the WG,
or who may not have the chance to come to the IETFs in the US /  
Canada. I can announce this in my Plenary talk scheduled Monday,
so I would suggest either Monday at 5:00 PM or Monday after the  
opening reception.

Regards
Marshall

Begin forwarded message:

> From: RIPE NCC meeting coordinator <[email-masked]>
> Date: April 6, 2006 4:06:58 AM EDT
> To: [email-masked], [email-masked], [email-masked]
> Subject: RIPE 52: Plenary Agenda
>
> [Apologies for duplicate mails]
>
> Dear Colleagues,
>
> RIPE 52 will be held 24 - 28 April 2006 at the Ceylan InterContinental
> Hotel in Istanbul, Turkey.
>
> RIPE 52 PLENARY AGENDA
> The plenary agenda and presentation abstracts are available at:
> http://www.ripe.net/ripe/meetings/ripe-52/presentations/
>
> MEETING PLAN
> The meeting plan is available at:
> http://www.ripe.net/ripe/meetings/ripe-52/meeting-plan.html
>
> RIPE NCC SERVICE CENTRE
> The RIPE NCC Service Centre, open to all meeting attendees, will be
> introduced at RIPE 52. The centre is available to RIPE NCC members and
> non-members.
>
> RIPE NCC staff will be available to answer your questions on subjects
> including:
> - Internet resource requests (IPv4, IPv6, Autonomous System Numbers)
> - The RIPE Whois Database
> - Invoice, billing and administrative queries
> - RIPE NCC Training Courses and the RIPE NCC E-Learning Centre
> - Routing Information Services (RIS), and BGPlay
> - rDNS, DNSSEC, DNSMON
> How to become a Local Internet Registry (LIR)
> More information is available at:
> http://www.ripe.net/ripe/meetings/ripe-52/services-centre.html
> RIPE 52 INFORMATION
> For further information on RIPE 52, please see:
> http://www.ripe.net/ripe/meetings/ripe-52/
>
> RIPE 52 REGISTRATION
> You can register for this meeting at:
> https://lirportal.ripe.net/lirportal/meeting/registration/ 
> meeting.html?id=29
>
> Should you have any questions, please contact us at:
> <[email-masked]>.
>
> Regards,
>
> Camilla Meidell
> Conference Coordinator
> RIPE NCC
>

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Thu, 6 Apr 2006 08:13:09 -0700

Folks,

	I think one of the things that MBONED might want to be
	looking at/taking on is the rise of L2 multicast
	solutions, and the fact that transport oriented SPs seem
	to favor these solutions over the IGMP/PIM
	architecture(s) we've built in the IETF.

	Dave

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 6 Apr 2006 09:30:19 -0700

> 	architecture(s) we've built in the IETF.

Or rather they have at best superficial understanding of IP multicast and
simply expect that if they wave magic "snooping" wand, then they can avoid to
ever understand it and will get a perfectly well working L2 network that
transports multicast video efficiently.

Why does only multicast get pounded with this ? "Can i please have routers
that do Spanning Tree snooping instead of ISIS or OSPF" ? I mean why don't
the unicast folks get some share of clueless requirements ?

Cheers
    Toerless

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 6 Apr 2006 12:48:18 -0400

> -----Original Message-----
> From: Toerless Eckert [mailto:[email-masked]] 

> the unicast folks get some share of clueless requirements ?

In case that wasn't a rhetorical question ...

The situation is a little different, right? Unicast is done efficiently
over large L2 nets now, whereas multicast over these same large L2 nets,
by default, is flooded. Which scares the SPs, I presume.

To do multicast efficiently requires either an increase in routers
throughout the SP backbone, and application of L3 multicast techniques,
or the snooping stuff, or GMRP, if you don't want to change the L3
structure.

Bert

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 6 Apr 2006 09:59:18 -0700

> In case that wasn't a rhetorical question ...

It was ;-)

> by default, is flooded. Which scares the SPs, I presume.

Well. There are two levels of problems:

 a) L2 networks are actually great if you ONLY need to flood your
    multicast traffic. Many IPTV deployments today think that that's
    what you need to do with broadcast TV programming, so i have no
    problem for the industry to move towards making that efficient
    (and that primarily involved to use P2MP delivery tree in SP cores
     as opposed to a big hub&spoke P2P pseudowire type distribution, which
     is the only thing done today).
    
    Now of coures i think that also in IPTV distribution trees should be
    more dynamic because there will be more such dynamic when you want to
    add application elements such ad ad-splicers, source redundancy,
    regional channel distribution, headend service providers, etc., ppp
    But at that point the latest you should stop doing L2 i think.
 
 b) So if you get to a level where you actually want to have well
    constrained multicst trees in your delivery network, then anything in
    L2 will just have to reinvent what is already working nicely in L3,
    and it can not be any simpler but will be more complex than at L3,
    because IGMP snooping and PIM snooping are as complex as IGMP and PIM
    PLUS the complexity of snooping.

I think the big difference is really that L2vPN service provide a
nice transparent unicast service, which is what L3VPNs don't: The customer
can use whatever unicast routing protocol he wants, and the SP does not
need to care. And that works. And it is actually quite a different service
between unicast in L2VPN and unicast in L3VPN.

And the problem is that customers have the expectation to get the same 
L2VPN over L3VPN benefits for multicast.  And that's just not true. Whether
you have an L3VPN or an L2VPN, you always want to have the same service: you
want the service provider to build explicit efficient delivery trees for
your IP multicast flows, that likely will be SSM. And with L2 it's even
more unlikely for that to correctly happen.

Cheers
    Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 6 Apr 2006 17:30:14 -0700

>> the unicast folks get some share of clueless requirements ?

    Because flooding unicast packets doesn't scale. And at one point it didn't
    work for multicasts either. But flooding IGMP reports doesn't scale either.
    It is just working in existing L2 networks because they are small and
    well contained.

Dino