[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] draft-ietf-dhc-dhcpv4-bulk-leasequery-01.txt
On Monday 26 October 2009, Kim Kinnear wrote:
Comments inline
> I've submitted a new version of the DHCPv4 Bulk Leasequery
> draft today.
>
> >4) Section 7.2.2 proposes dhcp-message formats that are somewhat
> >confusing: it specifies constrained format 3 character ASCII field where
> >the characters must be base10. As the table appears to be simple
> >incrementing error codes I would suggest an simple 16-bit result code
> >and associated table vs the left-, middle-, right-number format in
> >7.2.2. I do not think we should overload option 56 for error messages as
> >currently opt 56 is defined for text to display to end-client. I don't
> >see any harm in creating a new DHCP option for lease-query to convey
> >server-to-relay errors/results (ie, as done with the base-time and
> >start-time-of-state messages).
>
> This is not a particularly big deal either, but I did not
> change to a new option for status codes and messages.
>
> I resisted this admonition largely because this
> particular use of option 56 is solely within the DHCPv4
> bulk leasequery interaction. Without some definition of
> how to use option 56 in a bulk leasequery, it has
> essentially no meaning at all -- so I don't see the
> conflict with "option-56 is defined for text to display
> to [an] end-client". This isn't a DHCP client <-> DHCP
> server interaction (in the sense of a DHCP client who
> want's an IP address). This is an entirely orthogonal
> interaction concerning DHCP.
>
> Given that we are moderately short of options in the
> global DHCP option space (though less than we once were,
> of course), it seems wasteful to define a new option for
> use in bulk leasequery when we can use an existing option
> simply by more closely specifying the values that it may
> contain.
Hmm, both arguments seem reasonable.
But I have to wonder, is this now our standard operating procedure for DHCPv4,
to always overload options just because it's technically feasible?
On a side note, why is it difficult to expand the DHCPv4 option space?
Subencoded options are in their own number space. UTF-8 encoding was created
as a superset of ASCII. It seems possible.
> But if this is a major impediment to moving the draft
> along we can certainly define a new option for bulk
> leasequery and use up another number.
>
> >5) I dont think we should mix absolute and relative time scales in the
> >same single message. As currently proposed base-time is an absolute time
> >and all other time values are offsets from this base-time option. Is
> >there a way we can avoid absolute times all together thus avoiding the
> >need for time sync between relay and DHCP server? Given the leasequery
> >returns things like lease (which are timers) could we not get away with
> >returning the remaining lease time? I'm not sure I can appreciate value
> >in the relay agent knowing what the original lease time was.
>
> There are two reasons to have one absolute time in the
> messages. First, if you care about accuracy, having the
> absolute time in the message tells you the delay in
> sending, transmitting, receiving, and processing the
> message. This will allow you to develop (if you wish) a
> much more accurate sense of the time skew between the two
> machines and, because of that, a much more accurate set
> of time values.
>
> Second, if you are going to support query times (see
> below), then you need the absolute time in the context of
> the DHCPv4 server.
I have no problem with absolute times.
> >6) With section 7.2.5/7.2.6 I feel we are overcomplicating the query
> >with time ranges. Why would a relay agent not want to recover all leases
> >- further this requires a DHCP server to maintain an explicit
> >last-modified time for every lease.
>
> The cost of sending information concerning all of the
> lease can be quite large. It may be necessary to scan
> all of the IP addresses configured in the server in order
> to do any of the bulk leasequery operations -- and that
> can by itself be a load on the server. Having to use
> the network bandwidth to send it all back when it is
> unnecessary seems ... unnecessary and possibly
> prohibitively expensive.
>
> A relay agent may well have saved information to stable
> storage and be only interested in changes since a certain
> time. Beaing able to ask for only what the relay agent
> wants can make the load on the DHCP server, the network,
> and the relay agent much much less than it would
> otherwise be. In very little cost of complexity.
>
> We could certainly implement this as an add-on to bulk
> leasequery in vendor independent options, but I think that
> there is general utility to being able to do this.
Please do not push this towards vendor independent options. I think time
ranges are a great idea.
>
> ------------
>
> Regarding keeping the last modified time for a lease,
> RFC 4388 already defined the client-last-transaction-time.
> We are just using it again here.
>
> >7) The states RELEASED, ABANDONED, RESET suggest the server keeps state
> >of leases that have expired - I can see that this is a function of the
> >time-based query - but it puts a huge burden on a DHCP server.
>
>
> I would think most servers would do this because it is
> part and parcel of how most vendors implement some form
> of increased availability. But if you don't keep this
> information it doesn't invalidate that value of time
> oriented queries from the relay agent.
I generally find that any state not explicitly recorded can be easily
calculated on demand.
> See point
>
> >6 wrt returning all valid leases. These time-bound queries could lead to
> >out-of-sync problems between server and relay and as the motivation
> >appears to be state recovery it seems pragmatic to return all state
> >instead of a time-based subset. In reality how many relay-agents could
> >even implement a time-bound query after a reload (ie, do they really
> >know the second they were rebooted or lost power)?
>
> I agree, few relay agents have any clear idea of when they last
> were taken out of service or failed. On the other hand, they
> can easily keep track of the latest client-last-transaction-time
> of every bulk leasequery update and save that in stable storage.
> Thus, they know quite easily the most recent information held
> in stable storage and can ask for everything since then.
>
> >8) This proposal requires a TCP connection between server and relay
> >agent thus necessitating an IP address on the relay agent. This seems to
> >be at odds with the objectives outlined in the L2 Relay and LDRA drafts.
> >In these drafts relay-agent (often a DSLAM) does -not- require an IP
> >address nor is it desirable. This proposal will require the DSLAM has an
> >IP address that is routable to the DHCP server - also the draft says in
> >section 5 that "No relaying of Bulk Leasequery messages is specified".
> >This means a logical topology change in many ISP networks and is not
> >aligned with the broadband architectures put forward by other
> >organisations like Broadband Forum TR-101.
>
> Well, a UDP based approach to bulk leasequery was soundly
> defeated for DHCPv6 more or less recently, and years ago
> we sounded folks out on a UDP based version of RFC 4388
> for bulk leasequery for DHCPv4 -- and it was a
> non-starter.
>
> There is some ongoing work on extending RFC 4388 to
> clients that have no IP address.
>
> But, since DHCPv6 Bulk Leasequery made it to RFC status
> using TCP we decided to move forward using that precedent
> for DHCPv4 Bulk Leasequery. Despite your comments, I
> can't see that we have any reasonable alternative to TCP.
>
> Ted Lemons Comments:
> >In section 7.2.7, I don't really understand why the relay agent needs
> >to know more than that the lease is still active, or is no longer
> >active. This seems to be an extension on the functionality provided
> >by DHCPLEASEQUERY, relating to failover, but (a) it seems unnecessary,
> >(b) I have no idea what the DSLAM would do with it, and (c) because of
> >that, it seems like it could result in interoperability problems as
> >different implementors make different guesses as to how to handle
> >it. You could save a lot of text by just taking this out. Same
> >with data-source.
> >
> >I can see where it might be helpful to use this for disambiguating in
> >cases where one server reports a lease as free and another reports it
> >as allocated, but it might be better to simply specify rules for when
> >a server should claim to have knowledge about a lease - if a
> >particular IP address is in its peer's pool, and is not known to have
> >been allocated, perhaps that IP address should simply not be mentioned
> >in a DHCPBULKLEASEQUERY reply. It would be entirely permissible and
> >expected in some cases for that to happen.
>
> Yes, all of this stuff is about the increased
> availability solution where two servers are operating
> together to increase availability.
>
> There are three cases (at least) for each server:
>
> 1. The IP address is available for this server to
> allocate.
>
> 2. The IP address is available for the other server to
> allocate.
>
> 3. The IP address is leased out to a DHCP client.
>
> The expectation is that the relay agent will ask *both*
> servers for all of the information it is interested in,
> and then use the "best" response it gets for each IP
> address.
>
> You propose to have the two servers respond only for
> cases 1 and 3 and be silent on case 2. While that might
> be possible (though it isn't what the draft says, nor is
> it what I think the draft should say), the real issue is
> with case #3.
>
> When both servers are up and they both respond to a bulk
> leasequery about a leased IP address and the information
> they both send agrees everything is fine. And that is
> the normal case (or one hopes so, anyway).
>
> The sticky part is where they *don't* agree -- for
> various reasons sometimes the two DHCP servers providing
> high availability DHCP server don't agree for some period
> of time about the situation regards a particular IP
> address. Then the receiver of the two bulk leasequeries
> needs to figure out which information to believe. The
> information it has in its "database", or the information
> coming in over the wire from one of the servers.
> (Generally they won't both come in at the same instant).
>
> Our experience is that the state and data-source are
> critical to making effective judgements about which data
> is the "best", and therefore which to remember as the
> accurate information about a particular IP address.
>
> Since we are trying to standardize bulk leasequery, we
> thought that having this information available to make
> decisions would be valuable for everyone. We certainly
> need it.
>
> We could send this information to our users of bulk
> leasequery using vendor identifying vendor specific
> options (as we are already planning to do with other,
> less generally interesting, information). But since we
> believe in standards, we felt that having this
> information available to all in a documented and
> standardized format was critical to interoperability in
> an increased availability environment.
>
> But we can certainly take it out and then do it in a
> vendor specific way if you want. Seems unfortunate, as
> it means that we won't really have interoperability when
> otherwise it might well be possible, but I suppose that's
> the way things go.
I vote for the interoperability approach.
"for various reasons sometimes the two DHCP servers providing high
availability DHCP server don't agree for some period of time about the
situation regards a particular IP address."
Our server also does this, and I suspect that any server that used the
draft-dhc-failover document as a starting point does this.
Not that we should necessarily consider draft-dhc-failover when making these
decisions, but there are at least two independent DHCP server implementations
that provide redundancy by allowing cooperating servers to periodically be
out of sync.
> >Regarding section 8.6, as I've said previously in this commentary, I
> >think it would be better to specify the client behavior in such a way
> >that the conflicts proposed in this section simply do not happen.
> >This section is not specific enough to foster interoperability.
>
> See above. We need to decide if we want interoperability
> in an increased availability environment, or not.
>
> >Also on page 34:
> >
> >The message type of DHCPLEASEACTIVE or DHCPLEASEUNASSIGNED is based on
> >the value of the dhcp-state option. If the dhcp-state option value is
> >ACTIVE, then the message type is DHCPLEASEACTIVE, otherwise the
> >message type is DHCPLEASEUNASSIGNED.
> >
> >Once again I suggest you get rid of the dhcp-state message and simply
> >say what should happen here for IP addresses that are managed by
> >failover and those that are managed by a single server.
> >
> >Specifically, any IP address that is in the FREE state on the primary
> >is DHCPLEASEUNASSIGNED. Any IP address that is in the BACKUP state
> >on the primary is not reported on at all. Any IP address that is in
> >the FREE state on the secondary is not reported on at all. Any IP
> >address that is in the BACKUP state on the secondary is
> >DHCPLEASEUNASSIGNED. Likewise for all the other permutations; I
> >think that in any of the states where the failover peer would renew
> >the lease, it's active, and in states where it wouldn't renew the
> >lease, it's either unassigned, or shouldn't be mentioned.
>
> See above.
>
> >Also, in point 4, you mention a grace period on the expired state, but
> >as far as I know no such thing exists.
>
> We discussed the optional possibility for this
> a long time ago. Some servers support such a
> thing, and it seemed valuable to provide for it,
> but we can certainly take it out.
We support grace periods, but I fail to see how this information of use to a
relay agent. Is there something the relay could use this information for that
would result in some increase in effectiveness or efficiency?
- Bud
>
> >Section 10:
> >
> >As I mentioned earlier, the only authorization model for this protocol
> >is based on the requestor's IP address, and there is no
> >authentication. At a minimum this should be mentioned in the
> >security considerations section.
>
> There was a much better security section in RFC4388,
> which I transplanted here. While it may not be everything
> you wanted, it is certainly better.
>
> Thanks much to both of you for your input!
>
> Regards -- Kim
>
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
--
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687