Alain, all, I support the authors in the debate. Also I urge the authors to work with Ted to come up with a solution acceptable to DHC WG, e.g. suboptions. I agree that for load balancing the operators prefer to use DNS but not DHCP servers.
Regards, Behcet ----- Original Message ---- > From: "mohamed.boucad...@orange-ftgroup.com" ><mohamed.boucad...@orange-ftgroup.com> > To: Alain Durand <adur...@juniper.net>; Softwires list <softwires@ietf.org> > Cc: Ralph Droms <rdr...@cisco.com> > Sent: Wed, October 13, 2010 12:55:07 AM > Subject: Re: [Softwires] DHCP option for DS-lite > > Dear Alain, all, > > I strongly object to define only a single AFTR address option. As I > mentioned >in previous e-mails, the FQDN name option is needed for some scenarios such >as >load balancing. Having DHCP server acting as a load balancer is not an option >for us. > > > If the problem is only with the language as mentioned by D. Hankins, then > the >spec should be clear enough. > > I hope the wg will re-consider this position and defines the name aftr option. > > Cheers, > Med > > > -----Message d'origine----- > De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la >part de Alain Durand > Envoyé : mardi 12 octobre 2010 21:01 > À : Softwires list > Cc : Ralph Droms > Objet : [Softwires] DHCP option for DS-lite > > Dear wg: > >draft-ietf-softwire-ds-lite-tunnel-option<mailto: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 > > ********************************* > 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
