We've had a lot of discussion about how the FQDN might be used, perhaps in conjunction with the contents of other options, to provision a device with the IP address of ds-lite tunnel endpoint. I don't think I've seen formal I-D text that specifies, for example, the two levels of indirection mechanism you describe below. It would help the discussion a lot to have such a formal description of the use case and the specific mechanism that addresses that use case.
- Ralph On Oct 18, 2010, at 11:06 AM 10/18/10, <mohamed.boucad...@orange-ftgroup.com> wrote: > > Dear Alain, all, > > In addition to the technical reasons mentioned in previous e-mails, I > would like to raise that operational issues should be also taken > into account for the provisioning of the DS-Lite AFTR reachability > information. In particular, we are considering two levels of > redirection: > > o The first level is national-wise is undertaken by the DHCP: a > regional-specific FQDN will be returned; > > o The second level is done during the resolution of the regional- > specific FQDN to redirect the customer to a regional CGN among a > pool deployed regionally. > > Distinct operational teams are responsible for each of the above > mentioned levels. A clear separation between the functional > perimeter of each team is a sensitive task for the maintenance of the > services we are running. In particular, regional teams will require > to introduce new resources (e.g., new CGN devices) to meet an > increase of customer base. The introduction of these new devices > (addressing, redirection, etc.) is implemented locally. Having this > regional separation provides flexibility to manage portions of > network operated by dedicated teams. > > In order to be able to meet this operational constraint, the AFTR > option name is part of our requirements. > > Cheers, > > Med > > > > -----Message d'origine----- > De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la > part de Alain Durand > Envoyé : jeudi 14 octobre 2010 18:59 > À : Softwires list > Cc : Ralph Droms > Objet : Re: [Softwires] DHCP option for DS-lite > > 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 > > ********************************* > 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
