http://permalink.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/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 </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</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. </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</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 th</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 http://permalink.gmane.org/gmane.ietf.mboned/4075 <pre>Martin, Any circuit-breaker mechanism should be described in its own draft, and not within this one. Gorry and I agreed in Orlando that a paragraph warning of non-CG traffic would be sufficient. I hope this view has not changed. Thanks, Greg On Apr 8, 2013, at 4:04 AM, Martin Stiemerling &lt;martin.stiemerling&lt; at &gt;neclab.eu&gt; wrote: _______________________________________________ MBONED mailing list MBONED&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/mboned </pre> Greg Shepherd (shep 2013-04-08T13:43:23 http://permalink.gmane.org/gmane.ietf.mboned/4074 <pre>Hi Greg, I will read through it until Friday evening. Thanks! Martin On 04/01/2013 09:13 PM, Greg Bumgardner wrote: </pre> Martin Stiemerling 2013-04-04T09:32:06 http://permalink.gmane.org/gmane.ietf.mboned/4073 <pre>Hi all, I was asked to review this draft and I have a few concerns with this draft... 1. I agree with most of the issues raised by Stig. Yes, many of them are nits, but they can cause non-deterministic interpretations of what should be done or what the actual problems may be. 2. I am concerned that some of the service requirements are conflating application-level requirements with network-level requirements. This document needs to be very careful to identify which layer needs to be concerned with which requirements. 3. Does *anyone* in the working group expect to have solutions for every use case described in section 3? Some of them should never be considered unless an operator says that is exactly how they want to build their network. 4. As a problem statement document, I think this draft goes too far in specifying *how* each of the scenarios is addressed. A problem statement should not specify any type of "Adaptation Function", that is part of a solution. It should stick to descr</pre> Brian Haberman 2013-04-04T00:46:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.mboned