[Softwires] Re: WG LC Problem Statement

[Pekka Savola <[e-mail]>]

Hi,

I've re-read the problem statement.  Below are also those comments for 
the earlier version that didn't seem to be addressed but still seem 
applicable [1]).

I do not think the problem statement can go forward in its current 
form.  It clearly has not been read enough even by the co-authors as 
it has a number of typos, procedural omissions (failing ID-nits and so 
on) etc.  But I'm hopeful that these and the couple of substantial 
issues could be fixed in one or two revisions and the doc could go 
forward around the January timeframe.

substantial
-----------

[1] -- the issue with the assumption that the connected islands have 
just one address family (instead of being dual-stack) is serious and 
requires significant rewording.  The currently described problem is 
not the one described by CERNET.  The rest of the comments are at the 
end of this mail.

...

3.2.  Network Address Translation (NAT) and Port Address Translation
       (PAT)
...
    There is no requirement to be able to "autodetect" NAT or PAT
    presence during softwire setup.

==> I do not agree with this statement without further qualifiers. 
The softwire setup needs to work by default through a NAT, and the 
statement above does not really address that point.  Suggest replacing 
with:

    Establishing a softwire through NAT or PAT must work by default.
    However, there is no requirement for explicitly "autodetect"
    NAT or PAT presence during softwire setup.

I.e., unless the solution provides autodetection, it must be chosen in 
a manner that can traverse NAT/PAT.  I think that's a hard 
requirement.

.......

3.7.  Softwire Concentrator Discovery

    When the initiator of the softwire is a CPE, the IP address or DNS
    hostname of the softwire concentrator must be known.  The simplest
    way for this to be known by the CPE is for it to be configured by the
    user, or by the provider of the CPE in advance.  Alternatively, an
    automated discovery phase may be run in order to return the IP
    address(s), or hostname(s) of the concentrator.  The details of this
    discovery problem are outside the scope of this document.

==> The first "When the initiator of the softwire is a CPE," is not 
true and should be removed or reworded.  The same text applies 
(roughly) in all cases 1-3, though configuration is more difficult if 
the initiator is not CPE.  The text needs to be generalized.

    It should be noted that according to reports the islands do not want
    to achieve network connectivity via tunneled Layer 2 mechanisms but,
    as distinct Layer 3 or MPLS routers.  This clearly helps scaling and
    Layer 2 discovery performance issues.  It also prevents having to
    have fully meshed point to point Layer 2 connectivity between the
    nodes in differing islands as Layer 2 technology choice must be
    preserved.

==> while one network might want to use Layer 3 mechanism, I do not 
think Layer 2 should be ruled out as it's a more generic solution. 
We should provide a solution for that as well.

semi-editorial
--------------

==> in hub and spoke case 2 and case 3, isn't HGW typically v4-only 
(otherwise we'd be looking at case 1?), like follows:

                       +-------+   +-------------+  +--------+
                       |       |   | Softwire    |  | IPv6   |
    +-----+  +-----+   |  Pv4  |---| concentrator|--| Network|
    |Host |--| HGW |---|       |   +-------------+  +--------+
    +-----+  +-----+   |Network|
                       +-------+
            _ _ _ _ _ _ _ _ _ _ _ _
          ()_ _ _ _ _ _ _ _ _ _ _ _()
                    "softwire"
    |-------|-------------------||-------------------------|
     Dual          IPv4 only         IPv6 or dual stack
     stack

(however, it'd be possible for HGW be dual-stack but just not support 
setting up softwires..)

3.4.  Static Prefix Delegation

==> split the first paragraph in 2 or 3.

procedural issues
-----------------

==> it'd be appropriate to acknowledge the earlier problem statement 
work in this space -- at least draft-palet-v6tc-goals-tunneling-00, 
which includes references to even prior art.

==> a "null" IANA considerations section is needed.

==> the front page lists 6 authors.  This is more than the maximum 
limit (5).  I'd suggest just putting the editor on the front page.

7.  References

==> need splitting to norm/informative

==> the referred docs (e.g., Steve Bellovin's IPsec recommendations) 
need to be added as explicit recommendations here.


editorial
---------
==> spell out the terms when used the first time (at least, "ISP")

    multicast trafic.  They are also assumed to be non-ephemeral in
    nature thus, they are peristent or long-lived.  Last, the setup

==> s/trafic/traffic/
==> s/peristent/persistent/

    setup time of the CPE/Address Family Boundry Router (AFBR)

==> s/Boundry/Boundary/
==> missing "." at the end.

    Section 5).  The primary difference between these two problems are
    how many connections and associated routes are managed by each IPv4

==> s/are/is/

    number of well connected hubs and then deserve smaller airports

==> s/deserve/serve/

There are three cases refer to Hubs and Spokes problem
    which are shown in Diagram 1.

==> cannot parse "are three cases refer".  Missing "that" ?

    contentrator.  An ISP may deploy several concentrators (for example

==> s/content/concent/

    a keepalive mechanism MUST be define.  Such a mechanism is also

==> s/define/defined/

    Other OAM needed features include:

==> s/OAM needed/needed OAM/

    - Path failure detection)

==> remove ")" ? (both in section 3 and 4)

   differing address family type.  For an example, See Figure 1.  Note

==> it's figure 2.

    It should also be noted that the mesh problem can be treat as a

==> s/treat/treated/

    In contrast with the hub and spoke problem, routers are advertizing
    routers for relatively large islands, and never a single user so
    there is no "user authentication" necessary.

==> "routers are advertizing routers" and ", and never a single user" 
-- reword this sentence.

   IPv6/IPv4,IPv4/IPv6 and overlapping address space as defined in the

==> s/,/, /


==============
[[ earlier comments that still seem to be valid ]]

3.8.  Scaling

    In a hub and spoke model, an ISP MUST scale the solution to millions
    of softwire inititators by adding more hubs (i.e. softwire
    concentrator).

==> s/MUST scale/must be able to scale/ (we cannot give upper-case 
requirements on what the ISPs do, and even so, it's a bit 
inappropriate to use upper-case keywords in a requirements document)

    - End-point failure detection (must be encapsulated w/in the tunnel
    in the transmitting direction

==> please clarify what you mean after '(', it's not clear.

     Reference Diagram

                     ._._._._              ._._._._
                    |        |            |        |
                    |  V4    |            |  V4    |
                    |access  |            |access  |
                    |island  |            |island  |
                     ._._._._              ._._._._

==> I don't think this was the case we were talking about.  Shouldn't all the 
islands be dual-stack?  This is pretty important consideration -- the key point 
emerges when an island with protocol X would like talk to an island with 
protocol Y. (where an island could be the rest of the internet as well).

    The AFBR's are the only devices in the network that must be able to
    perform dual-stack operations and setup and encapsulate softwires in
    a mesh to the other islands.

==> s/network/ISP's network/ -- the CPEs should obviously be dual-stack, right, 
so those could set up tunnels if they wished to.

   It should be noted that according to reports the islands do not want
    to achieve network connectivity via tunneled Layer 2 mechanisms but,
    as distinct Layer 3 or MPLS routers.  This clearly helps scaling and
    Layer 2 discovery performance issues.

==> it isn't clear enough what this point means.
========================

_______________________________________________
Softwires mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/softwires