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: [email protected] [mailto:[email protected]] Sent: venerdì 8 ottobre 2010 7.31 To: Tomasz Mrugalski; Softwires WG Cc: [email protected]; 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:[email protected]] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email protected]; 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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of [email protected]<mailto:[email protected]> Sent: giovedì 7 ottobre 2010 10.07 To: [email protected]<mailto:[email protected]>; Softwire Chairs Cc: [email protected]<mailto:[email protected]> 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 : [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] De la part de [email protected]<mailto:[email protected]> Envoyé : lundi 27 septembre 2010 21:30 À : [email protected]<mailto:[email protected]> Cc : [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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 [email protected]<mailto:[email protected]> 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. ******************************** 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. [cid:[email protected]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.
<<inline: logo Ambiente_foglia.jpg>>
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
