Re: [Softwires] Re: WG LC Problem Statement

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

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




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