Hi gents, In the VoIP case, most clients honor the A RR ttl and cache the server's IP, so they won't do dns query for every call. In theory, the B4 element can cache the list of AAAA RRs if the FQND returns multiple AAAA RRs (or SRV). I guess this is what Med and Roberta meant for LB and HA. That said, this draft didn't mention anything about how the resolver to make use of the FQDN to achieve HA or LB, it has very little value to define it. What is worse is this may confuse the B4 implementers. From the spec perspective, I think it is better to remove the name option and define it later in a different draft if needed.
Regards, Yiu On 10/14/10 12:59 PM, "Alain Durand" <adur...@juniper.net> wrote: > 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: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 > > _______________________________________________ > 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
