Softwire Problem Statement
draft-ietf-softwire-problem-statement-03

[Ballot comment]
I propose a rewrite of the Abstract:
  >
  > This document captures the problem statement for the Softwires
  > Working Group, which is developing standards for the discovery,
  > control, and encapsulation methods for connecting IPv4 networks
  > across IPv6-only networks as well as IPv6 networks across IPv4-only
  > networks.  The standards will encourage multiple, inter-operable
  > vendor implementations by identifying, and extending where
  > necessary, existing standard protocols to resolve a selected set
  > of "IPv4/IPv6" and "IPv6/IPv4" transition problems.  This document
  > describes the specific problems ("Hubs and Spokes" and "Mesh") that
  > will be solved by the standards developed by the Softwires Working
  > Group.  Some requirements (and non-requirements) are also identified
  > to better describe the specific problem scope.

  The bulk of the Abstract also appears as in the Introduction, and I
  suggest that similar changes be made to the Introduction.

  Section 1 says:
  >
  > Softwires are assumed to be non-ephemeral in nature.
  >
  s/non-ephemeral/long-lived/

  I find the use of "Case X:" and "Figure X: Case X" in adjacent
  paragraphs confusing.  Wouldn't it be cleaner to have a multi-line
  figure caption?

[Ballot discuss]
1. Section 2.13 and 3.8:

Other encapsulations, like IPv6/IPv6 or
  IPv4/IPv4, are nice to have but not on the critical path.

Why is this type of encapsulation at all discussed in the document. It seems totally unnecessary for the described problem and not part of the charter.

2. On the following issues I am missing them listed as something that needs to be addressed by the softwire solution.

a. Explanation necessary on softwire protocols relation to other host mechanisms in the same layer of the network stack. Examples of mechanisms to consider are tunneling mechanisms, VPNs, mobility (SHIM6)

b. The issue of operational brittelness introduced by softwire also needs to be documented in solution specs and should be included in the problem description. Single point of failure and difficulties to deploy redundant systems seems to be one issue to consider.

c. Effects of softwires on the transport layer. Issue like packet losses, congestion control and handling of QoS reservation and usage of on-path protocols such as RSVP.

[Ballot discuss]
1. Section 2.13:

Other encapsulations, like IPv6/IPv6 or
  IPv4/IPv4, are nice to have but not on the critical path.

Why is this type of encapsulation at all discussed in the document. It seems totally unnecessary for the described problem and not in charter.

2. Missing discussion on the issue in which relation softwires have in the host stack in relation to other tunneling, VPN, and mobility mechanisms.

3. The issue of operational brittelness introduced by softwire also needs to be documented in solution specs and should be included in the problem description. Single point of failure and difficulties to deploy redundant systems seems to be one issue to consider.

[Ballot discuss]
Section 2.13:

Other encapsulations, like IPv6/IPv6 or
  IPv4/IPv4, are nice to have but not on the critical path.

Why is this type of encapsulation at all discussed in the document. It seems totally unnecessary for the described problem and not in charter.

[Ballot discuss]
The document says in section '2.  Hubs and Spokes Problem':

In some applications, manually configured tunnels (as described in
[RFC4213] are sufficient as a transition mechanism.  For a variety of
reasons (for example, use of dynamic IP addresses, and NAT
traversal), other solutions are also necessary.

This text needs to be expanded if this document wants to serve as a problem statement document.
Now it is evading the issues of the actual problem by handwaving them away as the softwires
working group was supposedly specifically needed because of issues with NAT and dynamic IP addresses in the first place. At the minumum it needs a forward reference to the appropriate sections later in this document.

The document says in section '2.3.  Network Address Translation (NAT) and Port Address Translation
      (PAT)':

If the NAT is not in the home gateway, but in carrier equipment
located at the other end of the access link (typically in an carrier
POP), support for NAT traversal is still required.

This is a ridiculous assumption. The best advice is to get the carrier to change to public
IP addresses. There is no reason to engineer for such broken setups.

In section '2.4.  Static Prefix Delegation':

An important characteristic of this problem in IPv4 networks is that
the carrier-facing CPE IP address is typically dynamically assigned.
Also, if the softwire has to be established from a node behind a CPE
router, that node IP address can also be dynamically assigned.

This scenario is fixed adequately by 6to4. Why is this still considered to be a problem ?
Did you perhaps missed to add something about CPE equipment that is addressed with
dynamically assigned private addresses ?

In section '2.8.  Scaling':

DNS redirection and/or local anycast
addresses among other choices, coupled with the (to-be-determined)
softwire concentrator discovery solution will enable sharing the load
among concentrators.

This is proposing a solution, while this is a problem statement document.

In section '2.10.  Multicast'

Existing multicast solutions can be used over the softwire.

What solutions ? Or did you try to say something else like
'softwire should support multicast'.

[Ballot comment]
The document says in section '1.  Introduction':

Wide area networks that support one or both address families may
be separated by transit networks that do not support all address
families.  Softwire connectivity is necessary to establish global
reachability of both address families.

I have serious doubts whether the first sentence will ever be the case. The ease of deploying a native ipv6 network in the core is simply to easy, configured tunnels are not very hard either and
the chance that somebody stays customer of a transit provider that doesn't provide them the services
they actually need seems remote.

I seriously hope that the softwires working group is not interested in dealing with this
particular completely theoretical case.

[Ballot comment]
Often it is important to find the right concentrator as the choice in concentrator can impact the performance - particularly for things like VoIP. I'm  surprised to see requirements around ability to select the concentrator ruled out of scope for this document.

[Ballot comment]
Not a comment on this document per se, but on softwires as a WG (which
  I haven't followed much, so this may not make sense): Why isn't all of
  this doable with one of the VPN solutions we have standardized or are
  standardizing, with security turned off? All the routing,
  encapsulation, management, etc. mechanisms seem to be practically
  identical. Or is the idea that the solution to these requirements will
  be an "unsecured VPN?"


Section 1., paragraph 6:
>    o  The nodes that actually initiate softwires should support dual-
>      stack (IPv4 and IPv6) functionality.

  Why?


Section 2., paragraph 0:
>  2.  Hubs and Spokes Problem

  Is multihoming in- or out-of-scope, i.e., can the softwire initiator
  start multiple softwires to different concentrators?


Section 2., paragraph 4:
>    There are four variant cases of the Hubs and Spokes problem which are
>    shown in the following figures.

  In all four cases, the softwire transits an IPv4 network and connects
  to the IPv6 Internet. Abstract and introduction have stated that
  IPv4-over-IPv6 and IPv6-over-IPv4 are in scope. Aren't there four more
  cases missing below? Or is IPv4 over IPv6 out-of-scope for the
  hub-and-spoke case?


Section 9.2., paragraph 0:
>  9.2.  Informative References

  Should probably cite RFC4301 for IPsec.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

==> Me, Alain Durand. I'm shepherding this document as wg co-chair.
I do believe it is ready for forwarding to the IESG for
publication.



(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

==> The document has had adequate review from both key wg members and
key non wg members.
I have no concerns about the depth nor breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

==> I have no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.


==> I have no specific concerns about this document anymore.
The lastest issue to be resolved was how to list multiple editors
in the initial boiler plate and all the real authors in the
acknowledgement
section. This document is a problem statement and is the product
of a large number of wg participants. I consider that this issue
is now resolved.
but might need a minor twist in the 48 hour period.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

==> The consensus is fairly solid in the wg. The document has been
around for quite some time
as the basis for the wg work.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

==> Not to my knowledge.

(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

==> The document was generated with xml2rfc


(1.h) Has the document split its references into normative and
informative?

==> Yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

==> No

If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

==> N/A