Re: [Softwires] Re: WG LC Problem Statement

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Pekka, all,

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

Regards,
Jordi




> De: Pekka Savola <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: Thu, 22 Dec 2005 09:45:27 +0200 (EET)
> Para: "[e-mail]" <[e-mail]>
> Asunto: [Softwires] Re:  WG LC Problem Statement
> 
> 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.

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.

> 
> ...
> 
> 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.

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

> 
> .......
> 
> 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.

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.

> 
>     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..)

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.

> 
> 3.4.  Static Prefix Delegation
> 
> ==> split the first paragraph in 2 or 3.

Ok.

> 
> 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.

Agree ;-)

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

Ok.

> 
> ==> 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.

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

> 
> 7.  References
> 
> ==> need splitting to norm/informative

Ok.

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

Ok.

> 
> 
> editorial
> ---------

Agree with the rest of the comments here.

> ==> 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




**********************************************
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.




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