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

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.

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.

  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.

  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?