I went back to the other thread on this topic "DHCPv6 AFTR name option is
needed".
The only technical argument brought forward is that some ISPs would like to use
a level of indirection via DNS
to achieve load balancing (where the DNS has some form of measurement of the
current load of the system).
They point at VoIP for a precedent in that space.
I would like to offer several remarks:
1) In the current DS-Lite model, the B4 element would only find out the tunnel
end-point at config (boot) time.
There is no provision in the spec to regularly refresh this information.
This means that whatever is configured
is going to stay that way for possibly a very long time.
2) It is unclear that the load information that the DNS was using at the time
of the AAAA resolution is a good indicator of what the load will be hours
or days later.
3) Thus, it is unclear that such a system provide any better load distribution
that a simple round-robin
that can trivially be implemented in a DHCP server
4) If one follows that logic, the DNS redirection just add a round trip time
for no benefits.
5) The analogy with VoIP does not hold here because the VoIP client can do the
AAAA query
just before placing a call. The load information coming from the DNS has a
better chance of being accurate for the next few minutes.
I would like to invite the proponents of the DNS indirection to provide
technical arguments as why the above remarks are incorrect.
- Alain.
On Oct 12, 2010, at 12:00 PM, Alain Durand wrote:
> Dear wg:
>
> draft-ietf-softwire-ds-lite-tunnel-option<mailto:[email protected]>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
