Re: [Softwires] Way forward with MAP-T and 4rd
I am no the author of two drafts, It should be more convinced that there is a scenario and PS about the motivation of the work. Thanks autho for publishing it quite recently, that would be more appropriate to discuss them during the coming IETF meeting before accept them. Otherwise IETF is going to invent the 2nd wheel for the same problem. thanks a lot -Hui 2012/9/25 Suresh Krishnan suresh.krish...@ericsson.com Hi all, During the softwire WG meeting at IETF84 a series of questions* to determine the preferred solution in the meeting room indicated that the sense of the room was in favor of MAP-E as the basis for the proposed standard stateless solution. There was also general agreement in the room to continue working on MAP-T and 4rd as experimental/informational specifications. After the meeting, there has also been some uncertainty as to the order in which the different drafts would progress from the wg, This call is being initiated to confirm two things: a) whether there is WG consensus towards continuing working on MAP-T and 4rd as experimental documents. b) whether there is WG consensus that MAP-E should be progressed to working group last call IESG review before MAP-T and 4rd.** Please state whether or not you're in favor of each of these decisions by replying to this email. If you are not in favor, please also (re)state your objections in your response. The call will complete at midnight EDT on 2012-10-05. Regards Suresh Yong * Questions are available at http://www.ietf.org/proceedings/84/slides/slides-84-softwire-15.pdf ** Note that work on MAP-T and 4rd can proceed in parallel with MAP-E and we are not aiming to freeze work on these drafts. They just will not be progressed from the WG before MAP-E is progressed. This is to ensure that the drafts do not end up competing for the available (finite) review cycles. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Way forward with MAP-T and 4rd
Hi, I'm in favor of both a) and b). cheers, --satoru On 2012/09/25, at 13:45, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi all, During the softwire WG meeting at IETF84 a series of questions* to determine the preferred solution in the meeting room indicated that the sense of the room was in favor of MAP-E as the basis for the proposed standard stateless solution. There was also general agreement in the room to continue working on MAP-T and 4rd as experimental/informational specifications. After the meeting, there has also been some uncertainty as to the order in which the different drafts would progress from the wg, This call is being initiated to confirm two things: a) whether there is WG consensus towards continuing working on MAP-T and 4rd as experimental documents. b) whether there is WG consensus that MAP-E should be progressed to working group last call IESG review before MAP-T and 4rd.** Please state whether or not you're in favor of each of these decisions by replying to this email. If you are not in favor, please also (re)state your objections in your response. The call will complete at midnight EDT on 2012-10-05. Regards Suresh Yong * Questions are available at http://www.ietf.org/proceedings/84/slides/slides-84-softwire-15.pdf ** Note that work on MAP-T and 4rd can proceed in parallel with MAP-E and we are not aiming to freeze work on these drafts. They just will not be progressed from the WG before MAP-E is progressed. This is to ensure that the drafts do not end up competing for the available (finite) review cycles. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med: What about this change? OLD: anycast-based schemes can be used for load-balancing and redundancy purposes. NEW: anycast-based schemes can be used for load-balancing and redundancy purposes between nodes embedding the Stateless IPv4/IPv6 interconnection function. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Med: We added this section because we received comments asking for having a section listing the main limitations(?) stateless solutions. It was a fair comment. Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Thank you for the prompt followup. Taking things out of order, if the Discussion section were called Limitations, I would have understood why it was there. It is not clear to me that the content actually describes limitations though. It describes design choices that need to be made in specifying and deploying statelessv4v6 solutions. On the packet preservation description text in section 3.3.2, I am not sure what assumptions the document makes. For good and appropriate reasons, the document does not describe. I believe tat the ability to avoid ALGs is dependent upon more specific choices of solution, beyond merely the stateless property. Would it be acceptable to weaken the statement in the document to one that notes that stateless solutions admit the possibility of solutions which do not require ALGs? And that such avoidance is highly desirable? Yours, Joel On 10/5/2012 11:38 AM, mohamed.boucad...@orange.com wrote: Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med: What about this change? OLD: anycast-based schemes can be used for load-balancing and redundancy purposes. NEW: anycast-based schemes can be used for load-balancing and redundancy purposes between nodes embedding the Stateless IPv4/IPv6 interconnection function. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Med: We added this section because we received comments asking for having a section listing the main limitations(?) stateless solutions. It was a fair comment. Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Way forward with MAP-T and 4rd
Hi Suresh, Thanks for clarifying. I am in support of both a and b. Regards, Behcet On Thu, Oct 4, 2012 at 8:16 PM, Suresh Krishnan suresh.krish...@ericsson.com wrote: Hi Behcet, On 10/04/2012 11:53 AM, Behcet Sarikaya wrote: Dear Chairs, I think that your call needs some clarification. First of all, there is no active document that describes MAP-T. Correct. There is no such draft yet. The idea is to split out the MAP-T pieces of the MAP draft into a separate draft if the wg is in favor of continuing work on MAP-T. I checked Roberta's draft, draft-maglione-softwire-map-t-scenarios-00.txt, she gives no references. Is the intention of this call to put all of MAP-E, MAP-T and 4rd into equal weighting so that the decision can somehow be revisited? No. Not at all. On the contrary we are going with MAP-E as the proposed standard solution. This call is to decide what we want to do with the other two solutions. My experience with CAPWAP protocol selection that we did in 2006 is that WG continued to work on the selected protocol and developed extensions, MIB, etc. The other candidates became experimental with not much work on them. MAP-T and 4rd will be progressed as experimental if the wg is in favor of continued work on them. Thanks Suresh ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
