Re: [Softwires] DHCP option for DS-lite
On Oct 18, 2010, at 11:22 AM, Ted Lemon wrote: On Oct 18, 2010, at 8:06 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: In addition to the technical reasons mentioned in previous e-mails, I I'm sorry, I must have missed that email. I saw a lot of talk about how the WG consensus was for the FQDN option, and the IESG ought to respect that, and the DHCwg ought not to have a say in it. [Alain] Ted, I'm sorry, but you might have missed the fact that the original document was last called both in Softwire and DHCwg in February. It is thus incorrect to say that DHCwg is expected to have no say in it I would also like to point out that a few comments were received, mostly supportive. The draft -01 that was submitted for last call contained both an IP address and a name. See last call announcement: http://www.ietf.org/mail-archive/web/softwires/current/msg01176.html So, please, stop saying that the DHCwg never saw that draft. [/Alain] 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. Okay, I can dig that. [Alain] What Mohamed is pointing at is a key piece of information that was missing so far in this discussion. [/Alain.] In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. See, this is the disconnect. Are you trying to suggest that this statement logically follows the previous paragraph's description of your circumstances? Or was that just a non-sequitur? Because I don't see any logical connection between these two statements. It seems to me that you are saying that the DNS will be under the control of this regional team, and the DHCP server is not. So the regional team is the only team that can make changes to the DNS. But since the DHCP server will be looking the name up in the DNS, this is a non-problem. Whether the DHCP server provides an FQDN or an IP address, the source for the IP address the client eventually uses will _always_ be the DNS. So the regional team will not have a problem updating that information. Furthermore, even if it were the case that the regional team couldn't do what you want, is that any justification for the position you've taken? I don't think it is, because it's an operational issue specific to your organization. We can't design protocols to suit your organization. Obviously we'd like to have the flexibility to address your needs, but as far as I can tell, we *have* that flexibility. And you haven't given any technical explanation for why we don't. [Alain] Ted: We always complain in IETF that operators left the room, that we need more operator guidance. We cannot say that and at the same time dismiss operator input. Both Mohamed Roberta have indicated that their operational model is to use a layer of indirection between national engineering and regional engineering. I'm not aware of any model in DHCP that allows for such an indirection. Thus, they apparently have decided, for operational reasons, to use DNS as their level of indirection. Apparently, for talking to Mohamed off-line, this is current, well deployed practice, and not just for Orange/FT, but done by many ISPs. We cannot ignore it. Operational needs should be as important as technical needs. [/Alain.] ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
I believe Ted is saying the operator achieves its objectives because when DHCP resolves the FQDN in order to distribute the address, it invokes the DNS mappings that have been set up by the regional teams. I see a potential gap in this reasoning. Could it be that the regional teams manage different DNS servers with different content for the saME FQDN? If so, how would DHCP know which DNS server to query to achieve the correct resolution for the given subscriber? Mohamed et al, have I characterized the problem correctly? If so, Ted, what is your response? On 19/10/2010 9:21 AM, Alain Durand wrote: On Oct 18, 2010, at 11:22 AM, Ted Lemon wrote: [snip] See, this is the disconnect. Are you trying to suggest that this statement logically follows the previous paragraph's description of your circumstances? Or was that just a non-sequitur? Because I don't see any logical connection between these two statements. It seems to me that you are saying that the DNS will be under the control of this regional team, and the DHCP server is not. So the regional team is the only team that can make changes to the DNS. But since the DHCP server will be looking the name up in the DNS, this is a non-problem. Whether the DHCP server provides an FQDN or an IP address, the source for the IP address the client eventually uses will _always_ be the DNS. So the regional team will not have a problem updating that information. Furthermore, even if it were the case that the regional team couldn't do what you want, is that any justification for the position you've taken? I don't think it is, because it's an operational issue specific to your organization. We can't design protocols to suit your organization. Obviously we'd like to have the flexibility to address your needs, but as far as I can tell, we *have* that flexibility. And you haven't given any technical explanation for why we don't. [Alain] Ted: We always complain in IETF that operators left the room, that we need more operator guidance. We cannot say that and at the same time dismiss operator input. Both Mohamed Roberta have indicated that their operational model is to use a layer of indirection between national engineering and regional engineering. I'm not aware of any model in DHCP that allows for such an indirection. Thus, they apparently have decided, for operational reasons, to use DNS as their level of indirection. Apparently, for talking to Mohamed off-line, this is current, well deployed practice, and not just for Orange/FT, but done by many ISPs. We cannot ignore it. Operational needs should be as important as technical needs. [/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
Re: [Softwires] DHCP option for DS-lite
On Oct 19, 2010, at 4:48 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: We believe that AFTR (CGN) capabilities should be distributed as close to the customers as possible, not only for scalability, flexibility and performance reasons, but also to improve the overall availability of the DS-Lite service while dramatically facilitating DS-Lite management as briefly exposed in one of my previous e-mails. Okay, so I asked you a specific question about this, and outlined a solution that involves resolving the FQDN in the DHCP server rather than in the client. You haven't said why this won't work for you. Could you speak to that? This use case could be further elaborated in a specific draft, but I'm curious to know why the use of the FQDN option mandates yet another effort, I explained this early, but I'll reiterate. If you have two different ways in DHCP to configure a value in the client, then you create an interoperability problem. The DHCP client requests one or the other option; if it requests the wrong option, the server will not respond, because it wasn't configured with that option. In order to correct this problem, the DHCP server needs to know that the FQDN option is an alias for the IP address option. This requires custom code on the DHCP server, just for your option. Imagine if every single working group that wanted a DHCP option wanted custom code for the option as well. You would have more customization code in the server than protocol code. This is what I am trying to avoid by having this discussion with you. I am not objecting to sending the FQDN, if that is what you really need. But I *am* asking you (that is, the softwires working group) to make a decision: do you want FQDN, or do you want IP address. We had a pretty unequivocal no to DNS from David Hankins. We have a pretty unequivocal yes to DNS from you. I'm asking you to work that out. [...details about your protocol...] I just want to briefly explain why I haven't responded to any of your statements about your protocol, and how it works. The reason is because you are using DHCP as an information delivery mechanism. It's not part of your protocol. You (the working group) need to decide what information you need DHCP to deliver to you. Once you've made that decision, the inner workings of your protocol are irrelevant to the DHCP protocol. And indeed, there used to be a WG consensus on supporting both options, as you rightfully recalled. The WG consensus was a consensus in the softwires working group, not in the DHC working group. Both working groups need to weigh in on this option, not just softwires. Now that you have feedback from the DHC working group, which you should have got before you sent the draft to the IESG, it would be nice if you could have a discussion in softwires about what the right course of action is, rather than insisting that such a discussion is not necessary because softwires has consensus. Last but not least, I think the unnecessary aggressively of your comments jeopardizes the serenity of the discussion (in particular the tone and contents of your message http://www.ietf.org/mail-archive/web/softwires/current/msg01703.html were totally inappropriate, especially because you are a WG chair), and I would therefore appreciate a greater show of courtesy from your side. The essential source of suffering in the world is the belief that my serenity depends on the actions of another. If I can free myself from this mistaken belief, serenity is available to me in any circumstance. I am sorry that you do not feel that I have been appropriately courteous. You are not the only person to have said this--I got a private note from someone at ISC who thought my response was a bit over the top as well. I'm sorry it came across this way, and I don't claim that it was appropriately worded. But the essence of my question was this: do you want this to be easy to implement, or hard to implement. I phrased it the way I did to emphasize my belief that the direction you wanted to go in the discussion was counterproductive. It was not my intention to insult you. Nor was it my intention to be aggressive, whatever that means in this context. My intention was, and is, to get the issue resolved. It would be highly effective if you were to avoid taking my comments personally, and instead see them in the context of a discussion about what the right technical solution is here. I don't know you personally, don't hold any ill will toward you, and really just want to get to the right outcome here. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
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 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 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-optionmailto: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
Re: [Softwires] DHCP option for DS-lite
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 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 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-optionmailto: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
Re: [Softwires] DHCP option for DS-lite
On Oct 18, 2010, at 8:06 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: In addition to the technical reasons mentioned in previous e-mails, I I'm sorry, I must have missed that email. I saw a lot of talk about how the WG consensus was for the FQDN option, and the IESG ought to respect that, and the DHCwg ought not to have a say in it. I saw some accusations about abuse of power (for the record, I have none, other than my ability to try to get the process to be followed, which it was not for this draft). But I didn't see a *single* technical reason given for your position. Unless DHCP won't work for us is a technical reason. 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. Okay, I can dig that. In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. See, this is the disconnect. Are you trying to suggest that this statement logically follows the previous paragraph's description of your circumstances? Or was that just a non-sequitur? Because I don't see any logical connection between these two statements. It seems to me that you are saying that the DNS will be under the control of this regional team, and the DHCP server is not. So the regional team is the only team that can make changes to the DNS. But since the DHCP server will be looking the name up in the DNS, this is a non-problem. Whether the DHCP server provides an FQDN or an IP address, the source for the IP address the client eventually uses will _always_ be the DNS. So the regional team will not have a problem updating that information. Furthermore, even if it were the case that the regional team couldn't do what you want, is that any justification for the position you've taken? I don't think it is, because it's an operational issue specific to your organization. We can't design protocols to suit your organization. Obviously we'd like to have the flexibility to address your needs, but as far as I can tell, we *have* that flexibility. And you haven't given any technical explanation for why we don't. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
On Fri, Oct 15, 2010 at 07:46:15AM +0200, mohamed.boucad...@orange-ftgroup.com wrote: This: 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. is why this: 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. shouldn't surprise you. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpCvBWOXK3cx.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
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 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 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
Re: [Softwires] DHCP option for DS-lite
Dear All, I object to the decision of removing the FQDN option, because this option is crucial for supporting load balance and redundancy in our deployment scenario. If needed, I'm available to work with the authors in order to clarify both the use case and the language in the draft in order to address the points raised by the IESG. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: mercoledì 13 ottobre 2010 7.55 To: Alain Durand; Softwires list Cc: Ralph Droms Subject: Re: [Softwires] DHCP option for DS-lite Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto: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 * 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
Hi ladies and gents, I understand why Ralph, Ted and Dave's worry about the FQDN option confused implementers. In fact, the current version didn't define the any behavior of using FQDN for redundancy and load-balancing of using FQDN. I also understand some operators (Orange and Telecom Italia) want to use FQDN for HA and LB. If the WG decides a FQDN option is very important, I would highly recommend to write a draft (similar to RFC3263 for sip) to explain the LB and HA behavior of using FQDN. Since this will take time to standardize this future draft and many operators and vendors are waiting for the DHCP option to complete the implementation, may I suggest this forwarding: 1. Go forward for this draft with only IP address option defined. 2. Write a new draft to describe the correct behavior using FQDN for HA and LB. This new draft will also define a new dhcp option. Is this acceptable to the WG? Thanks, Yiu On 10/13/10 3:50 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Dear All, I object to the decision of removing the FQDN option, because this option is crucial for supporting load balance and redundancy in our deployment scenario. If needed, I'm available to work with the authors in order to clarify both the use case and the language in the draft in order to address the points raised by the IESG. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: mercoledì 13 ottobre 2010 7.55 To: Alain Durand; Softwires list Cc: Ralph Droms Subject: Re: [Softwires] DHCP option for DS-lite Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-t unnel-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 * 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra
Re: [Softwires] DHCP option for DS-lite
Alain, all, I support the authors in the debate. Also I urge the authors to work with Ted to come up with a solution acceptable to DHC WG, e.g. suboptions. I agree that for load balancing the operators prefer to use DNS but not DHCP servers. Regards, Behcet - Original Message From: mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com To: Alain Durand adur...@juniper.net; Softwires list softwires@ietf.org Cc: Ralph Droms rdr...@cisco.com Sent: Wed, October 13, 2010 12:55:07 AM Subject: Re: [Softwires] DHCP option for DS-lite Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto: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 * 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
Re: [Softwires] DHCP option for DS-lite
On Oct 13, 2010, at 12:40 PM, Behcet Sarikaya wrote: I support the authors in the debate. Also I urge the authors to work with Ted to come up with a solution acceptable to DHC WG, e.g. suboptions. Suboptions do nothing to make the situation better, so I would really appreciate it if we could stop talking about them. I agree that for load balancing the operators prefer to use DNS but not DHCP servers. Can anyone state an actual reason why this is the wrong thing, or is this just going to be a popularity contest? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
On Wed, Oct 13, 2010 at 12:40:21PM -0700, Behcet Sarikaya wrote:
I agree that for load balancing the operators prefer to use DNS but not
DHCP
servers.
I do not mean to be rude by asking this, but as a DHCPv6 server
implementor I'm very surprised by this, as our community tell us
they're happy to do service load balancing by population - which is
handily monitored (and limited or controlled) by DHCP servers.
So I'm very curious if you're allowed to say what DHCP server you
are using?
For example, in ISC dhcpd for DHCPv6, I might configure, in
dhcpd.conf language;
if (encode-int(8, suffix(option dhc6.client-id, 1)) % 2) {
option dhc6.aftr-endpoint aftr1.example.com;
} else {
option dhc6.aftr-endpoint aftr2.example.com;
}
or somesuch...and neatly give statistically 1/2 the population one
of the 2 servers, or more as meets demands. The config can easily be
managed by the monitoring station, and updated as systems fail, or the
IPv6 address of the failed systems can be routed to a surviving peer.
This configuration might be scoped in groups collecting broadcast
domains, with separate statements for different sets of clients
depending on geography.
Really, the possibilities are quite endless. I'm of the understanding
that this sort of feature-set (either scrip-like configuration language
like ISC DHCP's, or user API's for callouts) is quite common in DHCP
servers on the market today.
So I am surprised that it is preferable to introduce an additional
protocol (DNS), additional packet exchanges (not just delay but the
error handling when DHCPv6 succeeds but DNS fails), and a larger
attack surface all for load balancing specifically using DNS, which
you could have done already when the DHCPv6 Reply is sent.
And if you are using a DHCPv6 server that is on the market today, I
would wonder why you wouldn't use this feature and instead invest
in a DNS load balancer?
--
David W. HankinsIf you don't do it right the first time,
Software Engineeryou'll just have to do it again.
Internet Systems Consortium, Inc. -- Jack T. Hankins
pgpSnUVItEV4o.pgp
Description: PGP signature
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
[Softwires] DHCP option for DS-lite
Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto: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
Re: [Softwires] DHCP option for DS-lite
Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto: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 * 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
