Subject: [Softwires] DHCPv6 AFTR name option is needed

From: <[email-masked]>
Date: Thu, 7 Oct 2010 10:06:33 +0200

Dear authors, chairs,

We are surprised to see the AFTR name option being removed from the latest version of this draft:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt

Is there any reason why this option has been removed?

We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined.

FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 27 septembre 2010 21:30
À : [email-masked]
Cc : [email-masked]
Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite
	Author(s)       : D. Hankins, T. Mrugalski
	Filename        : draft-ietf-softwire-ds-lite-tunnel-option-05.txt
	Pages           : 6
	Date            : 2010-09-27

This document specifies single DHCPv6 option which is meant to be
used by a Dual-Stack Lite client (Basic Bridging BroadBand element,
B4) to discover its Address Family Transition Router (AFTR) address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

*********************************
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: Thu, 7 Oct 2010 11:58:38 +0200

Hello All,
    I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios.
We really would like to see both of them back in the draft.

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: giovedì 7 ottobre 2010 10.07
To: [email-masked]; Softwire Chairs
Cc: [email-masked]
Subject: [Softwires] DHCPv6 AFTR name option is needed

Dear authors, chairs,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 27 septembre 2010 21:30
À : [email-masked]
Cc : [email-masked]
Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt

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

---

From: Tomasz Mrugalski <[email-masked]>
Date: Fri, 8 Oct 2010 05:24:26 +0200

Roberta, Mohamed,
AFTR name option was removed as a result of a concerns raised by Jari Arkko
and Ralph Droms during IESG review. They were very clear that defining two
options to configure the same parameter is not acceptable.

Regarding scenario mentioned by Mohamed, since you are already
differentiating between different locations (as I understand in your
scenario different locations provide different DNS addresses that resolve
the same AFTR FQDN to different addresses, right?), you may do this
explicitly and provide different AFTR addresses. Would that solve the
problem?

Hope that helps.
Tomek

On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta <
[email-masked]> wrote:

> Hello All,
>    I fully agree with Med, both AFTR IP address and AFTR name options are
> needed, in order to be able to handle different scenarios.
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> We would like to see this option back to the draft and that *** both ***
> the AFTR IP address and the name options are defined.
>
> FWIW, one of the deployment use cases we are considering is the
> distribution of the DS-Lite serviced customers among several (geo
> distributed) AFTRs by combining the search domain name dhcpv6 option (Code
> 24) and a generic FQDN conveyed in the AFTR name option. This would allow
> for a more controlled load distribution among deployed AFTRs.
>
>
> Cheers,
> Med
>
>
> Objet : [Softwires] I-D
> Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt
>
> 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: <[email-masked]>
Date: Fri, 8 Oct 2010 07:30:47 +0200

Dear Tomek,

Thank you for this clarification.

Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference.

To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned).

With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR.

Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context.

Hope this clarifies our concern.

Cheers,
Med

________________________________
De : Tomasz Mrugalski [mailto:[email-masked]]
Envoyé : vendredi 8 octobre 2010 02:00
À : Softwires WG
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta
Objet : Re: [Softwires] DHCPv6 AFTR name option is needed

Roberta, Mohamed,
AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable.

Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem?

Hope that helps.
Tomek

On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta <[email-masked]<mailto:[email-masked]>> wrote:
Hello All,
   I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios.
We really would like to see both of them back in the draft.

Best regards,
Roberta

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: giovedì 7 ottobre 2010 10.07
To: [email-masked]<mailto:[email-masked]>; Softwire Chairs
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Softwires] DHCPv6 AFTR name option is needed

Dear authors, chairs,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 27 septembre 2010 21:30
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 8 Oct 2010 10:10:54 +0200

Hello Tomek,
    Thanks for your reply.
The redundancy use case described by Med is the applicability scenario we have in mind too, for the ATFR name option.
I understand the doubts raised, in defining two options to configure similar parameters, but from a Service Provider's point of view we believe these to options fit different use cases. In my opinion one way to address this point and having both of them in the draft could be either saying that only one of the two options can be present in the DHCP message or to specify a priority that implies what should be the behavior in case both parameters are present.
In addition allowing specifying IP add or Name for a tunnel configuration is not a new concept, for example also in case of L2TP tunnel there was the possibility to specify either the tunnel endpoint name or the IP address.

Regards,
Roberta

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: venerdì 8 ottobre 2010 7.31
To: Tomasz Mrugalski; Softwires WG
Cc: [email-masked]; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta
Subject: RE: [Softwires] DHCPv6 AFTR name option is needed

Dear Tomek,

Cheers,
Med

Hope that helps.
Tomek

Best regards,
Roberta

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: giovedì 7 ottobre 2010 10.07
To: [email-masked]<mailto:[email-masked]>; Softwire Chairs
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Softwires] DHCPv6 AFTR name option is needed

Dear authors, chairs,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 27 septembre 2010 21:30
À : [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Oct 2010 07:34:03 -0700 (PDT)

Hi Med,

>Providing the IP address in the option is not flexible  enough and especially it 
>
>may not be recommended to achieve load balancing.  Otherwise the DHCPv6 server 
>should act as a load balancer, which is not  currently our preference.
> 
>To illustrate more the usage with the domain name option:  The scenario I 
>mentioned (is similar to what currently done in some VoIP  networks for 
>distributing customers among SBC nodes or P-CSCFs): you provide a  generic FQDN 

>of the AFTR by the DHCP server together with a suffix in the  dns serach list 
>option. When the B4 receives these two options, it  will form a the FQDN to use 

>to resolve its AFTR. Then a  query is sent to the DNS system (it can be 
>dedicated to the service), and  based on the load considerations, the requesting 
>
>client is redirected to  the appropriate AFTR nodes (i.e., an IP address is  
>returned).
> 
>Having the two options allow for more  flexibility for the engineering. IMHO, 
>the IETF should not impose  engineering choice to SPs. It will be up to each 
>service provider to decide  whether an IP address or a FQDN is more convenient 
>in his deployment  context.

I think this point should have been emphasized in the draft before sending it to 
IESG.
That would have made some difference in IESG.

Regards,

Behcet

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 8 Oct 2010 10:54:41 -0400

How about define a new option just for FQDN? Will this address the IESG¹s
concern?

On 10/7/10 11:24 PM, "Tomasz Mrugalski" <[email-masked]> wrote:

> Regarding scenario mentioned by Mohamed, since you are already differentiating
> between different locations (as I understand in your scenario different
> locations provide different DNS addresses that resolve the same AFTR FQDN to
> different addresses, right?), you may do this explicitly and provide different
> AFTR addresses. Would that solve the problem?
> 
> Hope that helps.
> Tomek
> 
> On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta
> <[email-masked]> wrote:
>> Hello All,
>> We would like to see this option back to the draft and that *** both *** the
>> AFTR IP address and the name options are defined.
>> 
>> FWIW, one of the deployment use cases we are considering is the distribution
>> of the DS-Lite serviced customers among several (geo distributed) AFTRs by
>> combining the search domain name dhcpv6 option (Code 24) and a generic FQDN
>> conveyed in the AFTR name option. This would allow for a more controlled load
>> distribution among deployed AFTRs.
>> 
>> 
>> Cheers,
>> Med
>> 
>>

---

From: <[email-masked]>
Date: Fri, 8 Oct 2010 17:36:48 +0200

Hi Yiu, all,

If there is a real issue with defining two DHCPv6 options (which I don't see), an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Yiu L. Lee
Envoyé : vendredi 8 octobre 2010 16:55
À : Tomasz Mrugalski; Softwires WG
Cc : [email-masked]; Softwire Chairs; Ullio Mario
Objet : Re: [Softwires] DHCPv6 AFTR name option is needed

How about define a new option just for FQDN? Will this address the IESG's concern?

Roberta, Mohamed,

Hope that helps.
Tomek

On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta <[email-masked]> wrote:
Hello All,
    I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios.
We really would like to see both of them back in the draft.

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: giovedì 7 ottobre 2010 10.07
To: [email-masked]; Softwire Chairs
Cc: [email-masked]
Subject: [Softwires] DHCPv6 AFTR name option is needed

Dear authors, chairs,

Cheers,
Med

---

From: Ralph Droms <[email-masked]>
Date: Mon, 11 Oct 2010 14:45:47 -0400

(Adding dhc WG chairs to the thread.)

The client behavior in draft-ietf-softwire-ds-lite-tunnel-option-04 did not describe any mechanism in which the client would combine the FQDN from the tunnel option with a suffix in the search list option to form a new name to use as its AFTR, nor did it mention anything about the DNS system doing load balancing.

Given the text in draft-ietf-softwire-ds-lite-tunnel-option-04, there is no advantage to sending an FQDN, so the spec should define only the IP address option.

- Ralph

On Oct 8, 2010, at 1:30 AM 10/8/10, <[email-masked]> <[email-masked]> wrote:

> On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta <[email-masked]> wrote:
> Hello All,

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 07:42:20 +0200

Dear Raplh,

Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? 

Chairs, how should we proceed? The version which passed the WG LC is not the 05.  

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ralph Droms
Envoyé : lundi 11 octobre 2010 20:46
À : [email-masked]
Cc : Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires
Objet : Re: [Softwires] DHCPv6 AFTR name option is needed

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 06:50:07 -0700

> Chairs, how should we proceed? The version which passed the WG LC is not the 05.  

I'm confused.   The current version of the draft is the -05 version, which makes no mention of FQDNs.   You seem to be discussing the -04 version.   Presumably the -05 version is the one that's meant to be published, so why are you discussing the -04 version?

If the name option is needed, then the right thing to do is to issue a new draft.   Since the draft would be substantially changed, and in a way that's contrary to the comments from the DHC working group, this would need to be re-reviewed by the DHC working group, and would need a new last call in the Softwires working group.

It would be entirely inappropriate for such a substantial change to be made during IESG review without further review by the DHC and Softwires working groups, and without another last call.

You would certainly need to explain the use case for the Name option--what value it adds that is missing from the address option.

---

From: <[email-masked]>
Date: Tue, 12 Oct 2010 16:15:38 +0200

Dear Ted, 

The version which passed the Softwire LC is http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which included both name and IP address options.

After IESG review, 05 has been published but this version has significant changes.  

We are at least two service providers who are asking for the need to roll back to 04. If text is needed to justify the need of the name option, for sure we can help.

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 07:26:10 -0700

> We are at least two service providers who are asking for the need to roll back to 04. If text is needed to justify the need of the name option, for sure we can help.

The draft never received any formal review by the DHC working group--the first I heard of it was when Ralph asked me about it recently.

The problem is not that we would or would not somehow grant you permission to use the name option, as if it were a scarce resource.   Rather, it is that the fact that you have both a name option and an IP address option that do the same thing creates an interoperability problem, and that there is no clean way out of that interoperability problem.

If you absolutely have to have the FQDN option, then get rid of the IP address option.    That eliminates the interoperability problem.   In any case, though, you need to issue a new draft.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Oct 2010 12:15:44 -0700

On Fri, Oct 08, 2010 at 05:36:48PM +0200, [email-masked] wrote:
> If there is a real issue with defining two DHCPv6 options (which I don't
> see),

The problem of defining two options that convey the same configuration
point is a problem we call "aliasing."  Section 6 ("Avoid Aliasing") of
draft-ietf-dhc-option-guidelines [1] is dedicated to discuss it, and
concludes with the advice to choose one natural format for the option.

In summary, it causes implementation confusion when the configuration
value for one knob is present in multiple places in the packet - a
resolution algorithm must therefore be defined.  You could say that
one of the IESG criticisms of the AFTR domain name option was that the
normative language to enforce this hierarchy is heavy, and unlikely to
actually be observed by casual implementers.  It creates complication,
and our experience is that complication creates problems.  Worse, in
this case it requires that the individual operator know the normative
requirements of the configuration they write (you are REQUIRED to
provide an IPv4 address, and PERMITTED to also provide a domain name
to clients that support that option).

The only advantage of defining multiple options for the same
configuration value is that such a heavy-handed set of normative
requirements _can_ be defined to ensure that clients are clearly
informed of what the minimum requirements are.

> an alternative would be to define one option with a sub-code field. This
> field indicates whether the option carries an IP address or a name option.

Which is section 5 of the same draft[1], "Conditional Formatting is
Hard."

DHCP software has to be designed to allow the operator and users to
use new options that weren't defined at the time the software was
released - or for example are defined by vendors.  Conditional format
bytes have not entered the mainstream of the mechanisms offered by
today's software, if even one implementation supports such a mechanism
it is unknown to me.

So the use of conditional formatting places adoption of the option on
the 5-year software development cycle, new code must be written to use
the option in both client and server, so it cannot realistically be
touched by mortals until then.

Conditional formatting also removes the question of choice from the
DHCP client software, which often prefers to implement the least that
is required.  Since you cannot enumerate the formats you support, and
you cannot expect a DHCP server to translate formats, a client must
support all formats (and all future formats!).  This means for example
a B4 client that might need a DNS recursive server configuration for
no other purpose than to locate its AFTR endpoint address must carry
along with it a recursive stub resolver specifically for that purpose.

It is a non-starter, in my opinion.

A third option that has been suggested, through the years, is to define
an encapsulated option space - "sub options."  This is a DHCP level
option that contains code-length-values, and so each different format
for the configuration parameter is given a unique code.  This has all
the same problems as the Aliasing problem, except that it offers an
opportunity to define a sub-option code that allows a client to
advertise what options it supports (a sub-option-request-sub-option).
I don't think there are any major criticisms of this approach except
that it again requires new code in both client and server.

[1] Hankins, D., "Guidelines for Creating new DHCP Options",
    draft-ietf-dhc-option-guidelines-05, February 2009.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Oct 2010 12:28:26 -0700

On Thu, Oct 07, 2010 at 10:06:33AM +0200, [email-masked] wrote:
> conveyed in the AFTR name option. This would allow for a more controlled
> load distribution among deployed AFTRs.

In this case, your AFTR FQDN option would no longer be an FQDN.  The
use of the domain search option to locate a not-fully-qualified AFTR
endpoint is not defined.  I would be surprised if this behavior was
general.

But it also sounds like you don't intend on configuration the AFTR
IP address option?  This then does not comply with the earlier
versions of the draft; you would be locking out clients that do not
implement the NAME option.  In order to allow clients to implement
to minimum requirements, servers are required to implement (and
in operation, offer) the IP address...clients are only required to
implement the address option.

Furthermore, if you have the DHCPv6 server infrastructure to deliver
different search paths to clients based upon geo-location, why do you
lack the DHCPv6 server infrastructure to deliver different AFTR
endpoints by IP address?  Surely these are identical problems?  I
suspect you could simply configure the AFTR endpoint location in
the DHCPv6 server by using a domain name, next to the adjusted
search path you wish to advertise.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Oct 2010 12:38:18 -0700

On Tue, Oct 12, 2010 at 07:26:10AM -0700, Ted Lemon wrote:
> If you absolutely have to have the FQDN option, then get rid of the IP
> address option.    That eliminates the interoperability problem.   In
> any case, though, you need to issue a new draft.

As a B4 implementor, I reject the onerus requirement imposed to
contain a DNS recursive stub resolver in B4 equipment, and to
complicate the configuration of the B4 software to be conditional
on the success (through retries) of its resolution.

I will simply not use the IETF standard option in this case, and
continue to configure our B4 elements using a VSIO option.

The address option must be defined.  If a name option must also be
defined, then we must define the strict normative requirements to
permit software to navigate the confusion that having both impose.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 16:47:27 -0700

> on the success (through retries) of its resolution.

I'm highly sympathetic.   But as you so eloquently argued earlier, having both options is not a good choice.   Our initial recommendation was to just use the IP address option, and let the DHCP server load balance or not as its configuration dictates.   This was rejected by Mohamed on the basis that DNS is the right way to do load balancing (a point which I find somewhat questionable).

I would strongly encourage the working group to develop a consensus *not* to use the FQDN option--it adds little value, much complexity, and is usually a deal-breaker for the DHC working group.   The only reason that this didn't get more pushback from the DHC working group is that it was only discussed very briefly there, and we were left with the impression that the FQDN option was going to be removed.   The expected formal request for review of this draft that should have come from softwires never did, so we only realized that the draft was broken when it hit the IESG.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 12 Oct 2010 18:58:11 -0500

Folks,

VoIP protocols in MGCP and SIP have been supporting IP address and FQDN for a long time.  In VoIP deployment with FQDN use, the deployment always keeps a local name resolver.  So why not look carefully at the use cases operators are presenting to advocate use of both FQDN and IP address and then go from there.  I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism.  After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 07, 2010 4:07 AM
To: [email-masked]; Softwire Chairs
Cc: [email-masked]
Subject: [Softwires] DHCPv6 AFTR name option is needed

Dear authors, chairs,

Cheers,
Med

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Oct 2010 17:12:10 -0700

On Oct 12, 2010, at 4:58 PM, Hemant Singh (shemant) wrote:
> I appreciate the feedback on DHCPv6 design style to not use two entities to represent the same primitive but if DHCPv6 is such a stick in the mud, we could go with some other control mechanism.  After all several protocols use FQDN and IP address interchangeably and the deployments are working fine. 

You've hit the nail on the head, Hemant.   Custom protocols have no trouble with this.   It's because DHCP is a general-purpose protocol that this becomes a problem.   If you want a custom protocol, you should define a custom protocol.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 12 Oct 2010 20:13:35 -0500

A general question.  If 6rd could become an RFC in RFC 5969 with no
mention of FQDN for the BR, what is so special about DS-Lite and
deployments that a FQDN is needed by DS-Lite for the AFTR?  I would
think the same FQDN issue would arise in 6rd as well... What did I miss?

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, October 12, 2010 1:42 AM
To: Ralph Droms;
[email-masked]
Cc: Ullio Mario; Chairs Dhc; [email-masked]; Softwire Chairs;
Softwires
Subject: Re: [Softwires] DHCPv6 AFTR name option is needed

Dear Raplh,

Do you suggest the I-D should elaborate further on the FQDN use cases so
this to be acceptable by the IESG? 

Chairs, how should we proceed? The version which passed the WG LC is not
the 05.  

Cheers,
Med

---

From: Washam Fan <[email-masked]>
Date: Wed, 13 Oct 2010 09:20:26 +0800

Hi Hemant,

As I know, since 6rd BRs are stateless, so you can configure an
anycast address for load balancing stuff.

Thanks,
washam

---

From: <[email-masked]>
Date: Wed, 13 Oct 2010 08:49:47 +0200

Dear David,

If we adopt the sub-option scheme with the following values:
   1    AFTR IP Addres
   2    AFTR Name 

And if the language is clear to state the client must include both IP address and name sub-options and the Server MUST answer with only one sub-option (IP address or name sub option). Is there any aliasing problem in such case?

I went through http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-06#section-8 and the main reco of that section is 

"it is not advisable to group options that may not be
   requested at the same time by the same client under an encapsulated
   space."

Which is not the case of the aftr option.

Cheers,
Med

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 13 Oct 2010 09:52:05 -0500

Washam,

Got it, thanks.

Hemant

-----Original Message-----
From: Washam Fan [mailto:[email-masked]] 
Sent: Tuesday, October 12, 2010 9:20 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; Ralph Droms;
[email-masked]; Softwires;
Chairs Dhc; [email-masked]; Softwire Chairs; Ullio Mario
Subject: Re: [Softwires] DHCPv6 AFTR name option is needed

Hi Hemant,

Thanks,
washam

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2010 08:33:01 -0700

> If we adopt the sub-option scheme with the following values:

Mohamed, Roberta, you seem to have a very strong opinion that is based on the principle "someone insists that we have this."   I have to ask: what is your goal here?   Is your goal to publish an RFC with your name on it that does what you want, even though probably no-one will implement it because it requires code changes to both the server and client?   Or is it to get something that works, and can be used?

If it's the former, then by all means, ignore our advice.   If it's the latter, you might want to consider listening to the advice you're getting.   The point of the advice is not to be authoritarian or arbitrary.   It's to encourage you to write a spec that will be implemented and widely deployed, because it will require no code changes on DHCP servers or clients.

David's suggestion to use suboptions wasn't necessary.   You can use both FQDN and IP address, and just require that the client request both.   The problem with this is that you gain nothing over just doing FQDN in this case, since the client must implement a resolver in case the server doesn't send the IP address option.

I think you are driving very hard for a Pyrrhic victory.

---

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

> Thank you for this clarification.

I think you may have misunderstood - I did not mean that the IESG's
main complaint was with the complex normative requirements, I meant
that this would be a fair way (I hope) to assess the motivations that
inspire the complaint.  The direction was pretty clear that we needed
to drop one of the two formats.

"Alias" options are not technically impossible.  I can point to a few
RFC's that describe options with partially overlapping or completely
aliased configuration state - just providing different formats.  They
are "IETF improbable" because of the complexity required in their
implementation - collectively, we are wary that people will actually
follow the (important) directions we include in our protocols, or that
we'll even be able to write appropriate directions to begin with.

I don't see a way to retain the two formats without also requiring the
complex normative requirements (on operators writing their
configurations!) as we did in -04.

> Which is not the case of the aftr option.

Sub-options are more of a way to encode multiple configuration values
of variable length, wherein if the client requests one of the options
it is a given the client must also receive the others in order to work.
I can't think of an example of this off the top of my head.

But the crux of it is that the server will reply with the entire
encapsulated space.  This isn't really a problem tho, particularly
in DHCPv6, because it's just a space optimization issue.  It also
doesn't work around the problem of client implementation of the
different formats.  We would still have to require that one of the
formats always appears from the server (the simplest, the address
option), that the client always supports the simplest option and at
its option implements the other formats, and then we'd still wind up
with the situation where the client gets the IPv6 address of its AFTR
endpoint -and its name- and then goes through all that resolution work
to find out if there might be a different address to use.

I mostly included the sub-option mechanic as a third option to be
complete.  It is a habit of mine to enumerate issues to enunciate
that we are not arguing a false dichotomy.  There is a real dichotomy
here - address or FQDN and not both - centered on the discussion of
the acceptance (or rejection if you prefer) of complexity in DHCP
option format standards.

-- 
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: Maglione Roberta <[email-masked]>
Date: Thu, 14 Oct 2010 10:13:36 +0200

Hi Ted,
    I am not one of the authors of this draft, thus my final goal is not to publish an RFC with my name. As Service Provider I come to IETF to find standard and interoperable solutions that would fit my deployment scenarios.

I fully respect technical advices provided by technical people like you, my point is that IETF community should work with Service Providers to find solutions that both fulfill our requirements and they don't break existing stuff. In the specific case being able to provide load-balancing and redundancy in DS-Lite scenario is a requirement for us, thus I would like to see a solution for this coming from IETF.

Best regards,
Roberta

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Oct 2010 19:42:24 -0700

On Oct 14, 2010, at 1:13 AM, Maglione Roberta wrote:
> In the specific case being able to provide load-balancing and redundancy in DS-Lite scenario is a requirement for us, thus I would like to see a solution for this coming from IETF.

So your requirement is to have load balancing, not to have DNS, correct?