David (document shepherd), Jari, all, In can answer to the technical questions, but before that let position this discussion in its context in the overall process (softwire should follow the ietf process). Below a reminder of the main steps for the adoption of this document:
o First of all, this document is the proprietary of the working group and should reflect the consensus of the working group not the opinions of the authors neither the chairs. o The working group reached a consensus on the version, available at http://tools.ietf.org/html/ draft-ietf-softwire-ds-lite-tunnel-option-03. During the last call I didn't remember comments about the name option. o Dave Ward who is the document shepherd mentioned the following in his note (available on the tracker): (1) "We saw evidence of extensive review on the mailing list. The documents has been presented in softwires, v6ops, and dhc working groups." (2) "the document has strong support in the WG." (3) "This is strictly a protocol specification. We believe that an operational document discussing some of the various tradeoffs and choices when deploying DS-Lite would be valuable." o According to the IETF tracker, a "Go Ahead" has been received from R. Droms on August, 5th. I understand this as Ralph has no technical issue with the content of the document. o According to the IETF tracker, Jari raised the following comment: "This document is ready to move forward. However, there is one issue that I would like to briefly discuss before recommending the final approval of the RFC. We have been pushing back in other cases when people defined both FQDN and IP address information for the same configuration item in DHCP. Why are two options and configuration mechanisms absolutely necessary in this case? Wouldn't IP-address based configuration suffice? " o The comment from Jari is valid and the document should justify why two options are needed. This is even surprising because D. Hankins is also the author of http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines since 2007. This is issue in not new for him. o The authors on their own (or with the document shepherd, I don't know) decided to remove the name option **without** asking the working group's opinion. No notification has been sent on the mailing list to notify or to justify this IMPORTANT change to the document. At least two representatives of service providers reiterated the need of the name option for high availability and load balancing reasons. We can provide Jari with more details if required. Since the authors already maintained the IP address I believe they have strong arguments to maintain also the IP address option. The question should whether this feedback solves the issue raised by Jari during the IESG review. Jari, do you need more justification? 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