Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-08 Thread Mark Smith
Thaler dtha...@microsoft.com; mbo...@ietf.org mbo...@ietf.org; 6...@ietf.org 6...@ietf.org Sent: Tuesday, 2 April 2013 7:56 AM Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Bunch of comments... 1. What Mark is proposing is being done AFAIK

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-03 Thread Behcet Sarikaya
6...@ietf.org; mbo...@ietf.org mbo...@ietf.org Sent: Saturday, 30 March 2013 8:33 AM Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Hi Mark, I read your draft. First of all I think you misunderstood RFC 6085 and based on a wrong assumption

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-02 Thread Carsten Bormann
On Apr 2, 2013, at 03:48, Toerless Eckert eck...@cisco.com wrote: Why should an AP not be able to convert multicast-unicast. Oh sure. I haven't checked 802.11 if its four-address structure actually might make this work without any change at the adaptation layer or above. Hacking the

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-02 Thread Toerless Eckert
Why should an AP not be able to convert multicast-unicast. All it would ahve to do is IGMPv3 snooping to know the clients connected to it. And it does know the per-client bitrate, aka: how far or how close a client is. I guess the one things that not possible is to send the smae multicast

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-02 Thread Andrew McGregor
Indeed, an 802.11 AP should be able to do this without breaking 802.11. However, there are probably wider cases where unicast fanout is worth doing. BTW, it's a common misconception that 802.11 transmit rates have something to do with range; actually, they're only very weakly correlated with

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Behcet Sarikaya
...@yahoo.com.au; 6...@ietf.org 6...@ietf.org; mbo...@ietf.org mbo...@ietf.org Sent: Saturday, 30 March 2013 8:33 AM Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Hi Mark, I read your draft. First of all I think you misunderstood RFC 6085 and based on a wrong

RE: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Christian Huitema
...@ietf.org] On Behalf Of Behcet Sarikaya Sent: Monday, April 1, 2013 8:33 AM To: Mark Smith Cc: mbo...@ietf.org; 6...@ietf.org; Dave Thaler Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Hi Mark, On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith markzzzsm

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Behcet Sarikaya
: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast ** ** Hi Mark, ** ** On Fri, Mar 29, 2013 at 5:18 PM, Mark Smith markzzzsm...@yahoo.com.au wrote: Hi Behcet, Thanks for your review and comments. From: Behcet

RE: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Christian Huitema
As far as I know, the operators prefer native multicast for IPTV applications, for a good reason. It seem like this is the application that  Mark has in mind. So, yes, it is a fairly good idea to study how multicast delivery could be accomplished by a series of unicast transmission.   There

RE: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Manfredi, Albert E
-Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Christian Huitema There are two solutions today: multicast all the way, from the source to the various destinations; and, unicast all the way. The multicast solution suffers from very poor

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Toerless Eckert
On Fri, Mar 29, 2013 at 08:55:21PM +, Dave Thaler wrote: http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast is work we did back in 2000 on this same topic. At the time, the draft is written from the perspective of the 6to4 NBMA link, but the topic was discussed

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Toerless Eckert
2013 8:33 AM Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Hi Mark, I read your draft. First of all I think you misunderstood RFC 6085 and based on a wrong assumption you developed your solution. What specifically do you think I've

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-04-01 Thread Carsten Bormann
On Apr 1, 2013, at 22:56, Toerless Eckert eck...@cisco.com wrote: It is clear that 802.11 is particularily challenged with native L2 multicast because they never defined a good resilience scheme as for unicast but so far not for multicast. Hopefully this will get fixed sometime. In

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-03-29 Thread Behcet Sarikaya
Hi Mark, I read your draft. First of all I think you misunderstood RFC 6085 and based on a wrong assumption you developed your solution. I suggest you take a look at http://tools.ietf.org/html/draft-sarikaya-netext-pmipv6-shared-link-01 on Netext for PMIPv6. I believe that we should use

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-03-29 Thread Mark Smith
March 2013 8:33 AM Subject: Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast Hi Mark, I read your draft. First of all I think you misunderstood RFC 6085 and based on a wrong assumption you developed your solution. What specifically do you think I've misunderstood? I

Re: [MBONED] MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast

2013-03-29 Thread Carsten Bormann
On Mar 29, 2013, at 23:18, Mark Smith markzzzsm...@yahoo.com.au wrote: The main use case I certainly can sympathize with this use case. I'm more interested in solutions that scale, up and down. When we did 6LoWPAN-ND to get rid of the requirement for subnet-wide multicast, we stuck to the