On Nov 11, 2010, at 8:40 PM, David W. Hankins wrote: > On Thu, Nov 11, 2010 at 05:17:03PM -0800, Ted Lemon wrote: >> Do I take this to mean that you are not in favor of the use of the >> search path with this option? > > That's one workaround. I am neither for nor against it. The search > path behavior was required in the WG discussions that were causative > in the -06 revision of the draft. I am simply reflecting that > discussion and consensus.
David: I went back to the email Mohamed Boucadair sent to the list to explain the requirements. See attached for full reference. The key point is: Begin forwarded message: > 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. That is, what the DHCP server returns is a region specific FQDN, not an unqualified domain name. As such, I see no reason to include the search path text in the draft. - Alain.
--- Begin Message ---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 : [email protected] [mailto:[email protected]] 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:[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 ********************************* 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. ********************************
--- End Message ---
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
