Re: [Softwires] DHCPv6 AFTR name option is needed
On Oct 14, 2010, at 1:13 AM, Maglione Roberta wrote: In the specific case being able to provide load-balancing and redundancy in DS-Lite scenario is a requirement for us, thus I would like to see a solution for this coming from IETF. So your requirement is to have load balancing, not to have DNS, correct? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Washam, Got it, thanks. Hemant -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Tuesday, October 12, 2010 9:20 PM To: Hemant Singh (shemant) Cc: mohamed.boucad...@orange-ftgroup.com; Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwires; Chairs Dhc; magli...@core3.amsl.com; Softwire Chairs; Ullio Mario Subject: Re: [Softwires] DHCPv6 AFTR name option is needed Hi Hemant, As I know, since 6rd BRs are stateless, so you can configure an anycast address for load balancing stuff. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Oct 12, 2010, at 11:49 PM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: If we adopt the sub-option scheme with the following values: 1AFTR IP Addres 2AFTR Name Mohamed, Roberta, you seem to have a very strong opinion that is based on the principle someone insists that we have this. I have to ask: what is your goal here? Is your goal to publish an RFC with your name on it that does what you want, even though probably no-one will implement it because it requires code changes to both the server and client? Or is it to get something that works, and can be used? If it's the former, then by all means, ignore our advice. If it's the latter, you might want to consider listening to the advice you're getting. The point of the advice is not to be authoritarian or arbitrary. It's to encourage you to write a spec that will be implemented and widely deployed, because it will require no code changes on DHCP servers or clients. David's suggestion to use suboptions wasn't necessary. You can use both FQDN and IP address, and just require that the client request both. The problem with this is that you gain nothing over just doing FQDN in this case, since the client must implement a resolver in case the server doesn't send the IP address option. I think you are driving very hard for a Pyrrhic victory. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Wed, Oct 13, 2010 at 08:49:47AM +0200, mohamed.boucad...@orange-ftgroup.com wrote: Thank you for this clarification. I think you may have misunderstood - I did not mean that the IESG's main complaint was with the complex normative requirements, I meant that this would be a fair way (I hope) to assess the motivations that inspire the complaint. The direction was pretty clear that we needed to drop one of the two formats. Alias options are not technically impossible. I can point to a few RFC's that describe options with partially overlapping or completely aliased configuration state - just providing different formats. They are IETF improbable because of the complexity required in their implementation - collectively, we are wary that people will actually follow the (important) directions we include in our protocols, or that we'll even be able to write appropriate directions to begin with. I don't see a way to retain the two formats without also requiring the complex normative requirements (on operators writing their configurations!) as we did in -04. it is not advisable to group options that may not be requested at the same time by the same client under an encapsulated space. Which is not the case of the aftr option. Sub-options are more of a way to encode multiple configuration values of variable length, wherein if the client requests one of the options it is a given the client must also receive the others in order to work. I can't think of an example of this off the top of my head. But the crux of it is that the server will reply with the entire encapsulated space. This isn't really a problem tho, particularly in DHCPv6, because it's just a space optimization issue. It also doesn't work around the problem of client implementation of the different formats. We would still have to require that one of the formats always appears from the server (the simplest, the address option), that the client always supports the simplest option and at its option implements the other formats, and then we'd still wind up with the situation where the client gets the IPv6 address of its AFTR endpoint -and its name- and then goes through all that resolution work to find out if there might be a different address to use. I mostly included the sub-option mechanic as a third option to be complete. It is a habit of mine to enumerate issues to enunciate that we are not arguing a false dichotomy. There is a real dichotomy here - address or FQDN and not both - centered on the discussion of the acceptance (or rejection if you prefer) of complexity in DHCP option format standards. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpRsFGzMT9lY.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Ted, The version which passed the Softwire LC is http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which included both name and IP address options. After IESG review, 05 has been published but this version has significant changes. We are at least two service providers who are asking for the need to roll back to 04. If text is needed to justify the need of the name option, for sure we can help. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : mardi 12 octobre 2010 15:50 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed On Oct 11, 2010, at 10:42 PM, mohamed.boucad...@orange-ftgroup.com wrote: Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. I'm confused. The current version of the draft is the -05 version, which makes no mention of FQDNs. You seem to be discussing the -04 version. Presumably the -05 version is the one that's meant to be published, so why are you discussing the -04 version? If the name option is needed, then the right thing to do is to issue a new draft. Since the draft would be substantially changed, and in a way that's contrary to the comments from the DHC working group, this would need to be re-reviewed by the DHC working group, and would need a new last call in the Softwires working group. It would be entirely inappropriate for such a substantial change to be made during IESG review without further review by the DHC and Softwires working groups, and without another last call. You would certainly need to explain the use case for the Name option--what value it adds that is missing from the address option. * 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
Re: [Softwires] DHCPv6 AFTR name option is needed
On Fri, Oct 08, 2010 at 05:36:48PM +0200, mohamed.boucad...@orange-ftgroup.com wrote: If there is a real issue with defining two DHCPv6 options (which I don't see), The problem of defining two options that convey the same configuration point is a problem we call aliasing. Section 6 (Avoid Aliasing) of draft-ietf-dhc-option-guidelines [1] is dedicated to discuss it, and concludes with the advice to choose one natural format for the option. In summary, it causes implementation confusion when the configuration value for one knob is present in multiple places in the packet - a resolution algorithm must therefore be defined. You could say that one of the IESG criticisms of the AFTR domain name option was that the normative language to enforce this hierarchy is heavy, and unlikely to actually be observed by casual implementers. It creates complication, and our experience is that complication creates problems. Worse, in this case it requires that the individual operator know the normative requirements of the configuration they write (you are REQUIRED to provide an IPv4 address, and PERMITTED to also provide a domain name to clients that support that option). The only advantage of defining multiple options for the same configuration value is that such a heavy-handed set of normative requirements _can_ be defined to ensure that clients are clearly informed of what the minimum requirements are. an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option. Which is section 5 of the same draft[1], Conditional Formatting is Hard. DHCP software has to be designed to allow the operator and users to use new options that weren't defined at the time the software was released - or for example are defined by vendors. Conditional format bytes have not entered the mainstream of the mechanisms offered by today's software, if even one implementation supports such a mechanism it is unknown to me. So the use of conditional formatting places adoption of the option on the 5-year software development cycle, new code must be written to use the option in both client and server, so it cannot realistically be touched by mortals until then. Conditional formatting also removes the question of choice from the DHCP client software, which often prefers to implement the least that is required. Since you cannot enumerate the formats you support, and you cannot expect a DHCP server to translate formats, a client must support all formats (and all future formats!). This means for example a B4 client that might need a DNS recursive server configuration for no other purpose than to locate its AFTR endpoint address must carry along with it a recursive stub resolver specifically for that purpose. It is a non-starter, in my opinion. A third option that has been suggested, through the years, is to define an encapsulated option space - sub options. This is a DHCP level option that contains code-length-values, and so each different format for the configuration parameter is given a unique code. This has all the same problems as the Aliasing problem, except that it offers an opportunity to define a sub-option code that allows a client to advertise what options it supports (a sub-option-request-sub-option). I don't think there are any major criticisms of this approach except that it again requires new code in both client and server. [1] Hankins, D., Guidelines for Creating new DHCP Options, draft-ietf-dhc-option-guidelines-05, February 2009. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgpl3Q6Wa2jwH.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Tue, Oct 12, 2010 at 07:26:10AM -0700, Ted Lemon wrote: If you absolutely have to have the FQDN option, then get rid of the IP address option.That eliminates the interoperability problem. In any case, though, you need to issue a new draft. As a B4 implementor, I reject the onerus requirement imposed to contain a DNS recursive stub resolver in B4 equipment, and to complicate the configuration of the B4 software to be conditional on the success (through retries) of its resolution. I will simply not use the IETF standard option in this case, and continue to configure our B4 elements using a VSIO option. The address option must be defined. If a name option must also be defined, then we must define the strict normative requirements to permit software to navigate the confusion that having both impose. -- David W. HankinsBIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/ pgppEDCdIhlIQ.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Folks, VoIP protocols in MGCP and SIP have been supporting IP address and FQDN for a long time. In VoIP deployment with FQDN use, the deployment always keeps a local name resolver. So why not look carefully at the use cases operators are presenting to advocate use of both FQDN and IP address and then go from there. I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism. After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, October 07, 2010 4:07 AM To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
On Oct 12, 2010, at 4:58 PM, Hemant Singh (shemant) wrote: I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism. After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. You've hit the nail on the head, Hemant. Custom protocols have no trouble with this. It's because DHCP is a general-purpose protocol that this becomes a problem. If you want a custom protocol, you should define a custom protocol. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
A general question. If 6rd could become an RFC in RFC 5969 with no mention of FQDN for the BR, what is so special about DS-Lite and deployments that a FQDN is needed by DS-Lite for the AFTR? I would think the same FQDN issue would arise in 6rd as well... What did I miss? Thanks, Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, October 12, 2010 1:42 AM To: Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc: Ullio Mario; Chairs Dhc; magli...@core3.amsl.com; Softwire Chairs; Softwires Subject: Re: [Softwires] DHCPv6 AFTR name option is needed Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Hi Hemant, As I know, since 6rd BRs are stateless, so you can configure an anycast address for load balancing stuff. Thanks, washam 2010/10/13 Hemant Singh (shemant) shem...@cisco.com: A general question. If 6rd could become an RFC in RFC 5969 with no mention of FQDN for the BR, what is so special about DS-Lite and deployments that a FQDN is needed by DS-Lite for the AFTR? I would think the same FQDN issue would arise in 6rd as well... What did I miss? Thanks, Hemant -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, October 12, 2010 1:42 AM To: Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc: Ullio Mario; Chairs Dhc; magli...@core3.amsl.com; Softwire Chairs; Softwires Subject: Re: [Softwires] DHCPv6 AFTR name option is needed Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med ___ 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] DHCPv6 AFTR name option is needed
(Adding dhc WG chairs to the thread.) The client behavior in draft-ietf-softwire-ds-lite-tunnel-option-04 did not describe any mechanism in which the client would combine the FQDN from the tunnel option with a suffix in the search list option to form a new name to use as its AFTR, nor did it mention anything about the DNS system doing load balancing. Given the text in draft-ietf-softwire-ds-lite-tunnel-option-04, there is no advantage to sending an FQDN, so the spec should define only the IP address option. - Ralph On Oct 8, 2010, at 1:30 AM 10/8/10, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Ralph Droms Envoyé : lundi 11 octobre 2010 20:46 À : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc : Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires Objet : Re: [Softwires] DHCPv6 AFTR name option is needed (Adding dhc WG chairs to the thread.) The client behavior in draft-ietf-softwire-ds-lite-tunnel-option-04 did not describe any mechanism in which the client would combine the FQDN from the tunnel option with a suffix in the search list option to form a new name to use as its AFTR, nor did it mention anything about the DNS system doing load balancing. Given the text in draft-ietf-softwire-ds-lite-tunnel-option-04, there is no advantage to sending an FQDN, so the spec should define only the IP address option. - Ralph On Oct 8, 2010, at 1:30 AM 10/8/10, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med
Re: [Softwires] DHCPv6 AFTR name option is needed
Hello Tomek, Thanks for your reply. The redundancy use case described by Med is the applicability scenario we have in mind too, for the ATFR name option. I understand the doubts raised, in defining two options to configure similar parameters, but from a Service Provider's point of view we believe these to options fit different use cases. In my opinion one way to address this point and having both of them in the draft could be either saying that only one of the two options can be present in the DHCP message or to specify a priority that implies what should be the behavior in case both parameters are present. In addition allowing specifying IP add or Name for a tunnel configuration is not a new concept, for example also in case of L2TP tunnel there was the possibility to specify either the tunnel endpoint name or the IP address. Regards, Roberta From: mohamed.boucad...@orange-ftgroup.com [mailto:mohamed.boucad...@orange-ftgroup.com] Sent: venerdì 8 ottobre 2010 7.31 To: Tomasz Mrugalski; Softwires WG Cc: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Subject: RE: [Softwires] DHCPv6 AFTR name option is needed Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.itmailto:roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.orgmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo
Re: [Softwires] DHCPv6 AFTR name option is needed
Hi Yiu, all, If there is a real issue with defining two DHCPv6 options (which I don't see), an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Yiu L. Lee Envoyé : vendredi 8 octobre 2010 16:55 À : Tomasz Mrugalski; Softwires WG Cc : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario Objet : Re: [Softwires] DHCPv6 AFTR name option is needed How about define a new option just for FQDN? Will this address the IESG's concern? On 10/7/10 11:24 PM, Tomasz Mrugalski tomasz.mrugal...@gmail.com wrote: Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore
Re: [Softwires] DHCPv6 AFTR name option is needed
Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.itmailto:roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.orgmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Cc : softwires@ietf.orgmailto:softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand
