Subject: [Softwires] DHCP option for DS-lite

From: Alain Durand <[email-masked]>
Date: Tue, 12 Oct 2010 12:00:36 -0700

Dear wg:

draft-ietf-softwire-ds-lite-tunnel-option<mailto:[email-masked]> 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.

---

From: <[email-masked]>
Date: Wed, 13 Oct 2010 07:55:07 +0200

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 : [email-masked] [mailto:[email-masked]] 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:

   - Alain.
_______________________________________________
Softwires mailing list
[email-masked]
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.
********************************

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 13 Oct 2010 09:50:43 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
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,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 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:

   - Alain.

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.

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 13 Oct 2010 08:27:07 -0400

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" <[email-masked]>
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
> 
> 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.
> 
> draft-ietf-softwire-ds-lite-tunnel-option<mailto:draft-ietf-softwire-ds-lite-t
> [email-masked]> 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 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
>> 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.
> 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.
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Oct 2010 12:40:21 -0700 (PDT)

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: "[email-masked]" 
><[email-masked]>
> To: Alain Durand <[email-masked]>; Softwires list <[email-masked]>
> Cc: Ralph Droms <[email-masked]>
> Sent: Wed, October 13, 2010 12:55:07 AM
>draft-ietf-softwire-ds-lite-tunnel-option<mailto:[email-masked]>
>>  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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2010 15:23:16 -0700

> 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 

Can anyone state an actual reason why this is the wrong thing, or is this just going to be a popularity contest?

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 13 Oct 2010 16:13:05 -0700

>   I agree that for load balancing the operators prefer to use DNS but not DHCP 

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. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: Alain Durand <[email-masked]>
Date: Thu, 14 Oct 2010 09:59:18 -0700

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.

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 14 Oct 2010 17:57:05 -0400

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" <[email-masked]> wrote:

>      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.
> 
> 
> 
> 
>> draft-ietf-softwire-ds-lite-tunnel-option<mailto:draft-ietf-softwire-ds-lite-
>> [email-masked]> 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
>> keep track which end-point is currently the best alternative and we would
>> have to develop

---

From: <[email-masked]>
Date: Fri, 15 Oct 2010 07:46:15 +0200

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 : [email-masked] [mailto:[email-masked]] 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

   - Alain.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 15 Oct 2010 16:21:57 -0700

On Fri, Oct 15, 2010 at 07:46:15AM +0200, [email-masked] wrote:

>       2007.  This is issue in not new for him.

shouldn't surprise you.

---

From: <[email-masked]>
Date: Mon, 18 Oct 2010 17:06:58 +0200

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-masked] [mailto:[email-masked]] 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

   - Alain.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Oct 2010 11:13:59 -0400

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Oct 2010 08:22:06 -0700

>   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.

>   network operated by dedicated teams.

Okay, I can dig that.

>   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.

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 13:48:38 +0200

Ted,

   The use cases for manipulating the FQDN information are those that
   motivated the DS-Lite-Tunnel-Name AVP (as described in Section 5.2 of
   http://www.ietf.org/id/draft-ietf-softwire-dslite-radius-ext-00.txt),
   and are very similar to those that reflect massively deployed VoIP
   designs, as reminded by Hemant in
   http://www.ietf.org/mail-archive/web/softwires/current/msg01692.html.

   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.

   The latter can be achieved by using a FQDN option, in a very similar
   way to what is usually done in VoIP environments.

   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, while (1) The FQDN AVP has been documented in the
   RADIUS extensions for DS-Lite draft, and (2) This is a very common
   practice that has proven to be useful and efficient in VoIP
   environments, based upon what is documented in RFC3361.  (Note that
   RFC3319 does not define only one domain name but A LIST OF FQDN for a
   SIP proxy).

   I'm sure you have already noticed the great similarity between the
   DS-Lite and VoIP contexts, as far as the NAT capabilities are
   concerned.  In the managed VoIP deployment, SIP UA are provisioned
   with their outbound proxy (usually an SBC to name it).  This
   device acts as a CGN for the VoIP traffic (signalling, NATing RTP
   flows, and other application-specific features such as THIG, etc.).
   In the context of DS-Lite, CPEs should be provided with the
   reachability information of the CGN that will handle all their IPv4-
   addressed traffic.

   This is not a matter of "suiting my organization", this is a use case
   that is considered valid by several WG members (http://www.ietf.org/
   mail-archive/web/softwires/current/msg01698.html, http://
   www.ietf.org/mail-archive/web/softwires/current/msg01692.html).

   And indeed, there used to be a WG consensus on supporting both
   options, as you rightfully recalled.

   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.

   Med

-----Message d'origine-----
De : Ted Lemon [mailto:[email-masked]] 
Envoyé : lundi 18 octobre 2010 17:22
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Softwires list
Objet : Re: [Softwires] DHCP option for DS-lite

Okay, I can dig that.

---

From: Alain Durand <[email-masked]>
Date: Tue, 19 Oct 2010 06:21:51 -0700

On Oct 18, 2010, at 11:22 AM, Ted Lemon wrote:

> 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]

>>  network operated by dedicated teams.

[Alain]
What Mohamed is pointing at is a key piece of information that was missing so far in this discussion.
[/Alain.]

> 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 i…

[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.]

---

From: Tom Taylor <[email-masked]>
Date: Tue, 19 Oct 2010 10:53:52 -0400

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 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.
>
> _______________________________________________ Softwires mailing
> list [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Oct 2010 08:38:00 -0700

>   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?

>   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.

>   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.

>   and I would therefore appreciate a greater show of courtesy from your

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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Oct 2010 08:49:38 -0700

> I'm sorry, but you might have missed the fact that the original document was last called both in Softwire and DHCwg in February.

I believe that you believe this, but find no evidence of it in the DHC working group archive.   What I do find are two messages about the last call in the softwire working group, which is *not* the same thing as a last call in the DHC working group.   One of the two messages to the mailing list about this was a comment by Dave Hankins about the very question we are debating now: whether or not the FQDN option is a good idea. Dave's position was that it was not.

If you want a comparison, look at how Remy handled the DHCP option for 6rd, which was also in February.   That was an actual DHC working group last call, and got quite a bit of discussion.

My point in mentioning the last call issue is not to blame anyone for not requesting the last call, but rather to explain why we are having this discussion now, rather than having had it in February.

> of indirection.

The model that allows this in DHCP is the one that I explained in the message that you replied to.   Do you think that that model will not work for some reason?   If so, what is the reason?

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 16:50:24 +0200

Ted, all,

Please see a few additional comments inline. 

[snip]

CJ: capitalizing on VoIP SBC operation experience, the de-correlation of DNS and DHCP functions facilitates redirection operations (e.g. towards the CGN that maintains static entries for a given customer), and the opportunity to apply similar operational procedures to NAT capabilities whether they are embedded in a CGN or in a SBC is something that is often valued by service providers, at least from an OPEX standpoint.

[snip]

CJ: it seems to me that the above comment mostly reflects an implementation/configuration-driven concern. I can understand this position, but I think IETF WGs are chartered to document tools (namely protocols) that are meant to address specific issues and requirements. WGs are not supposed to document how to *implement* (let alone configure) such tools, which is basically the responsibility of service providers and other players. 

I think the requirement for the FQDN option makes sense (at least in some providers' environments), and this is why the standardization of this option is useful. This does not mean that this option must be used by each and every service provider.

As long as this FQDN information can be made available by means of a DHCP option, then it's up to the service providers to deal with corresponding yet required configuration tasks.

This is why I don't see any harm in standardizing this option along with the IP address option, and I therefore support the need to re-include this option in the core spec.

Cheers,

Christian.