Subject: Re: Summary: DC meeting question #1

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 1 Dec 1999 17:26:08 -0500 (EST)

Hello Mike,

I hope you don't mind if I put spaces in different places in your
reply.  It helped me to read your note better, and to read my responses
to your note better too.

> 1) General Form
> 
>     *   Releasable resource extensions need to have a general form so that
>         clients/servers can manage them in a generic fashion.

Sounds good.

>     *   There is a generic bit in the extensions header which is set if the
>         extension is carrying a releasable resource. When this bit is set,
>         there are two 32 bit fields present in the extension which represent
>         the relative times in seconds when the client should start attempting
>         to extend the lease on the resource, and when the client must stop
>         using the resource if it is unable to extend it.

In Minneapolis, the suggestion was made that one range of extension
types was releasable, and that the rest of the extension types were
nonreleasable.  There seemed to be some general approval for this idea;
I don't remember who proposed it.

If the extensions from 32767-65535 were reserved for releasable
resources, that would work.  There could be a section in the
document prescribing a format for these extensions, but in general
I think that clients that ask for releasable resources can be
expected to know a lot about those resources.  Thus, working out
a general format for these future extensions may not be overwhelmingly
necessary right now.

>     *   Since extensions carrying releasable resources have a general
>         form/semantics, clients/servers do not need to change when new
>         extensions are defined which are releasable.

I don't totally disagree with this statement, but as I just
described it seems likely that consuming a releasable resource
implies some other systemic changes in the client that are more
fundamental than any standardized message format.

 are they allocated/requested, and how and to whom are they
> released?
> 
>     *   Servers advertise releasable resources. We (WG) need to consider
>         how releasable resources are advertised.

If a client really requires a particular releasable resource, we
should allow it to append an extension to its solicitation, with
the meaning that it wants an advertisement from a server that can
offer the resource.
 
>     *   Clients MUST request releasable resources, otherwise the server
>         will not allocate them.

This matches the general agreement I remember from Minneapolis.

>     *   Servers allocate releasable resources for a period of time set by
>         administrative policy

Check.

>     *   A client can renew releasable resources w/ allocating server, after
>         the first timer expires. If unable to contact the server, the client
>         must stop using resource when second timer expires.

Check, according to the proposed generalized scheme.  We should allow
for possible variations depending upon the particular resource that
is eventually designed for allocation by way of DHCP.  If a client
needs a "sophisticated" resource, we shouldn't proscribe such
sophisticated
clients from getting service from suitably sophisticated servers.

>     *   A client SHOULD release releasable resources to the allocating server.
>         If it fails to contact the allocating server, it MAY locate another DHCP
>         server and attempt to release them. In any case, the server will recover
>         the resource when its lease has expired. Thus, like DHCPv4, releasable
>         resources (addresses) will ultimately be reclaimed as administrative
>         policy dictates, and it isn't critical for clients to contact the server.

Check.

> 3) Multiple Server Environments
> 
>     *   Servers advertise available IP address(es) and other releasable
>         resources, thus clients know what resources are available from which
>         server.

Agreed, but in response to specific client requests only.  Otherwise,
the advertisements could get pretty long.  Case in point, what if a
server had to advertise every prefix from which it could allocate
addresses?  Or every disk farm from which it could allocate scratch
space?  Or ...?

>     *   We should avoid over specifying how DHCP works within multi-server
>         environments. However, an introductory/scenario section w/ a protocol
>         timeline would help validate the protocol model, and give some guidance
>         to implementors where needed.

Check.

> Miscellaneous:
> 
> *       I think we do need an "extension request extension" - having such an
>         extension would simplify the advertisement of informational extensions,
>         as well as simply a client's method for requesting extensions.
>         Note: We need to specify that a policy switch should be available
>               in the server to determine when an extension is returned (because
>               of administrative policy, or because client requested it?).
>         This point has been a bone of contention in DHCPv4, and we should
>         endeavor to clarify the semantics in DHCPv6.

Agreed on the suitability of such an extension for this purpose.

> *       Erik raised an interesting point about application layer extensions on
>         machines multiple interfaces: If you have multiple NTP servers 
>         available from DHCP information from different interfaces, which one
>         do you select? In our (Sun's) DHCPv4 client implementation, we have
>         a notion of a "primary" interface, from which application
>         layer parameters take precedence over those set in other interfaces.
>         It seems to me that a similar DHCPv6 implementation strategy could
>         resolve this issue. Charlie suggested that the server preference
>         value be used to determine preference. His suggestion has the
>         advantage that preference is set by the administrator. I prefer
>         the former solution ("primary" interface).

Perhaps for extensions where it actually matters, the preference could
be a field of the extension itself.  My original suggestion was just
on the spur of the moment, and not made with very much real study.
Letting the client decide is probably O.K. in most instances, I reckon,
so if it always decides in favor of a "primary interface", no harm is
likely to be done.

Regards,
Charlie P.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 2 Dec 1999 07:43:24 -0500 (EST)

At 06:49 PM 11/30/99 -0500, Michael W. Carney wrote:
>The discussion clearly showed that support for releasable resources was 
>something that the WG wanted. That said, what would be the semantics
>that would resolve the issues raised during the discussion of this
>question? It is this point I'm attempting to address.

Mike - Which discussion are you referring to, here?  IMO, we initiated
the discussion of releasable resources on the mailing to explore the
complexity of adding support to DHCPv6 for releasable resources, so we
could make an informed engineering decision about whether or not to
incorporate releasable resources into the spec.  We have had a good
discussion about how releasable resources might work and how they might
be supported in DHCPv6, but I don't think we've had an expression of
consensus about whether we want to go ahead and add releasable resources
to the spec.

- Ralph

---

From: "Michael W. Carney" <[email-masked]>
Date: Thu, 2 Dec 1999 20:07:14 -0500 (EST)

> consensus about whether we want to go ahead and add releasable resources

I fear I may have jumped ahead alittle. You are right. I believe are
close to having the semantics completely defined such that general
support for releasable resources is possible.

Those semantics are:

Either one of the following:

a) Extensions all have a "generic" header portion of which there are
bits which are present in all extensions. One such bit would indicate
that the resource carried in the extension is releasable, and that there
are two fields in the extension (a'la lifetimes in the IP address
extension) which represent the "preferred" and "absolute" lifetimes
represented in seconds relative to the transaction. (now).

b) A range of extensions is carved out and used for releasable
extensions. The fact that the extension is releasable is a
characteristic of the extension's code value.

Client implementations (scheme a or b)
 
	- Must request releasable resources - via extension request extension
in solicit.

	- Will track owner of such resources and SHOULD release them to the
allocating server, and MAY release them to another server if the
allocating server is unreachable.

	- A client will attempt to update the lifetimes on the releasable
resource if necessary. However, if the lifetimes expire, the resource
must be considered no longer usable. There's an interesting point -
since the DHCP client won't deal with most releasable resources, it will
not have control over whether or not a resource continues to be used
when the lifetime expires, whereas it certainly has control over IP
addresses acquired through DHCP.

	- A releasable resources can be reconfigured (again, the client
probably won't have the necessary control of the resource in order to
prevent its use, with the current exception of IP addresses).

Server implementations (scheme a or b)

	- Must have a generic mechanism for dealing with releasable resources.

	- A server will only advertise releasable resources if the client
requests it to do so in the Solicit.

	- A server controls a client's access to releasable resources based
upon the lifetimes associated with these resources. 

So I think this is mostly it in summary. The potential inability of the
client to enforce access to expired releasable resources is an issue.

If folks believe I've covered the required semantics / caveats of
general releasable resources, the question is: Do we try to specify
general releasable resources now, or should we defer till later if we
find them useful?

-- 

Mike Carney

---

From: "Michael W. Carney" <[email-masked]>
Date: Thu, 2 Dec 1999 20:05:41 -0500 (EST)

> reply.  It helped me to read your note better, and to read my responses

Great, thanks for your comments.

> a general format for these future extensions may not be overwhelmingly

Yes, I remember this suggestion. I'm fine with reserving some range of
extension codes for releasable resources.

> fundamental than any standardized message format.

Not having to change a client when a new extension is drafted was
something that was specifically requested in Minneapolis, specifically
the "releasability" of a resource.

> the meaning that it wants an advertisement from a server that can

Or use the "extension request extension" (as you pointed out, we need a
better name).

> addresses?  Or every disk farm from which it could allocate scratch

Or request that such resources be advertised via the Solicit.

> so if it always decides in favor of a "primary interface", no harm is

I agree. Erik?

-- 

Mike Carney