Subject: [dhcwg] SOFTWIRE WG LC: http://tools.ietf.org/html/draft-dhankins-softwire-tunnel-option-05

From: David Ward <[email-masked]>
Date: Thu, 4 Feb 2010 08:49:19 -0800

All -

We'd like to announce the WG LC on a DHCP option required for DS-Lite technology in the SOFTWIRE WG. I've copied both SOFTWIRE and DHC mailing lists and solicit comments from both groups of experts. The draft is here:

http://tools.ietf.org/html/draft-dhankins-softwire-tunnel-option-05

Please reply with comments to this thread by 2010.02.19 at 1700 PST

Thanks

-DWard

---

From: David Ward <[email-masked]>
Date: Thu, 4 Feb 2010 12:46:02 -0800

It's a SOFTWIRE WG doc but, hasn't been updated. It's title will be reflected but, the tools machine hasn't caught up.

-DWard

On Feb 4, 2010, at 2:15 PM, Behcet Sarikaya wrote:

> Hi David,
>   I did not know if a WG LC can be made on an individual draft?
> 
> Regards,
> 
> Behcet
> 
> 
> 
> ----- Original Message ----
>> From: David Ward <[email-masked]>
>> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
>> Cc: David Ward <[email-masked]>; Ralph Droms <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
>> Sent: Thu, February 4, 2010 10:49:19 AM
>> Subject: [dhcwg] SOFTWIRE WG LC: http://tools.ietf.org/html/draft-dhankins-softwire-tunnel-option-05
>> 
>> All -
>> 
>> We'd like to announce the WG LC on a DHCP option required for DS-Lite technology 
>> in the SOFTWIRE WG. I've copied both SOFTWIRE and DHC mailing lists and solicit 
>> comments from both groups of experts. The draft is here:
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 
> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Feb 2010 12:15:54 -0800 (PST)

Hi David,

Regards,

Behcet

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 04 Feb 2010 16:54:11 -0500

The Tombstone was missing, the actual draft under last call is available
http://www.ietf.org/id/draft-ietf-softwire-ds-lite-tunnel-option-01.txt
I apologize for the confusion. The Softwire WG last call deadline remain
2010.02.19 at 1700 PST

   - Alain, the other co-chair

On 2/4/10 3:46 PM, "David Ward" <[email-masked]> wrote:

>>> >> Cc: David Ward <[email-masked]>; Ralph Droms <[email-masked]>;
>>> "[email-masked]" <[email-masked]>;
>>> "[email-masked]" <[email-masked]>
>>> >> Subject: [dhcwg] SOFTWIRE WG LC:

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 5 Feb 2010 08:41:52 +0700

Looks OK to me.

Hope this helps.

~gwz

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Ward
> Sent: Thursday, February 04, 2010 11:49 PM
> To: [email-masked]; [email-masked]
> Cc: David Ward; Ralph Droms; [email-masked];
> [email-masked]
> We'd like to announce the WG LC on a DHCP option required for DS-Lite
> technology in the SOFTWIRE WG. I've copied both SOFTWIRE and DHC mailing
> lists and solicit comments from both groups of experts. The draft is
> here:
>

---

From: Paul Selkirk <[email-masked]>
Date: Mon, 8 Feb 2010 22:44:08 +0000 (UTC)

draft-ietf-softwire-ds-lite-tunnel-option-01.txt

I have read the draft, and support it on its technical merits.
However, it could use a bit of word-smithing.

The biggest thing is that the Address option is a MUST, and the Name
option is a MAY ALSO:
   A client that supports B4 functionality of the DS-Lite (defined in
   [draft-ietf-softwire-dual-stack-lite-02]) MUST include
   OPTION_DS_LITE_ADDR on its OPTION_ORO, and MAY include
   OPTION_DS_LITE_NAME at its option and ability.

I'd have expected to see the two options on an equal footing, where
clients could request one or the other without prejudice, but probably
wouldn't request both.

Further:
   If the client requests and receives both the OPTION_DS_LITE_ADDR and
   the OPTION_DS_LITE_NAME, it MUST proceed with resolving the
   OPTION_DS_LITE_NAME.

This says that the Address option is a throw-away in this context.
i.e. There's no reason to request the Address option in this context,
except that this draft mandates it.

I'd suggest something like:
   A client that supports B4 functionality of DS-Lite MUST include
   either OPTION_DS_LITE_ADDR or OPTION_DS_LITE_NAME on its
   OPTION_ORO.  If the client requests and receives both
   OPTION_DS_LITE_ADDR and the OPTION_DS_LITE_NAME, it MUST proceed
   with resolving OPTION_DS_LITE_NAME.

I'm not overly enthusiastic about resolving the conflict in favor of
the Name option, but there should be some deterministic resolution
mechanism.

On to the language nits...

It's "DS-Lite", not "DS Lite" or "the DS-Lite".

In most places, the latest draft changed "option" to "DHCPv6 Option".
I'm not sure this is really necessary.

This draft is tied much more closely to the terminology of DS-Lite
than previously, e.g. Softwire Initiator -> B4 element, Softwire
Concentrator -> AFTR element.  However, the options are still called
"The Dual-Stack Lite Softwire Concentrator Address DHCPv6 Option" and
"The Dual-Stack Lite Softwire Concentrator Name DHCPv6 Option".

For simplicity (and being able to say them in one breath), I'd 
suggest "The Dual-Stack Lite Address DHCPv6 Option" and "The
Dual-Stack Lite Name DHCPv6 Option".

Related to this, the Abstract goes half way:
   This document specifies two DHCPv6 Options which are meant to be used
   by Softwire Initiator (SI) to retrieve its attached DS-Lite AFTR
   (Address Family Transition Router).

I'd suggest something like;
   This document specifies two DHCPv6 Options which are meant to be
   used by a Dual-Stack Lite client (Basic Bridging BroadBand element)
   to discover its AFTR (Address Family Transition Router) address.

Section 2, 4th paragraph says:
   This document assumes that the SI is provided with appropriate
   instructions for the activation of an IPv4-in-IPv6 scheme which is
   supposed to be supported in both B4 and AFTR.  Consequently, this
   memo does not precise the IPv4-in-IPv6 encapsulation scheme to be
   used by B4.

In additon to "the SI" (a term that has been stripped of context) and
"precise" (prescribe?), this paragraph could be a lot more direct, e.g.
   The details of how the B4 establishes an IPv4-in-IPv6 tunnel to the
   AFTR are out of scope for this document.

In 3.1, it's not necessary to spell out Address Family Transition
Router a third time.

In 3.1 and 3.2, you say "Below is provided the description of the
enclosed fields:".  Not only is the language tortured, it's frankly
unnecessary.

At the end of 3.1, you say:
   The definition of this option is simple and encloses only a single
   IPv6 address.  It is temping to define a flexible option which may
   convey several IPv6 addresses (for robustness and service
   availability reasons), but for the sake of simplicity and consistency
   it is recommended to use a FQDN Option instead of conveying several
   IPv6 addresses.

This could be interpreted as a recommendation to use the FQDN option
instead of the Address option.  Perhaps something like:
   For the sake of simplicity, this option conveys a single IPv6
   address.  If you want to convey multiple IPv6 addresses, you should
   instead use the Dual-Stack Lite Name option, where the DNS name
   could resolve to multiple addresses.

In 3.2, the caption for Figure 2 says "DS-Lite FQDN DHCPv6 Option".
Change to "DS-Lite Name DHCPv6 Option".

In section 3.2, I'm not sure you need to say anything on the subject
of redundancy of high availability.

In section 4 (line 352), change FDQN to FQDN.

				paul

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Feb 2010 17:38:43 -0800

> clients could request one or the other without prejudice, but probably

The problem with placing the options on equal footing is that the
NAME option clearly requires a great deal more software, in addition
to extra packet transmits (and RTT's) to perform DNS resolution.  So
for the benefit of devices where both of those are an issue, the idea
is to require all clients and servers to implement the ADDR option,
the smallest common denominator.

Whether or not servers are configured with ADDR options when their
operators have NAME options configured is an unfortunate minor side
issue.

But it is generally easier for an operator to configure an extra value
when encountering such a client than it is to put extra software or
more batteries in a client that can't implement the NAME option.

> except that this draft mandates it.

That is correct; but it's a conclusion of the above discussion, so we
need to get closure there first.  Because the client will request
either the ADDR option or both options, it must select one above the
other.

In my opinion, because the resolution by DNS after DHCPv4 completes
takes extra RTT and relies on client implementation, an operator
wouldn't configure the NAME option unless the resolution by DNS on
the client end conferred some benefit (without speculating on those
benefits).  Noting that the ADDR option may be configured as a DNS
name in the server's configuration (resolved via DNS to be provided
in the DHCPv4 response), there really has to be some benefit to the
operator for the clients to be performing DNS to resolve this value
(the place resolution is performed is more important than the data
since otherwise it would be the same data).

So if a NAME option is provided, it is considered the operator's
intent for it to be evaluated.  Because all clients implement (and
request) the ADDR option, operators that do not see a benefit in
client-side DNS resolution can simply omit the NAME option from
configuration, and those clients will receive the configured ADDR
option they are required to supply.  It's a minor problem that they
really must include an address option in configuration but may not
know this.

>    with resolving OPTION_DS_LITE_NAME.

You have incorrectly placed the locus of the determination of "which
option should the client use?"  It does not rest with the client in
my opinion (above), it rests with the server operator.

The only way to give the server operator that power is for the clients
to request all the options they support, in the order they think they
should be prioritized in the packet, and let the server determine
which ones to provide or withhold.

So we're requiring the ADDR option be implemented for reasons above.

That limits the client's options to supplying only the ADDR option or
both the ADDR and NAME option.

There is a side-issue that was brought up earlier that I want to give
a more detailed answer to; the problem that providing both data values
in response is not optimal (wastes space).

One suggestion was to update Server behaviour so that the Server sends
only one of the two options at its preference if both were requested.
The problem with this is that it is specific to these particular two
options.  The problem of option aliasing is not a new one to DHCP, we
have many other option codes that alias information provided by each
other.  A generic solution, extending the DHCP protocol rather than
encoding prioritization in the servers is desired.

One approach suggested to DHC WG some time ago by Ted Lemon is to
"markup" the PRL with two otherwise unused option codes that bracket
options of which the client only wants one.  This optimizes the data
sent to the client, but makes client prioritization slightly more
cumbersome to instrument (e.g., a client may want OPTION_DS_LITE_ADDR
before OPTION_NAME_SERVERS, but OPTION_DS_LITE_NAME after as it's
useless without it; this may be a contrived example that is not a
general problem).

But I digress.

The point is although that particular way may not be the way the
problem is finally approached, it illustrates that this is
considerably a "protocol" problem and not a "data" problem, and that
we have at least one "protocol" solution if or when the issue of
redundant data in the DHCPv4 packet options space becomes an issue.

> On to the language nits...

I will have a look at these separately, I don't see anything offhand
that is an issue correcting.

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