Re: [Softwires] Re: WG LC Problem Statement (Pekka Savola Comments)

Still working through the comment backlog...

Spencer

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

Just so I'm sure I'm following you, we're still assuming that only one AF is 
being tunneled, right?

> 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 with this change. If others do not agree, please let me know (and we 
can discuss it).

> 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 with this change and plan to simply remove the identified phrase.

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

I agree with the thought but am having a hard time reading this into the 
Softwires charter (which seems pretty clearly focused on Layer 3). 
David/Alain, could you express an opinion here?

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

I understand the diagram and think I understand what to do with the 
document. Are you looking for more than a note that says "However ... " on 
your parenthetical comment?

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

Agree...

> procedural issues
> -----------------

Agree with all the following...

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

Agree with these.

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

Agree.

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

Agree...

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

Agree - otherwise we're talking protocol translation, not tunneling.

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

Agree.

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

Agree, and I'm not sure whether this even needs to be mentioned - especially 
if it morphs into a "describe the Layer 2/Layer 3 tradeoffs" paragraph. Our 
charter is for a Layer 3 solution - do we need to say more than that? 

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www1.ietf.org/mailman/listinfo/softwires