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

2013-04-08 Thread Mark Smith
rg" ; "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 AFAI

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

2013-04-03 Thread Behcet Sarikaya
d > as opposed to a >protocol group (i think... ). > > Cheers > Toerless > >tracking of >that it is consisting purely of mechanisms that the accss-point type > device in a > > > On Fri, Mar 29, 2013 at 03:18:06PM -0700, Mark Smith wrote: > >

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 rang

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 group

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

2013-04-01 Thread Carsten Bormann
On Apr 2, 2013, at 03:48, Toerless Eckert 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 destination address vi

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 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 a MIMO world

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

2013-04-01 Thread Toerless Eckert
o...@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 mi

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 > (spec

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

2013-04-01 Thread Mark Smith
gt; > Sent: Tuesday, 2 April 2013 7:06 AM > Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of > Multicast" > >> -Original Message- >> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of >> Christian

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 poo

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.  

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

2013-04-01 Thread Behcet Sarikaya
t 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" > > *

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 mailto

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

2013-04-01 Thread Behcet Sarikaya
> 6...@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. >

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 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 constrained node network u

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

2013-03-29 Thread Mark Smith
Hi Behcet, Thanks for your review and comments. > > From: Behcet Sarikaya >To: Dave Thaler >Cc: Mark Smith ; "6...@ietf.org" <6...@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"

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 multicast