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
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
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
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
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
...@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
...@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
: [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
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
...@ietf.org 6...@ietf.org
Sent: Friday, 29 March 2013 7:21 PM
Subject: Re: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
Hi Mark,
interesting draft. I'm interested in this from a 6LoWPAN perspective --
everything we can do to get rid of multicasts is very good for 6LoWPANs.
I
-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
: Thursday, March 28, 2013 8:22 PM
To: 6...@ietf.org
Subject: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
Hi,
The following is inspired by some work I did in around 2010/2011 on a
multicast TV service, where residential customers with Wifi networks
suffered from
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
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
Could some combination of IGMPv3 and ND signal to whatever is sending
doing the layer-2 multicast operations (e.g. the sender, or the router)
that the receiver would prefer to be receive layer-2 unicasts?
That could therefore happen at the IGMP aware switch, etc.
--
] Never tell
: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
IPv6
Creation date: 2013-03-29
Group: Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00.txt
Status:
http
Procedures for Link-Layer Unicast Delivery of
Multicast
IPv6
Creation date: 2013-03-29
Group: Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00.txt
Status:
http://datatracker.ietf.org/doc/draft-smith-mldv2-link
...@ietf.org
Sent: Friday, 29 March 2013 6:31 PM
Subject: Re: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
Hi Andrew,
Thanks very much for your review and comments.
From: Andrew McGregor andrewm...@gmail.com
To: Mark Smith markzzzsm
Title: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
IPv6
Creation date: 2013-03-29
Group: Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00.txt
Status:
http
, as such it gets trapped in Mailman with:
8-
Subject:Re: MLDv2 Procedures for Link-Layer Unicast Delivery of
Multicast
Size: 10605 bytes
Reason: Message has implicit destination
-8
The multi-hour delay comes from the simple fact that the people who
admin
On 2013-03-29 08:49 , Jeroen Massar wrote:
On 2013-03-29 08:38 , Mark Smith wrote:
There seems to be multi-hour delays to the 6...@ietf.org mailing
address, a copy for reference. I'll make sure all future replies are
to ipv6@ietf.org.
That is because you are sending mails without directly
Hi Mark,
interesting draft. I'm interested in this from a 6LoWPAN perspective --
everything we can do to get rid of multicasts is very good for 6LoWPANs.
I don't understand how you think NUD would work with this (3.2) -- are you
saying that the multicast emitter actively runs NUD to the
Hi Carsten,
Thanks very much for your review and comments.
- Original Message -
From: Carsten Bormann c...@tzi.org
To: Mark Smith markzzzsm...@yahoo.com.au
Cc: 6...@ietf.org 6...@ietf.org
Sent: Friday, 29 March 2013 7:21 PM
Subject: Re: MLDv2 Procedures for Link-Layer Unicast
On Mar 29, 2013, at 10:52, Mark Smith markzzzsm...@yahoo.com.au wrote:
Yes. NUD is performed on the link-local addresses used as the source
addresses for the MLDv2 messages.
RFC 4861 says:
Neighbor Unreachability Detection detects the failure of a neighbor
or the failure of the forward
Hi Carsten,
- Original Message -
From: Carsten Bormann c...@tzi.org
To: Mark Smith markzzzsm...@yahoo.com.au
Cc: ipv6@ietf.org ipv6@ietf.org
Sent: Friday, 29 March 2013 9:07 PM
Subject: Re: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
On Mar 29, 2013, at 10:52
28, 2013 8:22 PM
To: 6...@ietf.org
Subject: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
Hi,
The following is inspired by some work I did in around 2010/2011 on a
multicast TV service, where residential customers with Wifi networks
suffered from performance problems
:)
The most relevant WG is MBoneD.
-Dave
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Mark Smith
Sent: Thursday, March 28, 2013 8:22 PM
To: 6...@ietf.org
Subject: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
Hi
...@ietf.org 6...@ietf.org
Cc: mbo...@ietf.org mbo...@ietf.org
Sent: Saturday, 30 March 2013 7:55 AM
Subject: RE: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
http://tools.ietf.org/html/draft-thaler-ngtrans-6to4-multicast
is work we did back in 2000 on this same topic. At the time
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
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
: MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
IPv6
Creation date: 2013-03-29
Group: Individual Submission
Number of pages: 7
URL:
http://www.ietf.org/internet-drafts/draft-smith-mldv2-link-unicast-00.txt
Status:
http
31 matches
Mail list logo
