RE: High Availability DHCPv6

Inline.
 
John
========================================= 
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowskicable.comcast.com
<mailto:john_brzozowskicable.comcast.com> 
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=========================================

________________________________

From: David W. Hankins [mailtoavid_Han
kinsisc.org]
Sent: Wed 2/28/2007 2:16 PM
To: dhcwgietf.org
Subject: Re: [dhcwg] High Availability DHCPv6



My main concern (which I see now I edited out), is that
we're
all very easily excited (myself included) at the prospect
of creating a new architecture of high availability.

But complexity is a price that must be justified by demand.

I want to know what the underpinnings of DHCPv6 'HA Demand'
are before we talk about the merits or failings of any one
design.

[jjmb] I agree that doing this just to do is not wise. 
Something also worth noting is that failover is not
precluded, in fact, DHCPv6 failover must also be considered.
 Points of view on benefits and failings may vary.  From my
point of view some benefits could be reduced complexity for
implementation and management as well as maxmizing server
resources.  There may be other benefits as well as
drawbacks.  In fact it is probably fair to say that there
are pro's and con's to any solution.

That's what I set out to say anyway.


I think IA_PD is an unknown, and at least one outcome is
that prefixes will be 'assigned' to customers rather than
dynamically allocated by the DHCP server.  No need for an
HA overlord there.

[jjmb] DHCP PD is unknown in what sense?  Manual allocation
will not scale and I do see DHCPv6 being quite important for
the dynamic allocation of prefixes.  Given this an HA
solution will too have to account for PD.

DDNS is quite possible with multiple servers, not sure what
you're hinting at.  RFC4073's example gives it away for
free.

[jjmb] I assume you meant to refer to rfc4703?

"stateful relays" are a non-starter already.  We
need to
define the way these things will work to start
with...leasequery
without bulk updates clearly doesn't cut it...so we don't
know
if that method will work well or poorly with existing
protocol's
fault tolerance.  In this case, let's hatch the egg before
we
fry the chicken?

[jjmb] I agree that hatching this first makes sense and is
largely the reason why I sent the original email.  Stateful
relays, what are you referring to?  Also, are you saying
that there needs to be some mechanism for retrieving lease
data in bulk or are you saying it is not required?  If the
former, there was a some good work that was done as part of
the original DHCPv6 Leasequery ID which could be recycled. 
Perhaps we should also revisit the topic of bulking
leasequery, soon.

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



_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

On Mon, Mar 19, 2007 at 09:01:22AM -0400, Brzozowski, John
wrote:
> I think IA_PD is an unknown, and at least one outcome
is
> 
> [jjmb] DHCP PD is unknown in what sense?

We don't know how it's going to be "actually used"
yet.

> [jjmb] Manual allocation will not scale and I do see
DHCPv6 being quite important for the dynamic allocation of
prefixes.  Given this an HA solution will too have to
account for PD.

There's manual, and then there's "not by the dhcp
server."

I hope that most networks would automate the process through
which
"customers" are sold "products."

I think whatever device serves that function (or human if
that's
really what you want...) could wind up being what allocates
a prefix
to a customer.

So although having humans assign prefixes to customers
probably
doesn't scale, I should also mention that the converse -
allocating
prefixes to clients dynamically - possibly doesn't scale
either,
or a client could exhaust a server's pool of prefixes very
easily
(not true of addresses any more).

> [jjmb] I assume you meant to refer to rfc4703?

Yup, typo.

> [jjmb] I agree that hatching this first makes sense and
is largely the reason why I sent the original email. 
Stateful relays, what are you referring to?

Anything that needs to re-fetch client state in order to
operate, such
as via a leasequery message or similar.

> Also, are you saying that there needs to be some
mechanism for retrieving lease data in bulk or are you
saying it is not required?

I think that the abdications the v6 leasequery authors made
at the
behest of the WG were good - as described the mechanisms
were just
too complex for DHCPv6/UDP.

I also think that in so doing, the solution no longer fits
the
requirements.  A relay in such a network can no longer
recover
the state which leasequery is designed to deliver.

This turns the existing leasequery message into an
administrative
tool I think.

> [jjmb]  If the former, there was a some good work that
was done as part of the original DHCPv6 Leasequery ID which
could be recycled.  Perhaps we should also revisit the topic
of bulking leasequery, soon.

Could be.  I think there are about 4 solutions on the
table.

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

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg