Subject: Summary: DC meeting question #1

From: "Michael W. Carney" <[email-masked]>
Date: Mon, 29 Nov 1999 16:30:03 -0500 (EST)

Hi folks,

I've sifted through the WG alias traffic for messages addressing this
question,
and I'll attempt to summarize. The question that was asked was:

Seeking examples of releasable resources. An IP address is one.
Others? When would they be released?

The consensus was while there are not ready examples of releasable
resources
over and above IP addresses, it was an useful exercise to consider
generic
releasable resources and what their semantics are. I've attempted to
summarize
what's been discussed, and take a stab at filling in holes:

Semantics of releasable resources:

1) General Form

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

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

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

2) How 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.

    *	Clients MUST request releasable resources, otherwise the server
	will not allocate them.

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

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

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

3) Multiple Server Environments

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

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

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

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

--

Mike Carney

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Nov 1999 13:39:22 -0500 (EST)

Mike,

I've got some clarification questions.

>     *	There is a generic bit in the extensions header which is set if the

Clarification: are you saying the list discussion is arguing for such
a bit? Or that one will go into the draft? Or? (I don't recall the
current draft having such a bit.)

> 	extensions are defined which are releasable.

I believe the above is a goal. Are you saying that this goal has
already been achieved?

>     *	Servers advertise releasable resources. We (WG) need to consider how

>     *	A client can renew releasable resources w/ allocating server, after

This points out another question. The IP address extension has valid
and preferred lifetimes. Presumably all releasable resources would
need to have an associated lifetime. Shouldn't all releasable resource
extensions then have a somewhat standard format so that clients can
find the lifetime information in a standard place? (I don't recall the
current draft doesn't mentioning this.)

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

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

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

I still don't understand what multi-server aspects we need to
address. I think this is an important question that needs to be
resolved. In some earlier messages, it was pointed out that having a
client get conflicting information from different servers and then
requiring the client to somehow prioritize which information to use is
a hard problem. I agree. However, not addressing the problem makes it
pretty hard to claim that the protocol works in a multi-server
environment. Before deciding whether to solve or not solve this
problem, we need to decide whether the problem needs to be
addressed. I.e., do we think this problem is important?

For clarity, I'm talking about the multi-server case where there are
two different servers with different parameters/resources and the
client is required to communicate with both in order to get all the
information it needs.

> 	* 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 on the server to determine when an extension is returned
> (because of administrative policy, or because client requested it?).
> endeavor to clarify the semantics in DHCPv6.

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

I'm not sure the server preferance field should be used for this. My
understanding of the preference field was that it was to be used to
select the "highest priority" server a collection of servers, where
all of the servers in the set are equivalent (i.e., any of them
returns correct information). These servers presumably have the same
information and are administered by the same organization. But the
multi-server problem I mention above also occurs when the multiple
servers are not under the same administrative domain. i.e., it
wouldn't make sense to compare server preferences because they are
assigned idipendently by the different domains.

Thomas

---

From: "Michael W. Carney" <[email-masked]>
Date: Tue, 30 Nov 1999 18:49:03 -0500 (EST)

Hi Thomas,

> I've got some clarification questions.

Sure.

> current draft having such a bit.)

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.

General support for releasable resources would require a general method
of communicating between client/server that the resource described in
the extension was releasable. That's what the bit is used for, along
with the lease times. Thus, releasable resources would have a have a
general extension format (A bit in the header which clues the
implementation that
the two lease/lifetimes is present).

Perhaps "summarize" was a poor choice of words.

> I believe the above is a goal. Are you saying that this goal has

No, although this message's purpose was to propose semantics of such
extensions in pursuit of that goal.

> current draft doesn't mentioning this.)

Exactly my point! That's the first bullet in #1, General form.

> addressed. I.e., do we think this problem is important?

It is important in DHCPv4 land, and it is just as important in DHCPv6,
IMHO. See Miscellaneous, second bullet, where I discussed Erik's issue
in detail.

> assigned idipendently by the different domains.

That's true - this breaks down in multi administrative domains. However,
the primary interface concept does not. What do you think of this
concept?

-- 

Mike Carney