[Softwires] sa46t-as (draft-matsuhira-sa46t-as-00)
Hi all, FYI, Today, I submitted sa46t-as, Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing. http://tools.ietf.org/html/draft-matsuhira-sa46t-as-00.html Basically, this idea is the same as sa46t, and easily support IPv4 Address sharing function adding port number into the SA46T address. Please refer sa46t basic document. http://tools.ietf.org/html/draft-matsuhira-sa46t-spec-01 Servers with sa46t-as capability (can terminate sa46t-as tunneling) can share one IPv4 global address with up to about 65534 servers. Of course, Clients / subscriber can share one IPv4 global address by separating the range of the port number that can be used. Regards, Naoki Matsuhira ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
Dear Alain, all, In addition to the technical reasons mentioned in previous e-mails, I would like to raise that operational issues should be also taken into account for the provisioning of the DS-Lite AFTR reachability information. In particular, we are considering two levels of redirection: o The first level is national-wise is undertaken by the DHCP: a regional-specific FQDN will be returned; o The second level is done during the resolution of the regional- specific FQDN to redirect the customer to a regional CGN among a pool deployed regionally. Distinct operational teams are responsible for each of the above mentioned levels. A clear separation between the functional perimeter of each team is a sensitive task for the maintenance of the services we are running. In particular, regional teams will require to introduce new resources (e.g., new CGN devices) to meet an increase of customer base. The introduction of these new devices (addressing, redirection, etc.) is implemented locally. Having this regional separation provides flexibility to manage portions of network operated by dedicated teams. In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 14 octobre 2010 18:59 À : Softwires list Cc : Ralph Droms Objet : Re: [Softwires] DHCP option for DS-lite I went back to the other thread on this topic DHCPv6 AFTR name option is needed. The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS to achieve load balancing (where the DNS has some form of measurement of the current load of the system). They point at VoIP for a precedent in that space. I would like to offer several remarks: 1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time. There is no provision in the spec to regularly refresh this information. This means that whatever is configured is going to stay that way for possibly a very long time. 2) It is unclear that the load information that the DNS was using at the time of the resolution is a good indicator of what the load will be hours or days later. 3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin that can trivially be implemented in a DHCP server 4) If one follows that logic, the DNS redirection just add a round trip time for no benefits. 5) The analogy with VoIP does not hold here because the VoIP client can do the query just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes. I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect. - Alain. On Oct 12, 2010, at 12:00 PM, Alain Durand wrote: Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG. The -05 rev is getting de facto review now, but you'll need to determine WG consensus for the changes in the -05 rev. - Ralph If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
We've had a lot of discussion about how the FQDN might be used, perhaps in conjunction with the contents of other options, to provision a device with the IP address of ds-lite tunnel endpoint. I don't think I've seen formal I-D text that specifies, for example, the two levels of indirection mechanism you describe below. It would help the discussion a lot to have such a formal description of the use case and the specific mechanism that addresses that use case. - Ralph On Oct 18, 2010, at 11:06 AM 10/18/10, mohamed.boucad...@orange-ftgroup.com wrote: Dear Alain, all, In addition to the technical reasons mentioned in previous e-mails, I would like to raise that operational issues should be also taken into account for the provisioning of the DS-Lite AFTR reachability information. In particular, we are considering two levels of redirection: o The first level is national-wise is undertaken by the DHCP: a regional-specific FQDN will be returned; o The second level is done during the resolution of the regional- specific FQDN to redirect the customer to a regional CGN among a pool deployed regionally. Distinct operational teams are responsible for each of the above mentioned levels. A clear separation between the functional perimeter of each team is a sensitive task for the maintenance of the services we are running. In particular, regional teams will require to introduce new resources (e.g., new CGN devices) to meet an increase of customer base. The introduction of these new devices (addressing, redirection, etc.) is implemented locally. Having this regional separation provides flexibility to manage portions of network operated by dedicated teams. In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 14 octobre 2010 18:59 À : Softwires list Cc : Ralph Droms Objet : Re: [Softwires] DHCP option for DS-lite I went back to the other thread on this topic DHCPv6 AFTR name option is needed. The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS to achieve load balancing (where the DNS has some form of measurement of the current load of the system). They point at VoIP for a precedent in that space. I would like to offer several remarks: 1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time. There is no provision in the spec to regularly refresh this information. This means that whatever is configured is going to stay that way for possibly a very long time. 2) It is unclear that the load information that the DNS was using at the time of the resolution is a good indicator of what the load will be hours or days later. 3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin that can trivially be implemented in a DHCP server 4) If one follows that logic, the DNS redirection just add a round trip time for no benefits. 5) The analogy with VoIP does not hold here because the VoIP client can do the query just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes. I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect. - Alain. On Oct 12, 2010, at 12:00 PM, Alain Durand wrote: Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors
Re: [Softwires] DHCP option for DS-lite
On Oct 18, 2010, at 8:06 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: In addition to the technical reasons mentioned in previous e-mails, I I'm sorry, I must have missed that email. I saw a lot of talk about how the WG consensus was for the FQDN option, and the IESG ought to respect that, and the DHCwg ought not to have a say in it. I saw some accusations about abuse of power (for the record, I have none, other than my ability to try to get the process to be followed, which it was not for this draft). But I didn't see a *single* technical reason given for your position. Unless DHCP won't work for us is a technical reason. Distinct operational teams are responsible for each of the above mentioned levels. A clear separation between the functional perimeter of each team is a sensitive task for the maintenance of the services we are running. In particular, regional teams will require to introduce new resources (e.g., new CGN devices) to meet an increase of customer base. The introduction of these new devices (addressing, redirection, etc.) is implemented locally. Having this regional separation provides flexibility to manage portions of network operated by dedicated teams. Okay, I can dig that. In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. See, this is the disconnect. Are you trying to suggest that this statement logically follows the previous paragraph's description of your circumstances? Or was that just a non-sequitur? Because I don't see any logical connection between these two statements. It seems to me that you are saying that the DNS will be under the control of this regional team, and the DHCP server is not. So the regional team is the only team that can make changes to the DNS. But since the DHCP server will be looking the name up in the DNS, this is a non-problem. Whether the DHCP server provides an FQDN or an IP address, the source for the IP address the client eventually uses will _always_ be the DNS. So the regional team will not have a problem updating that information. Furthermore, even if it were the case that the regional team couldn't do what you want, is that any justification for the position you've taken? I don't think it is, because it's an operational issue specific to your organization. We can't design protocols to suit your organization. Obviously we'd like to have the flexibility to address your needs, but as far as I can tell, we *have* that flexibility. And you haven't given any technical explanation for why we don't. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Call for agenda items
Hi Alain and Dave, My we request a time slot for the below work? https://datatracker.ietf.org/doc/draft-tsou-softwire-gwinit-6rd/ Time: 15 mins Presenter: Tina Tsou Thanks. Have a nice week. Best Regards, Qi, Cathy, Tom and Tina http://tinatsou.weebly.com/contact.html -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Alain Durand Sent: Thursday, October 14, 2010 4:32 PM To: Softwires list Subject: [Softwires] Call for agenda items This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ 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] [v4tov6transition] Comment on draft-despres-softwire-6a44-01.txt
Hi Brain, Brian E Carpenter 2010-10-16 Wrote: On 2010-10-16 15:15, Dong Zhang wrote: Hi Remi, Please see inline. ... Is the A:W-N:Z mapping created staticly? Or dynimicly? Dynamically when the 6a44-C starts operation. It then remains static until the 6a44 client or the NAT is reset. That is say it is similar to a kind of permanent state once the mapping is created, supposing that there no NAT reboot and power off. Right? If so, the interruption issue of CPE should be considered. 6a44 still needs to guarantee the state recovery, right? Why? When I have to restart my IPv4-only ADSL box, I lose all sessions, and for all I know I get a different IPv4 address. So why do I care if 6a44 loses state too? Certainly the IPv6 client host must be forced to restart the 6a44 process when this happens. We do need a method of forcing that. Yes, this is what I mean. If the client still uses the old 6a44 address after ADSL restart, 6a44 will not work. So the host should realize the restart of ADSL box. Thanks. Brian -- Dong Zhang 2010-10-19 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Softwire Mesh Multicast
A new version of I-D, draft-xu-softwire-mesh-multicast-00.txt has been submitted (http://tools.ietf.org/html/draft-xu-softwire-mesh-multicast-00). Your comments are appreciated. Abstract: The Internet will need to support IPv4 and IPv6 packets. Both address families and their attendent protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution for supporting E-IP unicast and multicast across an I-IP backbone. This document describes the mechanisms for suppporting Internet -style multicast across a set of E-IP and I-IP networks supporting softwires mesh. Mingwei ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
