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-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
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
