Hi ladies and gents, I understand why Ralph, Ted and Dave's worry about the FQDN option confused implementers. In fact, the current version didn't define the any behavior of using FQDN for redundancy and load-balancing of using FQDN. I also understand some operators (Orange and Telecom Italia) want to use FQDN for HA and LB. If the WG decides a FQDN option is very important, I would highly recommend to write a draft (similar to RFC3263 for sip) to explain the LB and HA behavior of using FQDN.
Since this will take time to standardize this future draft and many operators and vendors are waiting for the DHCP option to complete the implementation, may I suggest this forwarding: 1. Go forward for this draft with only IP address option defined. 2. Write a new draft to describe the correct behavior using FQDN for HA and LB. This new draft will also define a new dhcp option. Is this acceptable to the WG? Thanks, Yiu On 10/13/10 3:50 AM, "Maglione Roberta" <roberta.magli...@telecomitalia.it> wrote: > Dear All, > I object to the decision of removing the FQDN option, because this option > is crucial for supporting load balance and redundancy in our deployment > scenario. > If needed, I'm available to work with the authors in order to clarify both the > use case and the language in the draft in order to address the points raised > by the IESG. > > Best regards, > Roberta > > -----Original Message----- > From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf > Of mohamed.boucad...@orange-ftgroup.com > Sent: mercoledì 13 ottobre 2010 7.55 > To: Alain Durand; Softwires list > Cc: Ralph Droms > 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-t > unnel-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 > > 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 https://www.ietf.org/mailman/listinfo/softwires
