http://blog.gmane.org/gmane.ietf.nemo hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.nemo/8380 <pre>Hi Pete, On 5/20/13 4:29 PM, "Peter McCann" &lt;Peter.McCann&lt; at &gt;huawei.com&gt; wrote: Its fine. But, there is no data point to prove that one option is cheaper than the other... :) I don't want to re-open RFC-2804 discussions, at least for now and surely not in this WG. As I commented in OPSAWG some time back, I completely disagree with that document and IETF's past views on this topic. It surely needs a review to check its applicability and relevance for the current times. To me its a regulatory requirement that operators need to comply with, else they cannot deploy that service. Now, in the DMM context, it is relevant when we justify models based on such parameters such as cost ..etc. We cannot forget the key services and draw some random conclusions. BTW, the cost argument may turn out to be trueŠbut we have insufficient data here. Better approach would be to consider both the options, but not make claims using "cost" as the driver. Any case, my entry into this discussion was more with a general comment. I'm not asking for any changes in the Reqs documentŠ Regards Sri </pre> Sri Gundavelli (sgundave 2013-05-21T01:21:45 http://permalink.gmane.org/gmane.ietf.nemo/8379 <pre>Hi, Sri, Sri Gundavelli (sgundave) wrote: Agree cost is not the only argument for local break-out. But it is an important one and I think it's appropriate to call it out in a requirements document. I meant a small number of subscribers. Besides, as far as I know RFC 2804 is still IETF consensus. Unless you want to re-open the Raven discussions, we should not even be considering LI requirements in our work in IETF, let alone allowing them to drive us to an architecture that is grossly inefficient. -Pete &gt;&gt;&gt;&gt;&gt;&gt; </pre> Peter McCann 2013-05-20T23:29:05 http://permalink.gmane.org/gmane.ietf.nemo/8378 <pre> Macro spectrum overload I though is a bigger consideration and off course the use of cheaper access ..But, any ways as I'm saying split model is fine and will be a dominant model. Sri On 5/20/13 12:24 AM, "Alper Yegin" &lt;alper.yegin&lt; at &gt;yegin.org&gt; wrote: </pre> Sri Gundavelli (sgundave 2013-05-20T17:29:53 http://permalink.gmane.org/gmane.ietf.nemo/8377 <pre>Pete, I'm not suggesting that. Split model, with partial subset of the flows going through a central anchor and part of the other traffic breaking out locally is fine. My comment is not tie "cost" as the only argument for enabling LBO models. Its a deployment consideration that drives that decision. It may be about the availability of internet peering points, or many other considerations. You mean small set of subscribers, or small portion of a subscriber traffic. ? If its later, I assumed the Communication Content (CC) for intercept (in general) is HTTP+SMTP traffic which in most cases maps to 100% of the subscriber traffic. Sri On 5/17/13 6:04 AM, "Peter McCann" &lt;Peter.McCann&lt; at &gt;huawei.com&gt; wrote: </pre> Sri Gundavelli (sgundave 2013-05-20T17:27:26 http://permalink.gmane.org/gmane.ietf.nemo/8376 <pre> On May 17, 2013, at 8:42 AM, Sri Gundavelli (sgundave) wrote: If that were the case, then the operators wouldn't be offloading the subscriber IP traffic from WiFi to Internet. Alper &gt; </pre> Alper Yegin 2013-05-20T07:24:41 http://permalink.gmane.org/gmane.ietf.nemo/8375 <pre>The original comment was on "resources" in the problem statement PS3: How about revising PS3 to the following without comparing resources: PS3: Low scalability of centralized tunnel management and mobility context maintenance Setting up tunnels through a central anchor and maintaining mobility context for each MN in a centralized design increase the processing at the anchor as the number of MNs increases. Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities with proper signaling protocol design can increase scalability. H Anthony Chan -----Original Message----- From: dmm-bounces&lt; at &gt;ietf.org [mailto:dmm-bounces&lt; at &gt;ietf.org] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO) Sent: Friday, May 17, 2013 9:24 AM To: Peter McCann Cc: dmm&lt; at &gt;ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Very much agreed. Also, distributed solutions can be concentrated as deployment needs dictate using layer 2 means, as is done often in many present networks. can't do the opposite with centralized solutions without a whole lot of acrobatics. "J" Kim AT&amp;T Labs - Research http://sites.google.com/site/macsbug/ On May 17, 2013, at 9:04 AM, Peter McCann wrote: _______________________________________________ dmm mailing list dmm&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dmm </pre> h chan 2013-05-18T04:47:28 http://permalink.gmane.org/gmane.ietf.nemo/8374 <pre>The original comment was on "resources" in the following problem statement: PS3: Low scalability of centralized tunnel management and mobility context maintenance Setting up tunnels through a central anchor and maintaining mobility context for each MN therein requires more resources in a centralized design, thus reducing scalability. Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities can increase scalability. How about revising PS3 to the following and comparing resources: PS3: Low scalability of centralized tunnel management and mobility context maintenance Setting up tunnels through a central anchor and maintaining mobility context for each MN in a centralized design increase the processing at the anchor as the number of MNs increases. Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities with proper signaling protocol design can increase scalability. H Anthony Chan -----Original Message----- From: dmm-bounces&lt; at &gt;ietf.org [mailto:dmm-bounces&lt; at &gt;ietf.org] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO) Sent: Friday, May 17, 2013 9:24 AM To: Peter McCann Cc: dmm&lt; at &gt;ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Very much agreed. Also, distributed solutions can be concentrated as deployment needs dictate using layer 2 means, as is done often in many present networks. can't do the opposite with centralized solutions without a whole lot of acrobatics. "J" Kim AT&amp;T Labs - Research http://sites.google.com/site/macsbug/ On May 17, 2013, at 9:04 AM, Peter McCann wrote: _______________________________________________ dmm mailing list dmm&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dmm </pre> h chan 2013-05-17T21:07:12 http://permalink.gmane.org/gmane.ietf.nemo/8373 <pre>Very much agreed. Also, distributed solutions can be concentrated as deployment needs dictate using layer 2 means, as is done often in many present networks. can't do the opposite with centralized solutions without a whole lot of acrobatics. "J" Kim AT&amp;T Labs - Research http://sites.google.com/site/macsbug/ On May 17, 2013, at 9:04 AM, Peter McCann wrote: </pre> KIM, BYOUNG-JO J (BYOUNG-JO 2013-05-17T14:23:42 http://permalink.gmane.org/gmane.ietf.nemo/8372 <pre>We shouldn't require all the traffic to pay the price of centralization just because some small subset of the flow need it. LI should be a very small proportion of the traffic, and those flows can be directed to a collection point as needed. If you really need per-flow, per-application charging, you can send meta-information about the flows to a charging collection box. No need to send the flows themselves. -Pete Sri Gundavelli (sgundave) wrote: </pre> Peter McCann 2013-05-17T13:04:46 http://permalink.gmane.org/gmane.ietf.nemo/8371 <pre> Counter argument. It implies, LI, Charging, DPI Šetc on each of the distributed nodes. Implies more "CAPEX and OPEX" ? I'm not against distributed models and 6909 is the proof point. But, IMO, it will hard to draw relation to cost models, based on traffic exit points. You may need mobility hierarchy in the network for "n" number of reasons and a centralized models for "m" number of reasons. It more about deployment choice, dependent on many parameters. Sri On 4/29/13 5:29 AM, "Alper Yegin" &lt;alper.yegin&lt; at &gt;yegin.org&gt; wrote: </pre> Sri Gundavelli (sgundave 2013-05-17T05:42:40 http://permalink.gmane.org/gmane.ietf.nemo/8370 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : Requirements for Distributed Mobility Management Author(s) : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-04.txt Pages : 19 Date : 2013-05-07 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts< at >ietf.org 2013-05-08T06:13:30 http://permalink.gmane.org/gmane.ietf.nemo/8369 <pre> Folks, We have now got a number of reviews and specifically comments put into issue tracker. I am pleased to find out that the discussion on some of the posted comments has already started. The next thing is to solve the issues recorded in the issue tracker and close them one by one. Some of them are purely editorial. Some might need a bit more WG work. I encourage submitting intermediate version quite frequently once non-overlapping issues have been solved. That helps keeping track where we go. The faster we get the document updates done, the better.. obviously. - Jouni &amp; Julien On Apr 24, 2013, at 8:17 PM, Konstantinos Pentikousis &lt;k.pentikousis&lt; at &gt;huawei.com&gt; wrote: </pre> Jouni Korhonen 2013-05-02T08:56:25 http://permalink.gmane.org/gmane.ietf.nemo/8368 <pre>Hi Charlie, Honestly, I don't know whether how it would be a feature or not. But I know that the current multicast part is one of the requirements/considerations the DMM should take into account. Actually, we need to think of the reason why it is important. Existing approaches were a "patching-up" style that first, base multicast support design has been made on the reference protocol, then optimizations and extensions have been followed, thus leading to the unnecessities to the reference protocol and the inefficiencies to the network. I think this approach has been O.K. until now because IP mobility support itself and enhancement for unicast has been first. But now I believe we're in the slightly different stage when contemplating the ultimate goals and expected effects by the DMM. So, I think we need to consider the requirement reflecting such a concern at the initial stage. And current multicast requirement does not prevent to appear 'good proposals' but only provides the minimum guidelines of IP multicast deployment in the DMM we want to define. Best Regards, Seil -----Original Message----- From: Charles E. Perkins [mailto:charliep&lt; at &gt;computer.org] Sent: Saturday, April 27, 2013 1:13 AM To: Seil Jeon Cc: dmm&lt; at &gt;ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello Seil, You suggest that if a feature is not listed as a requirement, it cannot be considered during the evaluation of solution proposals. This is not true. Given the choice of two proposals, the one that meets the requirements and offers the best other features will invariably be chosen. The real danger is in disqualifying good proposals because they fail to offer some feature that should not have been made into a requirement. There is no harm in listing desirable features (like multicast) that would enhance the value of a solution that meets the requirements. Regards, Charlie P. On 4/26/2013 6:18 AM, Seil Jeon wrote: important, *required* -- Regards, Charlie P. </pre> Seil Jeon 2013-04-30T10:52:15 http://permalink.gmane.org/gmane.ietf.nemo/8367 <pre>Hi Charlie, No, it should be less. Distributed solution: Take IP traffic directly from access router to the Internet. Centralized solution: Take IP traffic from access router to a core router to the Internet. The latter suggests more CAPEX and OPEX. Alper On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote: </pre> Alper Yegin 2013-04-29T12:29:20 http://permalink.gmane.org/gmane.ietf.nemo/8366 <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. _______________________________________________ dmm mailing list dmm&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dmm </pre> johnsonhammond2< at >hushmail.com 2013-04-27T17:06:31 http://permalink.gmane.org/gmane.ietf.nemo/8365 <pre> Hello Alper, I agree with your point, but it means that the total cost of the distributed solution is even more expensive.... right? Regards, Charlie P. On 4/26/2013 12:56 AM, Alper Yegin wrote: </pre> Charles E. Perkins 2013-04-27T00:44:00 http://permalink.gmane.org/gmane.ietf.nemo/8364 <pre>Hello folks, Here are some editorial suggestions for the document. Check for missing articles. For instance: "Gateway selection mechanism" --&gt; "A gateway selection mechanism" "is also taking the" --&gt; "also takes" Delete "However" before "assigning". Delete "Issues such as" Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. "In particular, there is an increase in direct communications among peers in the same geographical area." --&gt; there has always been such locality... in fact maybe less now than previously. Otherwise, please provide a citation. Delete "While deploying" "today's mobile networks, service providers face" --&gt; "Today's mobile networks present service providers with" Delete "more often than not," Delete "Therefore it is not uncommon to observe that" "ever-increasing" --&gt; "unnecessary" "provided" --&gt; "managed" "non-optimal" --&gt; "unnecessary" Delete "Given this motivational background in this section," "address these problems": at this point in the document, the problems have not been identified. As suggested earlier, there should be a section devoted to listing the problems, and then a cross reference to that section could go here. "changing IP address" --&gt; "locator IP address" Insert "The" before "Gateway GPRS Support Node" "respectively, act" --&gt; "all act" "SAE" --&gt; "EPC" "closeby" --&gt; "nearby" Center figure 2. (and might as well center figure 1 too) "future flat IP-based" --&gt; "flat IP-based" (unwise to predict the future) "states the requirements as follows" --&gt; "identifies the following requirements" "Distributed deployment" --&gt; "Distributed processing" ... also in "REQ1" "of IP sessions" --&gt; "of some flows" "an optimal manner" --&gt; "to avoid known bottlenecks" "This requirement addresses problems PS1, PS2, PS3, and PS4 in the following." ... the following ?what? "each MN therein" .... the MNs are not "in" the tunnel, and they are not "in" the mobility anchor. "Centralized anchoring" --&gt; "Centralized anchoring designs" "Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities can increase scalability." --&gt; only when the signaling protocol is properly designed. "is to be inline" --&gt; "conforms" "may need to interoperate with a network or mobile hosts/ routers that do not support DMM protocols." ... this is technically infeasible. Suggested replacement: "may need to co-exist with a network or mobile hosts/ routers that do not support DMM protocols." Delete "The motivations of this requirement are" </pre> Charles E. Perkins 2013-04-27T00:19:22 http://permalink.gmane.org/gmane.ietf.nemo/8363 <pre>Hello Seil, You suggest that if a feature is not listed as a requirement, it cannot be considered during the evaluation of solution proposals. This is not true. Given the choice of two proposals, the one that meets the requirements and offers the best other features will invariably be chosen. The real danger is in disqualifying good proposals because they fail to offer some feature that should not have been made into a requirement. There is no harm in listing desirable features (like multicast) that would enhance the value of a solution that meets the requirements. Regards, Charlie P. On 4/26/2013 6:18 AM, Seil Jeon wrote: </pre> Charles E. Perkins 2013-04-27T00:13:26 http://permalink.gmane.org/gmane.ietf.nemo/8362 <pre>Hi Charles, Actually, in realizing DMM-based mobility management, as you know, they may exist various ways or more requirements for DMM protocol deign tackling the issues raised from CMM. Given the requirements defined in the document is confining, in their ways, explicitly or implicitly the protocol design for further steps. It means that proposed solutions should satisfy or consider the requirements, or they will not be DMM solution in DMM WG at least. If you see the mail posted by Sergio a few days ago, the multicast part title was changed with 'Multicast Considerations' for right meaning. With the meaning, I think it would go together with the other requirements. Have a look, please. Regards, Seil -----Original Message----- From: dmm-bounces&lt; at &gt;ietf.org [mailto:dmm-bounces&lt; at &gt;ietf.org] On Behalf Of Charles E. Perkins Sent: Thursday, April 25, 2013 1:24 AM To: dmm&lt; at &gt;ietf.org Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03 Hello again folks, I can't type in all the editorial suggestions right now, but at least I wanted to provide some overall comments that cause the document to seem quite inaccurate in many of its claims. Here are my general comments. - The requirements need to be distinguished from the desirable features. For instance, section 4.7 describes a desirable feature, not a requirement. Moreover, the desirable feature may be unattainable. This is important, because if feature is *required*, a solution not providing the *required* feature "must" be considered incomplete and rejected. </pre> Seil Jeon 2013-04-26T13:18:26 http://permalink.gmane.org/gmane.ietf.nemo/8361 <pre>Hi Charlie, This would be true for tasks that can be performed either on the distributed node or on the central node. But the essential task for DMM systems, IP forwarding, is not of that nature. In centralized architecture, that task needs to be performed *both* at the edge node and also at the central node (and in fact even in between) before the packets hit the Internet/mobile device. Alper </pre> Alper Yegin 2013-04-26T07:56:27 http://permalink.gmane.org/gmane.ietf.nemo/8360 <pre>Hello again folks, I can't type in all the editorial suggestions right now, but at least I wanted to provide some overall comments that cause the document to seem quite inaccurate in many of its claims. Here are my general comments. - The requirements need to be distinguished from the desirable features. For instance, section 4.7 describes a desirable feature, not a requirement. Moreover, the desirable feature may be unattainable. This is important, because if feature is *required*, a solution not providing the *required* feature "must" be considered incomplete and rejected. - The problem statement clauses should be located in an initial section. Each problem statement should have a motivation. - There is no problem statement supporting sections 4.4 or 4.6 - There is no motivation for section 4.4 - There is nothing specific to DMM in sections 4.4 or 4.6 - Section 5 should cross-reference section 4.6, and they should both be rewritten to eliminate redundant extra verbiage of which there is too much. - PS7 claims that deployment (of "something": existing IETF solutions?) is too complicated. Compared to what??? 3GPP solutions?? Dozens of incompatible clunky slow portal authentication design botches? This point strikes me as basically wrong, but it can be rescued if a target level of deployment complexity is described. - REQ3 claims that we should target IPv6 because of tools available for IPv6 that are not available for IPv4. Please identify at least one. - Section 1 claims that user traffic patterns have shifted to become more localized. This is probably false, but I can imagine several ways to change it so that it becomes true. It is important for this purpose to clarify what is intended by "peer communications". - What is an "IP session"? Wasn't IP supposed to be connectionless? I strongly suggest not trying to define such a thing. Perhaps it was intended to indicate a "flow" instead. - It is claimed that a centralized architecture requires more resources than a distributed architecture. This is usually false. For instance, if a centralized node requires 100 units, and 100 distributed nodes each require 1.03 units, the distributed architecture requires 3 more units overall. Even so, the additional expense of the distributed architecture would often be a bargain for reasons of redundancy, resiliency, etc. I will do the editorial suggestions tomorrow. Also I can volunteer to rewrite various parts if extra effort is needed. Regards, Charlie P. On 4/24/2013 2:14 PM, Charles E. Perkins wrote: </pre> Charles E. Perkins 2013-04-25T00:24:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.nemo