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