(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) > 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 > > ********************************* > 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
