Last Call Review of draft-ietf-v6ops-siit-dc-02

Request Review of draft-ietf-v6ops-siit-dc
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-09-22
Requested 2015-09-11
Authors Tore Anderson
Draft last updated 2015-09-17
Completed reviews Genart Last Call review of -02 by Christer Holmberg (diff)
Secdir Last Call review of -02 by Tobias Gondrom (diff)
Opsdir Last Call review of -02 by Qin Wu (diff)
Assignment Reviewer Qin Wu
State Completed
Review review-ietf-v6ops-siit-dc-02-opsdir-lc-wu-2015-09-17
Reviewed rev. 02 (document currently at 03)
Review result Ready
Review completed: 2015-09-17


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


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.



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



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






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

   desirable to avoid requiring the use of IPv4-translatable IPv6




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



Qin WU