On Tue, Jul 26, 2011 at 8:19 AM, Satoru Matsushima <[email protected]> wrote: > Hi Jari, > > Thank you for your comments. Please see inline: > > On 2011/07/23, at 10:36, Jari Arkko wrote: > >> I have reviewed this draft in preparation for discussions in the upcoming >> meeting. >> >> Thanks for writing this. In general, I agree with many of the points raised >> in the document. I do have a number of issues with the document as well, >> however. In some cases listed below, the document appears to be claiming a >> little bit too broad benefit where it should have argued for a specific >> difference between stateful and stateless solutions. Secondly, and more, >> seriously, I wish the document would contain a description of the actual >> trade-offs, including some of the issues that seem apparent in the stateless >> solution. > > Thanks, actually we had some trade-off explanation in previous version. But > due to focus more on the motivation, current version doesn't mention the > trade-off. Since the purpose of this document is to describe motivations, and > kick-off to develop stateless solution, the authors focus to motivation > otherwise analysis work. I agree that trade-off analysis is significant, but > it would be better to be another document outside of which the motivation > draft bears. > > >> To name some: >> >> - difficulty in supporting widely different numbers of ports that different >> users employ ("cookie-cutter") >> - operational impacts of having to make changes to port allocations for some >> users (does it change my addressing plan?) >> - port randomization >> >> Note: I'm not saying that these things are showstoppers for the the >> deployment of stateless solutions, but I think the document would come >> across are more balanced if it actually did consider both the negative and >> positive aspects. > > My thoughts for these question: > > (1) stateless solution is not exclusive with other solution in theory. CPE > can use statefull solution for such purpose. > (2) 4rd as for example, multiple mapping rule can be helpful to change port > allocation without address plan changing and renumbering. > (3) Port randomization still preserve host side. Restrict ports should be in > CPE. Appropriate NAT session filtering is helpful to avoid the issues of port > scan threats. (i.e., address and address-and-port dependent filtering) > > >> >> Finally, I think the document would benefit from describing differences >> between stateful solutions with dynamic mappings (traditional NAT44-like >> CGNs), network-based solutions with a static mappings, and approaches that >> are based on static/stateless mappings at the protocol level. Understanding >> the difference between these three I think is key to making a decision on >> moving ahead with stateless solutions work. > > As Remi pointed out, we couldn't assume any stateless solution in the > motivation draft. So again, I think that it would be better to be another > document to do it if we needed. > > Then, let me try to make technical discussion: > >> >> Technical: >> >>> Service providers need to consider >>> optimizing the form of packet processing when encapsulation is used. >>> Since existing header compression techniques are stateful, it is >>> expected that stateless solution minimize overhead introduced by the >>> solution. >>> >> >> I'm not sure I understand this. First off, both stateless and stateful >> solutions appear to be sending relatively static data from CPEs to the >> central network equipment (same source addresses etc). Is you argument that >> the stateless approach is even more static in this sense, and that this >> would be beneficial from the point of commonly used header compression >> tools? Can you be more specific about the exact differences between the two >> approaches in this case? >> >> FWIW, my experience is that fixed wireless solutions -- such as those >> involving a home access point communicating over 3G/LTE towards an operator >> network -- do not today use header compression as much as they theoretically >> could. I think we'll see more header compression deployment in coming years, >> and that would also provide an opportunity to push the right compression >> technology. >> > > Yes, it is not header compression technology itself. It is operational effort > to be by choosing translation method in tunneling network architecture, which > I meant that within same address-family communication. > >
Since i have seen 3G/LTE on a few of these related threads, i will state that it is unlikely that mobile wireless providers and the 3GPP/GSMA will adopt yet another tunneling protocol or user equipment modification. cb > >>> 3.1.4. No Additional Protocol for Port Control is Required >>> >>> The deployment of stateless solution does not require the deployment >>> of new dynamic signaling protocols to the end-user CPE in addition to >>> those already used. In particular, existing protocols (e.g., UPnP >>> IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. >> >> I think this point, while valid, needs some reformulation. As I can see: >> >> * A new protocol will be required between CPE and network equipment. The >> question is if this protocol needs both a data path and control path >> component or not. And its not clear to me how provisioning works, somehow >> the CPE needs to learn what port ranges to use. So _some_ amount of control >> protocols are needed. > > Thanks, we'll clarify it, and improve the text. > > >> >> * Stateless/full aspect does not seem to matter with regards to whether you >> can use existing protocols to talk to the closest NAT, whether its at the >> CPE or in the network. Where you need new protocols and new code is if (a) >> there are multiple layers of NATs, and e.g., the home NAT needs to talk to >> the service provider NAT or (b) security and resource model of the NAT >> changes from "I have all ports" to "I can only give you some ports". > > Agreed. But point (b), current NAT implementation already can control to port > range/number to force its port pool. As long as we utilize it, I don't think > we need new code to do (b). > > >> >>> 3.2.1. Preserve Current Practices >>> >>> >>> Service Providers require as much as possible to preserve the same >>> operations as for current IP networking environments. >>> >>> If stateless solutions are deployed, common practices are preserved. >>> In particular, the maintenance and operation of the network do not >>> require any additional constraints such as: path optimization >>> practices, enforcing traffic engineering policies, issues related to >>> traffic oscillation between stateful devices, load-balancing the >>> traffic or load sharing the traffic among egress/ingress points can >>> be used, etc. In particular: >>> >>> o anycast-based schemes can be used for load-balancing and >>> redundancy purposes. >>> >>> o asymmetric routing to/from the IPv4 Internet is natively supported >>> and no path-pinning mechanisms have to be additionally >>> implemented. >> >> I think the issues at the bottom are valid requirements. However, the >> general point seems a bit overstated, IMO. The network is changing. Both >> with stateless and stateful solutions. I would suggest reformulating this >> point to be more about the specific issues than the general point. > > I think we can clarify it. But I don't understand your point clearly. Can you > give some example about 'network changing'. > > >> >>> 3.2.5. Simplification of Qualification Procedures >> >> IMHO, this point is perhaps a little bit overstated as well. The general >> argument is that stateless mechanisms are simpler and therefore easier to >> test. I think the reality is that any solution involving major fraction of >> traffic from the ISP and involving significant multi-vendor interoperability >> requirements (CPE - network node) is something that I would like to test >> very, very carefully. And remember that this is not just TCP port forwarding >> to static port ranges per subscriber. Its UDP, too. And ICMP. And some >> provisioning mechanism so that CPEs learn what ranges they can use. > > Thanks, we'll revisit about it. In general, we usually try to keep current > procedure when we change something. From my tiny experience of deployment > stateless solution into any area, qualification procedure of these are > lightweight than statefull. > > >> >>> 3.3.2. No Organizational Impact >>> >>> Stateless solutions rely on IP-related techniques to share and to >>> deliver IPv4 packets over an IPv6 network. In particular, IPv4 >>> packets are delivered without any modification to their destination >>> CPE. As such there is a clear separation between the IP/transport >>> layers and the service layers; no service interference is to be >>> observed when a stateless solution is deployed. This clear >>> separation: >>> >>> Facilitates service evolution: Since the payload of IPv4 packets is >>> not altered in the path, services can evolve without requiring any >>> specific function in the Service Provider's network; >>> >>> Limits vendor dependency: The upgrade of value-added services does >>> not involve any particular action from vendors that provide >>> devices embedding the stateless IPv4/IPv6 interconnection >>> function. >>> >>> No service-related skills are required for network operators who >>> manage devices that embed the IPv4/IPv6 interconnection function: IP >>> teams can be in charge of these devices; there is a priori no need >>> to create a dedicated team to manage and to operate devices >>> embedding the stateless IPv4/IPv6 interconnection function. The >>> introduction of stateless capabilities in the network are unlikely >>> to degrade management costs. >> >> I think the point about less involvement between transport and service >> functions is a valid one. That being said, I think the introduction of >> either stateless or stateful solutions does have an organizational impact. >> For instance, now the capabilities and configuration of your CPE equipment >> are very relevant with respect to what you can deploy in the network side. >> >> I would suggest focusing on the specific point and not arguing the general >> point. > > Thanks, we'll revisit it. > > >> >> Editorial: >> >>> most sensitive problems >> >> ... most pressing? sensitive doesn't seem like the right word. >> >>> stateless solutions optimizes CPE-to-CPE >>> >> >> ... optimize ... >> >> Jari >> > > Thanks, > > cheers, > --satoru > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
