http://blog.gmane.org/gmane.ietf.mboned hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.mboned/4096 <pre> We now have a new version of the draft that suggests some major changes, e.g. what is an SSM address (including ff2x::/32 for IANA allocations). It would be great if you can see if this addresses the errata, and also whether it makes sense in general. The latest version is at http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01 Stig _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Stig Venaas 2013-06-05T18:11:26 http://permalink.gmane.org/gmane.ietf.mboned/4095 <pre>WG, This version integrates Stig's comments of late March. Cheers, Christian. -----Message d'origine----- De : internet-drafts&lt; at &gt;ietf.org [mailto:internet-drafts&lt; at &gt;ietf.org] Envoyé : mercredi 5 juin 2013 16:38 À : Tina Tsou; Qiong Sun; BOUCADAIR Mohamed OLNC/OLN; JACQUENET Christian OLNC/OLN; Tina Tsou; Yiu Lee; Jacni Qin Objet : New Version Notification for draft-ietf-mboned-v4v6-mcast-ps-03.txt A new version of I-D, draft-ietf-mboned-v4v6-mcast-ps-03.txt has been successfully submitted by Christian Jacquenet and posted to the IETF repository. Filename: draft-ietf-mboned-v4v6-mcast-ps Revision: 03 Title: IPv4-IPv6 Multicast: Problem Statement and Use Cases Creation date: 2013-06-05 Group: mboned Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-ietf-mboned-v4v6-mcast-ps-03.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mboned-v4v6-mcast-ps Htmlized: http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-v4v6-mcast-ps-03 Abstract: This document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning. The IETF Secretariat _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> christian.jacquenet< at >orange.com 2013-06-05T14:39:47 http://permalink.gmane.org/gmane.ietf.mboned/4094 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : IPv4-IPv6 Multicast: Problem Statement and Use Cases Author(s) : Christian Jacquenet Mohamed Boucadair Yiu Lee Jacni Qin Tina Tsou Qiong Sun Filename : draft-ietf-mboned-v4v6-mcast-ps-03.txt Pages : 20 Date : 2013-06-05 Abstract: This document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mboned-v4v6-mcast-ps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-v4v6-mcast-ps-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> internet-drafts< at >ietf.org 2013-06-05T14:38:02 http://permalink.gmane.org/gmane.ietf.mboned/4093 <pre> If you would like to present anything at MBONED in Berlin, please let Greg and me know what you'd like to cover and how much time you'd like. Thanks, MBoned Chairs _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Leonard Giuliano 2013-05-15T18:48:59 http://permalink.gmane.org/gmane.ietf.mboned/4092 <pre>Hi On 5/11/2013 11:25 AM, Toerless Eckert wrote: Med (copied) and I are trying to get some of these issues resolved, we have one draft (draft-ietf-6man-multicast-addr-arch-update) that will try to clarify and resolve some conflicts. We intent to discuss some of these SSM issues mentioned here as well. We will probably both on the list and in the next IETF meeting try to discuss some of these issues. We've been focusing on how the flag bits are used, and one of the cases is the use of the transient flag and SSM. Perhaps this thread is a good opportunity to move forward on this topic. One question in particular, is whether the T bit should be allowed to be 0 for SSM, and whether the IANA SSM assignments (non-yet) should have T=0. Stig _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Stig Venaas 2013-05-13T17:21:05 http://permalink.gmane.org/gmane.ietf.mboned/4091 <pre>Let me add mboned and the author of said errata. The author of this errata seems to claim inconsistency between 4607 and prior addressing standards (RFC3307, RFC4291). He also states: "I'm sure that RFC 4291 should NOT be called in question.". This to me implies that he is asking to have RFC4607 updated to remove these conflicts in RFC4607bis. IMHO: I have not been able to (in)validate the erratas author claims wrt. to the interpretation of the prior RFCs. I hope others on the lists can chime in. Assuming he is right on one or the other accounts: I would like to see a resolution that minimizes actual deployment/interoperability problems. Withdrawing address ranges deemed to be useable according to existing RFC4607 in an upcoming RFC4607bis definitely has the potentialy to create mayor disturbances in deployments relying on those addresses. If MBoned can clearly identify affected ranges known not to be deployed at all, then they could be redesignated, otherwise IMHO not. I have not seen any example of actual deployment/interoperability issues from the incompatibility of existing RFC4607 and its claimed conflicts with prior address architectures. It would be good if the author of the errata (or someone else) could provide some example of such breakage. If no real breakage could reasonably be claimed, i think RFC4607bis should grandfather in the ranges from RFC4607 and explain how we derived at them, and that they constitute unfortunate, but not caught violations of principle due to the a) human nature, b) IETF process or c) the complexity of the IPv6 address architecture. And grandfathering is not the same as questioning RFC4291. Cheers Toerless On Sat, May 11, 2013 at 05:36:53PM +0100, Adrian Farrel wrote: _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Toerless Eckert 2013-05-11T18:25:40 http://permalink.gmane.org/gmane.ietf.mboned/4090 <pre>It's a start. For what are you looking? Greg On Wed, May 8, 2013 at 5:34 AM, Jan Ollmann &lt;bkgmjo&lt; at &gt;gmx.net&gt; wrote: _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Greg Shepherd 2013-05-08T14:33:56 http://permalink.gmane.org/gmane.ietf.mboned/4089 <pre>Hey there, I am not sure if I am right here but some IANA support person said people here could help me find out who operates a specific multicast network. Is this correct?_______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Jan Ollmann 2013-05-08T12:34:25 http://permalink.gmane.org/gmane.ietf.mboned/4088 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:41:26 http://permalink.gmane.org/gmane.ietf.mboned/4087 <pre> On 04/25/2013 07:14 PM, Greg Bumgardner wrote: ok, thanks and resubmit the updated version to see where we are. Thanks, Martin </pre> Martin Stiemerling 2013-04-25T17:19:22 http://permalink.gmane.org/gmane.ietf.mboned/4086 <pre>Martin, IPv6 is mentioned in the second paragraph though the description is pretty vague - basically implying that, just as an IPv6 router is not supposed to (re)fragment IPv6 datagrams, an AMT relay should not fragment data messages that encapsulate non-fragmented datagrams. I'll expand on this in the the paragraph in question, and will review the normative description to see if it is adequate. Thanks, -g.b. On Mon, Apr 22, 2013 at 8:44 AM, Martin Stiemerling &lt; martin.stiemerling&lt; at &gt;neclab.eu&gt; wrote: </pre> Greg Bumgardner 2013-04-25T17:14:46 http://permalink.gmane.org/gmane.ietf.mboned/4085 <pre>Le 2013-04-24 à 12:30, Brian Haberman &lt;brian&lt; at &gt;innovationslab.net&gt; a écrit : I read in the draft three operators as co-authors: Orange, Comcast, China Telecom So my reading of the situation is that some operators are interested in this, some don't. To me, that looks pretty similar to a lot of IETF technologies: i.e. some operators prefer IS-IS, others OSPF. I have a hard time thinking that for 3 major operators, from 3 different continents, the IETF is rejecting this work. I thought we wanted to listen to operators? Marc. _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Marc Blanchet 2013-04-24T17:13:20 http://permalink.gmane.org/gmane.ietf.mboned/4084 <pre>... ... Yeah, that part was a bit unthinking. The capital cost argument still holds, but obviously from your conversations the tradeoffs depend on the operator. _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Tom Taylor 2013-04-24T17:05:34 http://permalink.gmane.org/gmane.ietf.mboned/4083 <pre> I had conversations about v4/v6 multicast transition with network architects at two large service providers recently. Unfortunately, they did not want their employers named (due to unannounced plans), but were willing to talk about how *they* plan to migrate their multicast clients to IPv6. Their feedback to me is that their cost analyses indicated that it was much cheaper to move to dual-stack for multicast services than to introduce any kind of translation service. These costs included opex and capex. When I pointed them to the referenced document, one said it had no value to him and the other called it "a theoretical exercise". In a nutshell, their response to this problem mirrored Lenny's views on the subject. Could you elaborate on how making multicast receivers dual-stack would interfere with "a more general plan for rolling out IPv6"? Regards, Brian _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Brian Haberman 2013-04-24T16:30:41 http://permalink.gmane.org/gmane.ietf.mboned/4082 <pre>I cannot account for the results at RIPE and NANOG, except to say that the right people may not have been present. At the IETF, four different operators expressed concrete support for aspects of this work. I've learned to duck if an operator is discussing requirements, so if an operator does so, I will discreetly withdraw from the conversation. As far as your remarks on IPv6-only receivers are concerned: we agree that the simplest way to migrate IPTV to IPv6 is to start by upgrading the receivers to dual stack. We even wrote a draft saying so: draft-tsou-v6ops-multicast-01.txt. But the simplest migration plan may interfere with a more general plan for rolling out IPv6, or may require capital investment that the operator can't afford for the moment. Tom Taylor On 19/04/2013 1:29 PM, Leonard Giuliano wrote: _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Tom Taylor 2013-04-23T02:52:33 http://permalink.gmane.org/gmane.ietf.mboned/4081 <pre> On 04/08/2013 03:43 PM, Greg Shepherd (shep) wrote: The current statement is ok. What about this question: - Section 4.2.2.4 looks rather incomplete as it basically only describes the IPv4 case. Is this intentionally? Otherwise, please post an updated version of the draft. Martin </pre> Martin Stiemerling 2013-04-22T15:44:12 http://permalink.gmane.org/gmane.ietf.mboned/4080 <pre> &lt;Co-chair hat off, speaking as an individual&gt; Overall, I have a great deal of skepticism of the utility, not only of this draft, but of the MULTRANS work in general. My concern is that this work is of no interest to production network deployments and that the work will generate nothing more than a flood of documents in the WG that don't really solve any real world problems. I base this skepticism on the following: 1) No interest outside of this WG: Personal suspicions aside, when brought up in RIPE, according to the meeting report, "The response from the room indicated that this is not something people need." The video was even more revealing and speaks for itself: https://ripe65.ripe.net/archives/video/182/ When brought up at NANOG, there was again no response: http://marc.info/?l=nanog&amp;m=134445649807595&amp;w=4 2) Current deployment status of the technologies being transitioned to/from: Using certain metrics in the best light, IPv4 multicast today encompasses 1-3% of the global Internet. Global IPv6 unicast penetration is roughly similiar. The union of these 2, IPv6 multicast, is practically nonexistent on the Internet. Are folks really clamoring to transition traffic from the nearly nonexistent (v4 mcast) to the practically nonexistent (v6 mcast)? 3) The scope of the solutions There is apparent widespread agreement that the scope of the problem and solutions should be limited to intradomain. Within domains, there is significant flexibility to solve these problems (or avoid them in the first place). One of the apparent motivators for this work is that v6-only set-top boxes will want to receive v4 multicast. v6-only STBs?? For years now, I've been told that STBs can't possibly be expected to add advanced features like IGMPv3 (RFC 3376 came in 2002), so SSM deployment has been limited (or hacks like ASM-&gt;SSM mapping have been implemented to circumvent). But now v6-only STBs? Can they at least do dual stack and join the v4 mcast streams that apparently cannot possibly be replaced with v6 multicast? If v4 exhaustion is the problem, just give these dual stack STBs an RFC 1918 address- it is after all, intradomain, and the v4 is only being used to receive these walled-garden v4 mcast streams. 4) Just use NAT &lt;willing suspension of disbelief&gt; OK, so for whatever reason, SPs must deploy v6-only STBs which must find a way to receive v4 mcast streams within a walled-garden that the SP totally controls, (and, of course, sending v4 streams to the v4-only receivers and v6 streams to the v6-only receivers is out of the question). Or better yet, v4-only STBs must find a way to get all that v6 mcast content. Why not simply throw NAT at this problem and be done? The solution could be characterized in a paragraph or 2. Do we really need a 19 page requirements doc, or the 6 other multrans docs we've seen so far? Or the flood of new drafts that seem likely follow? &lt;/willing suspension of disbelief&gt; _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Leonard Giuliano 2013-04-19T17:29:45 http://permalink.gmane.org/gmane.ietf.mboned/4079 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : IPv6 Multicast Address With Embedded IPv4 Multicast Address Author(s) : Mohamed Boucadair Jacni Qin Yiu L. Lee Stig Venaas Xing Li Mingwei Xu Filename : draft-ietf-mboned-64-multicast-address-format-05.txt Pages : 12 Date : 2013-04-18 Abstract: This document reserves one bit (M-bit) of the unicast prefix-based multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM mode to be used in the context of IPv4-IPv6 interconnection. The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> internet-drafts< at >ietf.org 2013-04-18T07:03:00 http://permalink.gmane.org/gmane.ietf.mboned/4078 <pre>I don't think I replied to this yet. I think the draft should go forward, assuming Stig's comments are resolved satisfactorily. On 21/03/2013 9:45 AM, Leonard Giuliano wrote: _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Tom Taylor 2013-04-11T14:32:13 http://permalink.gmane.org/gmane.ietf.mboned/4077 <pre>Hi Toerless, Sorry not to get back to you sooner, a bit time constrained at the moment. Thanks very much for your review and comments. ----- Original Message ----- That's good to know, I'd say it shows the idea is both feasible, useful and deployable. I found the following, which was a reasonable overview: http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/ps10325/white_paper_c11-577721.html Dale Carder also pointed off list that Aruba Networks do the same thing (under Dynamic Multicast Optimization): http://www.arubanetworks.com/vrd/80211nnetworksvrd/wwhelp/wwhimpl/common/html/wwhelp.htm#href=Chap4_AdaptRadioMgmt.html&amp;single=true I initially limited the topic to IPv6, because I knew IPv6 had the functions necessary i.e. MLDv2 and IPv6 ND NUD. That being said, Carston has since pointed out that RFC4861 says that NUD is only supposed to be done for unicast traffic, but not multicast traffic. That would be talking about layer 3 unicast vs layer 3 multicast. To accommodate the use of NUD for what is proposed here, RFC4861 would have to be slightly updated to apply NUD to link-layer unicast of layer 3 multicast. As for IPv4, that was something I was going to investigate. IGMPv3 would support this, the missing bit is an ARP equivalent of NUD. As far as I'm aware (although I haven't done much research yet), there is no RFC that specifies "ARP NUD". I have found that RFC1122 "2.3.2.1  ARP Cache Validation" does specify that Unicast polling of a neighbor using point-to-point ARPs can be use to check ARP cache entry validity. Also in passing I've noticed that Linux's implementation of ARP seems to use the states that it's IPv6 ND implementation uses, but I haven't yet verified that the behaviour is exactly the same. In other words, I think it is highly likely it can be applied to IPv4, but I wanted to see if "ARP NUD" was both permitted and also described somewhere. The follow on question is whether that description would have updated similarly to RFC4861. I've realised through the discussion over the last few days that I need to separate out and make more clear some of these points. This first version was mainly to "throw it at the wall and see if it sticks." The reason I though to use NUD to track the presence of the neighbors was that neighbor presence discovery is necessary to resolve the layer 2 information for the link-local MLDv2 source addresses, and NUD was tracking and verifying individual neighbors independently. By default, MLDv2 general queries are only sent around every 2 minutes, and there isn't any reliability for that and the responses, meaning that if a query isn't received due to packet loss, or any of the reports are lost due to packet loss, the next opportunity to discover continued listener presence is in around 2 minutes time. So in the case of a single packet being lost, that might mean traffic is being sent to a non-existent listener for up to 4 minutes, which I think is getting a bit too close to the typical 5 minute aging of learned MAC addresses in switches.  NUD will probe by default around every 30 seconds, and if it gets no response, will retransmit the probe around once a second. So it'd be much quicker and more reliable at detecting that the listener has disappeared than using MLDv2 General Queries. As MLDv2 General Queries are going to occur anyway, one optimisation that has occurred to me is that the corresponding reports from the listeners could be used as the evidence to Neighbor Discovery that the listener still exists, as a General Query and the corresponding reports are a two way transaction. The NUD probe could then be delayed for another 30 seconds. One drawback of this idea though would be that it would start roughly synchronising when NUD probes to all the listeners starts. So I think using NUD (perhaps with MLDv2 GQ/Report hints) would be a better mechanism to use to track listener presence. I'd think standards track due to the minor change required to RFC4861. I'm not sure what happens with IPv4, as I haven't found an RFC describing "ARP NUD". That's why I used "may". Link layer multicasts should be used when they're better than what I've described. However, when link-layer multicasts are not going to perform as well as replication and link-layer unicasts, or when some of the other differences of replication and link-layer unicast are beneficial (i.e., better data confidentiality, better battery life on mobile devices like tablets, smartphones etc.), then what is described could be used. The operating models were really just to highlight that not only could it be done on a per-group basis, but might also be useful to adopt for all groups on an interface, which may be a useful default model for an 802.11 interface. While I agree the doc is light on referenced evidence, I think it still describes the situation correctly, because I've done experiments of my own, and have seen bad multicast video over wifi, and have seen multicast traffic impact unicast performance.  I can't think of a situation when falling back to multicast after using replicated link-layer unicast would be useful. I consider what I've described to be an alternative to link-layer multicast, to be used when either it is either known or likely from the outset that link-layer multicast will be inadequate, or when replication and link-layer unicast provides some useful advantages over link-layer multicast. Falling back to link-layer multicast wouldn't solve the replication and link-layer unicast performance problems if they've occurred (otherwise, use multicast in the first place), or would eliminate the useful advantages that replication and link-layer unicast provided. I know it is possible to tune 802.11 to provide better multicast performance, however I understand that that tuning requires changing settings on all of the AP clients, as well as possibly on the AP, and if one new client which isn't tuned joins the link, performance drops back to before any tuning took place. This tuning would be beyond the capability of most residential home users. Another thought I've had is that as wired switches are doing this type of packet replication and effectively link-layer unicasting out their individual ports, perhaps in the future the hardware doing this could also be adapted to increase the performance of replication and link-layer unicasting over 802.11. This generally sounds to me to be above layer 3 (and the interface to layer 2) and be in the domain of either things like RSVP, or applications/protocols that already provide reliable multicast, mainly because I think it is necessary for the receiver to indicate to the sender success or failure of packet delivery. It could be done also be done on a link layer level, and I understand that 802.11 probably has enough mechanisms to be able to do this (e.g. acknowledgements and retransmissions). However, while 802.11 is the most likely use case for what I've described, I think there are benefits in keeping it generic, and applicable to any current or future link-layers which support both multicast and unicast transmission. For example, multicast over wired ethernet is (usually?) going to outperform replication and link-layer unicast (although, as a few people have pointed out off-list, switches are in effect doing replicating and link unicasting to emulate broadcast/multicast behaviour), however the other benefits may mean it is preferable to use what I've described instead of link-layer multicast. Thanks again. Best regards, Mark. _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Mark Smith 2013-04-08T21:30:10 http://permalink.gmane.org/gmane.ietf.mboned/4076 <pre>Hi Greg, - Section 4.1.4.2. is a good start and documents the challenges. However, there has been also the proposal from Gorry/me (sent in a private email) about adding a circuit breaker to the protocol. E.g., adding a protocol mechanism that allows relays to exchange some basic information such as x packet sent in the last second, so that the other end can detect if it has received less than x or x packets. - Section 4.2.2.4 looks rather incomplete as it basically only describes the IPv4 case. Is this intentionally? Martin On 04/01/2013 09:13 PM, Greg Bumgardner wrote: </pre> Martin Stiemerling 2013-04-08T11:04:53 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mboned