Re: [Softwires] DS-lite update
Dear all, I have just read the new DS-Lite version and I have the following comments for Section 8: (1) 8.2. NAT conformance A dual-stack lite AFTR SHOULD implement behavior conforming to the best current practice, currently documented in [RFC4787] and [RFC5382]. Other discusions about carrier-grade NATs can be found in [I-D.nishitani-cgn]. * This text should be updated to something like: a DS-Lite AFTR MUST follow the requirements specified in [I-D.ietf-behave-lsn-requirements]. * In addition, [I-D.ietf-behave-lsn-requirements] is to be listed as a normative reference. (2) Section 8.3. Application Level Gateways (ALG) is to be removed since this can be covered in [I-D.ietf-behave-lsn-requirements]. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 3 mars 2011 16:50 À : Jari Arkko; Ralph Droms Cc : softwires@ietf.org list; Yong Cui Objet : [Softwires] DS-lite update Dear ADs, New rev of the them main DS-lite doc (draft-ietf-softwire-dual-stack-lite-07) and the DHCP tunnel option (draft-ietf-softwire-ds-lite-tunnel-option-09) have been published. I believe they address all remaining comments. This should enable to restart the IESG process. - Alain. ___ 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] Fwd: Call for presentation - 4rd
Hello, Alain, Yong, As yo noted, authors of the 4rd draft included the word Intarea in the file name of this 4rd draft. This was intended only as a hint that the draft might be presented there if not presented in Softwires (a previous version had been listed out of scope in Softwire). Yet, all of us are still convinced that Softwire remains the natural WG for 4rd in view of its charter. Brian Carpenter and Mark Townsley in particular expressed recently the same understanding. Since Intarea won't anyway be a good place to present such a solution document, please be sure that no danger of duplicate presentation exists if, as we expect, the requested Softwire slot for 4rd is confirmed. Best regards, RD Début du message réexpédié : De : Ole Troan otr...@employees.org Date : 16 mars 2011 10:35:07 HNEC À : Alain Durand adur...@juniper.net, Yong Cui cuiy...@tsinghua.edu.cn Cc : softwires@ietf.org list softwires@ietf.org Objet : Rép : [Softwires] Call for presentation Chairs, my co-authors and I would to discuss 4rd: http://tools.ietf.org/html/draft-despres-intarea-4rd-01 IPv4 Residual Deployment across IPv6-Service networks (4rd) we could live with 5 minutes, but if you got 10 that would be appreciated and allow for some discussion. cheers, Ole On Mar 9, 2011, at 16:30 , Alain Durand wrote: If you are planing to present something in the softwire wg in Prague, please send agenda item requests to me and Yong by 3/16. We also need your slides Friday 3/25 (before the meeting starts). - Alain. ___ 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 mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02
Jim, to kick-start the discussion, could you outline the usage scenarios that would drive the requirements you mention below? Thanks, Frank -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Jim Guichard Sent: Tuesday, March 15, 2011 4:04 PM To: softwires@ietf.org Subject: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Authors, Some comments on this draft as follows that I would like to have discussed on this alias: * The draft is currently specific to point-to-point tunnels but I believe this needs to be extended to cover bi-directional tunnels and possibly point-to-multipoint tunnels also. * IP-in-MPLS tunneling is not covered in the draft and this is clearly necessary so that PW and RSVP-TE tunnels can be used. * The CID needs to be extended to allow for 20-bit transport label and the ability to stack labels below that (such as a VPN label). * The draft should allow for the CID to be signaled between the gateways and whatever software terminating device holds a specific service function. * Section 6 of the draft needs to define MPLS LSP so that PW and RSVP-TE are possible. ___ 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] DS-lite update
Comments like this one should really have been sent during the wg last call, long ago... That said, I tend to agree with Francis that MUST is too strong. As about ALG, I do not see what is wrong there. - Alain. On Mar 17, 2011, at 4:55 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear all, I have just read the new DS-Lite version and I have the following comments for Section 8: (1) 8.2. NAT conformance A dual-stack lite AFTR SHOULD implement behavior conforming to the best current practice, currently documented in [RFC4787] and [RFC5382]. Other discusions about carrier-grade NATs can be found in [I-D.nishitani-cgn]. * This text should be updated to something like: a DS-Lite AFTR MUST follow the requirements specified in [I-D.ietf-behave-lsn-requirements]. * In addition, [I-D.ietf-behave-lsn-requirements] is to be listed as a normative reference. (2) Section 8.3. Application Level Gateways (ALG) is to be removed since this can be covered in [I-D.ietf-behave-lsn-requirements]. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 3 mars 2011 16:50 À : Jari Arkko; Ralph Droms Cc : softwires@ietf.org list; Yong Cui Objet : [Softwires] DS-lite update Dear ADs, New rev of the them main DS-lite doc (draft-ietf-softwire-dual-stack-lite-07) and the DHCP tunnel option (draft-ietf-softwire-ds-lite-tunnel-option-09) have been published. I believe they address all remaining comments. This should enable to restart the IESG process. - Alain. ___ 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] fwd: New Version Notificationfordraft-guo-softwire-6rd-ipv6-config-02
-邮件原件- 发件人: Templin, Fred L [mailto:fred.l.temp...@boeing.com] 发送时间: 2011年3月18日 1:14 收件人: Xu Xiaohu; softwires@ietf.org 抄送: dh...@ietf.org 主题: RE: [Softwires] fwd: New Version Notificationfordraft-guo-softwire-6rd-ipv6-config-02 Hi Xiaohu, I'm just seeing this draft for the first time, and I noticed that it is asking the CE router to act as a combined DHCP client/relay. Sections 4.1 and 4.2.3.1 of the VET spec provide a detailed description of how to do that, and the same considerations apply to what you are trying to accomplish. Hi Fred, Thanks for this information. I will read your draft. When you start dealing with DHCPv6-allocated addresses and prefixes, however, you also have to consider how that will interact with the IPv6 routing system. For that, your CEs would either have to engage in a proactive dynamic IPv6 routing protocol (e.g., RIPng, OSPFv3, etc.) or somehow discover more-specific IPv6 routes on-demand of data traffic. Section 5.14 of the VET spec specifies a new on-demand dynamic IPv6 routing protocol based on redirection that applies to ISATAP and VET, but I think would also apply equally to your use case. This draft (draft-guo-softwire-6rd-ipv6-config-02) only discusses about how to support stateless DHCPv6 service in 6rd scenario. Hence, IMHO, a proactive dynamic IPv6 routing protocol is not needed. Did I misunderstand your point? One question about your draft. If the CE acting as a combined client/relay forwards a DHCP request to 6rd BR A (via the 6rd anycast address), what happens if subsequent DHCP renwals are directed to 6rd BR B? I don't think it is disasterous as long as the BR's communicate with each other, but you might want to say that somewhere. Since only the stateless DHCPv6 service is now considered in this draft, the synchronization among BRs is not required. Would this usage cause any concern? Best wishes, Xiaohu Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Xu Xiaohu Sent: Tuesday, March 15, 2011 7:12 PM To: softwires@ietf.org Cc: dh...@ietf.org Subject: [Softwires] fwd: New Version Notification fordraft-guo-softwire-6rd-ipv6-config-02 Hi all, An updated version of draft-guo-softwire-6rd-ipv6-config is available at http://tools.ietf.org/html/draft-guo-softwire-6rd-ipv6-config-02. Abstract: The 6rd [RFC5969] linktype does not support IPv6 link-local addressing, multicast and 6rd nodes are off-link from each other. The host configuration protocol DHCPv6 [RFC3315] relies on link-local addressing and multicast to function. This document specifies how DHCPv6 can be used across a 6rd link. Any comments are welcome. Best wishes, Xiaohu -邮件原件- 发件人: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org] 发送时间: 2011年3月14日 17:45 收件人: o...@cisco.com 抄送: guo...@huawei.com; x...@huawei.com; m...@townsley.net 主题: New Version Notification for draft-guo-softwire-6rd-ipv6-config-02 A new version of I-D, draft-guo-softwire-6rd-ipv6-config-02.txt has been successfully submitted by Ole Troan and posted to the IETF repository. Filename:draft-guo-softwire-6rd-ipv6-config Revision:02 Title: IPv6 Host Configuration in 6rd Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 5 Abstract: The 6rd [RFC5969] linktype does not support IPv6 link-local addressing, multicast and 6rd nodes are off-link from each other. The host configuration protocol DHCPv6 [RFC3315] relies on link-local addressing and multicast to function. This document specifies how DHCPv6 can be used across a 6rd link. The IETF Secretariat. ___ 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
