Last Call Review of draft-ietf-v6ops-siit-dc-02
review-ietf-v6ops-siit-dc-02-opsdir-lc-wu-2015-09-17-00

I have reviewed draft-ietf-v6ops-siit-dc-02 as part of the Operational
directorate's ongoing effort to review all IETF

documents being processed by the IESG.  These comments were written

with the intent of improving the operational aspects of the IETF

drafts. Comments that are not addressed in last call may be included

in AD reviews during the IESG review.  Document editors and WG chairs

should treat these comments just like any other last call comments.



Short Summary

This document describes an IPv6 deployment model for the IDC operator's
services and applications which uses the Stateless IP/ICMP Translation(SIIT)
algorithm and Single Stack IPv6 Operation in an IPv6 Internet Data Centre
 (IDC).



It is well written, especially deployment consideration section which discusses
several issues encountered in the SIIT deployment and gives good suggestions to
address them. There are no operational or management concerns
 in this document. I believe it is ready for publication with tiny nits  and
 one general question as follows:



General question:

It looks this document and draft-ietf-v6ops-siit-dc-2xlat-01 are dependent two
documents and both documents discuss deployment considerations is there any
overlapping between two documents since both documents discuss
 how BR and ER are used together to work in the IPv6 environment in some cases?
 How do you look at this?



Section 1.2, 1st paragraph:

Section 1.2 said:

“

SIIT-DC does not keep any state between each

   packet in a single connection or flow.

”

s/between/on

Section 1.3, 2nd paragraph.

“

One example

   would be servers that are operating in a supporting/back-end role and

   only communicates with to  other servers (database servers, file

   servers, and so on).

”

s/with to/with



Section 4.1, 1st paragraph:

“

The ER provides the

   application or node with seemingly native IPv4 connectivity, by

   translating the packets (that were previously translated from IPv4 to

   IPv6) by the **BR** back to IPv4 before passing them to the

   IPv4-dependent application or node.

”

Who previously translate from IPv4 to IPv6, ER or BR?,

Secondly when saying

“

translating the packets by the BR

”

,By the BR back to IPv4 or by the ER back to IPv4?

Look at draft-ietf-v6ops-siit-dc-2xlat-01, I think the answer is the packet is
first translated from IPv4 to IPv6 by the ER, and then translated from IPv6 to
IPv4 by the BR, please make this clear in the text.





Section 4.9.3, 3rd paragraph

“

It may reduce its Path MTU value to exactly 1280, and in addition

      include a Fragmentation header in subsequent packets sent to that

      destination.  In other words, the IPv6 node will start emitting

      Atomic Fragments.  The Fragmentation header signals to the the BR

      that the Don't Fragment flag should be set to 0 in the resulting

      IPv4 packet, and it also provides the Identification value.



”

s/signals the the BR/signal the BR



Section 4.10,1st paragraph

OLD TEXT:

“

Section 2 I-D.ietf-v6ops-siit-eam  of [I-D.ietf-v6ops-siit-eam] discusses why
it is

   desirable to avoid requiring the use of IPv4-translatable IPv6

   addresses.



”

NEW TEXT:

“

Section 2 of [I-D.ietf-v6ops-siit-eam] discusses why it is

   desirable to avoid requiring the use of IPv4-translatable IPv6

   addresses.



”

Section 4.10, last paragraph

“

Avoiding such drawbacks is a

   design goal of SIIT-DC, cf.  Section 1.1, therefore the use of

   IPv4-translatable IPv6 Service Addresses is discouraged.



”

s/cf. Section 1.1/ as described in section 1.1



Regards!

Qin WU