[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments: draft-savola-v6ops-transarch-01.txt

This draft can become useful, but needs more WG discussion and I suggest
we have that here and give Pekka input.  Document needs spell checker
for some wordsm, and sentence structure check.  Also to mahy cliches
used that convey no technical message to me as a reader.  I think the
document important but needs much more work here in the WG.

Specific Comments:

   Robustness is also essential: the mechanism and the architecture must
   be reliable and robust, to encourage the adoption.  Also, mechanisms
   must not be less robust than their IPv4 counterparts: quite the
   contrary.  It is highly desirable to aim for building the
   architecture which does not depend on known-unreliable components
   (for example, certain operational modes of IPv4 NAT's); otherwise,
   the whole architecture is easily deemed unreliable.

Confused on what is trying to be said regarding IPv4 counter parts?  How
can an IPv6/IPv4 transition mechanism have a counter part.  I get the
point but this needs word-smithing to tighten up the point for
robustness.  Also I don't think any mechanisms proposed in our history
rely on IPv4 parts that do not work well?

   In absence of a plan, the transition must be made so that the future
   transition options will not be end-ran, and only "safe" transitionary
   actions are executed.  For example, deploying dual-stack nodes with
   currently only IPv4 connectivity does not end-run any transitionary
   goals, but is an important step that must be done anyway.

Not sure what end-ran or end-run defines? 

What exactly does "safe transitonary actions" mean?

I am having a hard time parsing the point of this paragraph? 

     o Providing IPv6 connectivity
     o Protocol translation
     o Application-specific protocol interoperability (ie. ALG or proxy)

   Deployment models for IP nodes:
     o IPv4-only
     o Dual-stack with only IPv4 connectivity
     o Dual-stack w/ IPv4/6 connectivity
     o Dual-stack with only IPv6 connectivity
     o IPv6-only

   And services:
     o IPv4-only
     o Separate IPv4 and IPv6
     o IPv4/6
     o IPv6-only

Each of the above should be their own section with descriptions in depth
technically what they mean and imply to a transition architecture.
Bullets are simply not enough in this case for a document labeled with
the word "architecture" in it.  I am willing to help with this offline
as I can find the spare cycles.

   2.3. Transition Mechanism Deployment Considerations

   There are a few very important questions which must be addressed in
   the cases where a transition mechanism deployment is deemed
   necessary.  For example:

     o if I deploy IPv6-only service, whose burden is it to enable its
       use by all clients I wish to make it accessible to?

     o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6
       connectivity, whose burden is it to enable them to access all the
       services they want?

     o how much easier would it be to go for dual-stack approach

   The intuitive answer to both of these would appear to be: "if you
   really want to shoot yourself in the foot, do not blame the person
   who sold you the gun -- or at least get prepared for a big hospital

Could we get technical or architecture statements to replace the above
please :--)

  The desire to go straight to IPv6-only seems to be mainly caused by a
   dream of fast transition especially in some more evolved networks.
   However, this seems counter-productive.

Important.  My impression is the hot button for this draft is that nodes
and networks will best be served by dual IPv4 and IPv6 layers being
supported, not that the draft is against IPv6 applications being
deployed or IPv6 gradually becoming dominant for network operations over
time.  I think this point is very important to be clear on in this work.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6