Subject: [Softwires] Re: WG LC Problem Statement

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Dec 2005 09:45:27 +0200 (EET)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 22 Dec 2005 09:08:51 +0100

Hi Pekka,

Just a quick comment, I will review later on today all your comments (thanks
a lot for them !).

I provided a lot of inputs, including typos corrections, but for some reason
they were not applied. I sent them already to this list around 15 Oct., and
also did a new review a couple of days ago which is being proccessed right
now.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 22 Dec 2005 09:45:27 +0200 (EET)
> Para: "[email-masked]" <[email-masked]>
> Asunto: [Softwires] Re:  WG LC Problem Statement
> 
> Hi,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 25 Dec 2005 19:25:16 +0100

Hi Pekka, all,

See my comments below, in-line, need to check anyway with the rest of the
co-authors opinions.

Regards,
Jordi

> forward around the January timeframe.

The point is being considered as just one address family if any of the
network elements (end-to-end) is a single address family. From that
perspective, tunneling need to be done to traverse that element.

> a manner that can traverse NAT/PAT.  I think that's a hard

I agree on this, we may need to rework this a bit.

> the initiator is not CPE.  The text needs to be generalized.

I agree that will be much better to have some autodiscovery for the
softwire. We may keep this open in the sense that can be a choice for manual
configuration or auto-discovery. The issue is that in the charter we agreed
to keep this out for the time being.

We may include here also references to the existing work on this.

> We should provide a solution for that as well.

Agree, we may need to state for the HGW IPv4-only, but no softwire support.
Similarly could be the other case, so it will be IPv6-only, but no softwire
support.

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

Ok.

> procedural issues

Agree ;-)

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

Ok.

> limit (5).  I'd suggest just putting the editor on the front page.

We tried, but didn't succeed to make it automatically with XML.

> ==> need splitting to norm/informative

Ok.

> need to be added as explicit recommendations here.

Ok.

> editorial

Agree with the rest of the comments here.

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

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.