Ted, The use cases for manipulating the FQDN information are those that motivated the DS-Lite-Tunnel-Name AVP (as described in Section 5.2 of http://www.ietf.org/id/draft-ietf-softwire-dslite-radius-ext-00.txt), and are very similar to those that reflect massively deployed VoIP designs, as reminded by Hemant in http://www.ietf.org/mail-archive/web/softwires/current/msg01692.html.
We believe that AFTR (CGN) capabilities should be distributed as close to the customers as possible, not only for scalability, flexibility and performance reasons, but also to improve the overall availability of the DS-Lite service while dramatically facilitating DS-Lite management as briefly exposed in one of my previous e-mails. The latter can be achieved by using a FQDN option, in a very similar way to what is usually done in VoIP environments. This use case could be further elaborated in a specific draft, but I'm curious to know why the use of the FQDN option mandates yet another effort, while (1) The FQDN AVP has been documented in the RADIUS extensions for DS-Lite draft, and (2) This is a very common practice that has proven to be useful and efficient in VoIP environments, based upon what is documented in RFC3361. (Note that RFC3319 does not define only one domain name but A LIST OF FQDN for a SIP proxy). I'm sure you have already noticed the great similarity between the DS-Lite and VoIP contexts, as far as the NAT capabilities are concerned. In the managed VoIP deployment, SIP UA are provisioned with their outbound proxy (usually an SBC to name it). This device acts as a CGN for the VoIP traffic (signalling, NATing RTP flows, and other application-specific features such as THIG, etc.). In the context of DS-Lite, CPEs should be provided with the reachability information of the CGN that will handle all their IPv4- addressed traffic. This is not a matter of "suiting my organization", this is a use case that is considered valid by several WG members (http://www.ietf.org/ mail-archive/web/softwires/current/msg01698.html, http:// www.ietf.org/mail-archive/web/softwires/current/msg01692.html). And indeed, there used to be a WG consensus on supporting both options, as you rightfully recalled. Last but not least, I think the unnecessary aggressively of your comments jeopardizes the serenity of the discussion (in particular the tone and contents of your message http://www.ietf.org/mail-archive/web/softwires/current/msg01703.html were totally inappropriate, especially because you are a WG chair), and I would therefore appreciate a greater show of courtesy from your side. Med -----Message d'origine----- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : lundi 18 octobre 2010 17:22 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Softwires list Objet : 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. ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
