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.
>> 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
