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. 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.
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.
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.
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.
* 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".
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.
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.
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.
Editorial:
most sensitive problems
... most pressing? sensitive doesn't seem like the right word.
stateless solutions optimizes CPE-to-CPE
... optimize ...
Jari
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
