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

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

Review
review-ietf-v6ops-siit-dc-02-opsdir-lc-wu-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
 (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