Subject: [dhcwg] Comments on draft-ietf-dhc-leasequery-by-remote-id-02.txt

From: Damien Neil <[email-masked]>
Date: Thu, 6 Aug 2009 16:14:18 -0700

This draft specifies a new query type for DHCPv4 DHCPLEASEQUERY,  
enabling query by remote ID.  The remote ID query is defined as having  
three possible responses: DHCPLEASEACTIVE, DHCPLEASEUNASSIGNED, and  
DHCPLEASEUNKNOWN.

I believe that the distinction between DHCPLEASEUNASSIGNED and  
DHCPLEASEUNKNOWN for this query type is not well-specified.  Section  
6.3 states that the former response is used if "the server manages the  
IP address allocation for the given remote ID" while the latter is  
used otherwise.

It is not clear to me what exactly this means.  In the case of a query  
by IP address, the distinction between "unassigned" and "unknown" is  
clear--an unassigned address is one that has no active binding, but  
which is nonetheless available for static or dynamic assignment, while  
an unknown address is one that the server will never grant.  In the  
case of remote IDs, however, there is no guarantee that the server  
will have a specific list of remote IDs that it grants service to.

I presume that this is the reason that RFC 4388 only defines the  
DHCPLEASEUNASSIGNED response for queries by IP address, and not for  
queries by MAC or client ID.

Appendix A of draft-ietf-dhc-leasequery-by-remote-id-02.txt includes a  
rationale for providing both "unassigned" and "unknown" responses to a  
query by remote ID, but I do not believe this rationale is  
convincing.  It states:

> If a DHCPLEASEUNASSIGNED response comes, access concentrator will  
> drop the traffic corresponding to the IP address. If a  
> DHCPLEASEUNKNOWN response comes, access concentrator may drop the  
> traffic corresponding to the IP address but will have to  
> periodically send the lease query for that IP address again  
> (additional overhead). The process is triggered whenever an unknown  
> IP address comes.

I do not see why an access concentrator would need to resend a query  
after receiving any response--active, unassigned, or unknown.  In the  
absence of DHCP traffic between the DHCP client and DHCP server, the  
results of each query will be identical.  If traffic does pass between  
the DHCP client and DHCP server, that traffic will pass through the  
access concentrator, which can glean the relevant information in the  
normal fashion.

Upon receiving any response to a query by remote ID other than  
DHCPLEASEACTIVE, an access concentrator has sufficient information to  
drop all non-DHCP traffic from that remote ID, as it now knows there  
is no client with an active lease behind it.

On a less technical note, I believe that the clarity of this draft  
could be substantially improved by making it less a copy of RFC 4388.   
This draft is specifying a new query type, not an entirely new lease  
query implementation, and yet it expends substantial effort repeating  
information already available in 4388.

For example, the first three paragraphs of section 6.1 of draft-ietf- 
dhc-leasequery-by-remote-id-02 are largely identical to the first  
three paragraphs of section 6.2 of RFC 4388.  This duplication is  
unnecessary and confusing.  Worse, it introduces the possibility of  
conflicts between the two documents.

I also think the draft spends a bit too much time providing  
justifications for the feature; the use case seems fairly obvious to  
me, and not in need of an overly lengthy rationale.  That's more a  
matter of taste than a substantial objection, however.

These concerns aside, I think the general goal of the draft is worthy  
and the approach sound.

                    - Damien

---

From: Stephen Jacob <[email-masked]>
Date: Sat, 8 Aug 2009 11:55:08 -0700

I agree with Damien that the general goal of the draft is a good
one and the suggested implementation seems reasonable.

Damien already provided a good write-up of some technical issues,
so I don't have too many comments to make beyond what he said.

Additionally, he suggested radical enough changes to the draft
(e.g. not making it such a copy of RFC 4388) that it is probably
not useful for me to provide comments along the lines of
grammatical corrections.

At this point I only have a couple of comments:

-----

The draft includes various statements like:

	"There MUST be a Relay Agent Information option (option 82)
	 with only Agent Remote ID sub-option (sub-option 2) in the
	 DHCPLEASEQUERY message."

I wonder if it is worth either extending the draft to allow querying
by other Relay Agent Information sub-options (circuit ID especially
comes to mind) or whether using "MUST" in this case might make it
difficult for a server to comply both with this draft and a possible
future "DHCPLEASEQUERY by <some other relay agent sub-option>" draft?

-----

I was going to suggest changing wording in a couple of places due to
the fact that I considered the wording to be incorrect, but it turned
out that both of the problems I identified were copied verbatim from
RFC 4388 and so if my comments are valid they should really be against
RFC 4388 and not this draft.

Specifically (note that the section # refers to the draft, not the RFC):

    6.1 Sending the DHCPLEASEQUERY Message

	"In some (but not all) contexts in RFC 2131, the giaddr is
	 used as the "key" to access the appropriate address pool."

    RFC 2131 does not use the term "pool" or "address pool" in this
    way. It talks about the set of all the addresses the server may
    allocate leases for as the server's address pool.

    The usage of "address pool" in this draft is inconsistent with
    its use in RFC 2131 and could cause unnecessary confusion with
    existing implementations (for example in our implementation a
    pool is a configuration element which contains a set of address
    ranges [which are usually not all from within one subnet], and
    in the ISC implementation it is a range of addresses within a
    subnet as I understand it).

    Unfortunately, this means we have many different meanings for
    the term "[address] pool" out there. Two in RFCs where one of
    them is intending to refer to the usage in the other.

    If I were to suggest re-wording, I would probably keep it
    simple and go with something like:

	"In some (but not all) contexts in RFC 2131, the address to
	 allocate to a client is selected based on 'giaddr'."

    -----

    Also in section 6.1, second bullet point:

	"... a DHCPREQUEST message that didn't contain a
	 DHCPLEASEQUERY message ..."

    DHCPREQUEST messages don't ever contain DHCPLEASEQUERY messages
    since DHCPLEASEQUERY is a separate DHCP message type.

    I think what may have been intended is more like:

	"... a DHCPREQUEST message that did not contain a Parameter
	 Request List option (option 55) ..."

I think that this is yet more justification for not making the
draft such a copy of RFC 4388. If at some people we need to issue
an updated/corrected version of RFC 4388, it would be bad to have
any issues additionally encoded in this draft.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

On Thu, Aug 06, 2009 at 04:14:18PM -0700, Damien Neil wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: pavan_kurapati <[email-masked]>
Date: Mon, 10 Aug 2009 10:08:44 +0530

Hi Damien,

Thanks for taking time to review this. Please find my replies inline

Regards,
Pavan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Damien Neil
> Sent: Friday, August 07, 2009 4:44 AM
> To: DHC-WG WG
> Subject: [dhcwg] Comments on draft-ietf-dhc-leasequery-by-remote-id-
> 02.txt
> 
[Pavan] RFC 4388 states that a DHCPLEASEUNKNOWN is generated when the server does not know about this IP address. Yes, it can be interpreted as the one that the server will never grant, but it was covered in more broader sense. Here is what the RFC states "The DHCPLEASEUNKNOWN message indicates that the DHCP server has no knowledge of the information specified in the query (e.g., IP address, MAC address, or Client-identifier option)."
In the same context, if a server receives a query by remote-id for which it has no information or no IP leases, it will reply with a DHCPLEASEUNKNOWN. Unlike in the case of query by IP where spoofing of any IP is possible by hosts, chances of this happening for query by remote-id is very less since it is added by Access Concentrator. We can in fact do away with the reply type UNKNOWN for this query, if that is what the community feels?

> access concentrator, which can glean the relevant information in the
[Pavan] We completely agree with you that a periodic query may not be required even for the data driven approach. What we stated in Appendix is that RFC 4388 recommends a periodic query for UNKNOWN based on negative caching. We've raised a similar query to the authors of 4388 as to why a periodic query was needed. As a matter of fact, we do not recommend this periodic querying in query by remote-id approach.

> conflicts between the two documents.
[Pavan] We wanted this draft to be an independent read, and intentionally borrowed text from RFC 4388 as it was an extension to the idea proposed by RFC 4388. We will definitely look into changing the text as suggested by you and will come out with a new version.
> matter of taste than a substantial objection, however.
[Pavan] The justification was presented in Appendix for the readers to understand the need for the new query type. We can remove the appendix section once it passes the WG last call

---

From: pavan_kurapati <[email-masked]>
Date: Mon, 10 Aug 2009 10:23:22 +0530

Hi Stephen,
Thanks for the review. Please find my replies inline

Regards,
Pavan 

> Of Stephen Jacob
> Sent: Sunday, August 09, 2009 12:25 AM
> To: DHC-WG
> Cc: Damien Neil
> Subject: Re: [dhcwg] Comments on draft-ietf-dhc-leasequery-by-remote-
> id-02.txt
> 
[Pavan] We started with having both circuit-id and remote-id in our initial version. Since circuit-id is not a unique string unlike remote-id, there were concerns on usefulness of query by circuit-id in the initial review by WG. Also, a query by circuit-id has to be combined with relay-id whose combination will be unique. Considering that a query by remote-id would be sufficient for the problem statement, we removed other sub-options. Having said that, the "MUST" used in this paragraph is only for identifying a query by remote-id.
> 	 allocate to a client is selected based on 'giaddr'."
[Pavan] We will re-word accordingly in the next version.
> 	 Request List option (option 55) ..."
[Pavan] Yes, you are right. This again is a mistake inherited from 4388. We will change it in our next version

---

From: Damien Neil <[email-masked]>
Date: Sun, 9 Aug 2009 23:10:40 -0700

On Aug 9, 2009, at 9:38 PM, pavan_kurapati wrote:
> [Pavan] We completely agree with you that a periodic query may not  
> be required even for the data driven approach. What we stated in  
> Appendix is that RFC 4388 recommends a periodic query for UNKNOWN  
> based on negative caching. We've raised a similar query to the  
> authors of 4388 as to why a periodic query was needed. As a matter  
> of fact, we do not recommend this periodic querying in query by  
> remote-id approach.

This is an interesting point.  I had missed the language in 4388  
recommending a maximum lifetime of cached DHCPLEASEUNKNOWN responses.   
(I assume you're talking about the second to last paragraph of section  
6.5.)

I'm going to venture a guess that this is intended to deal with  
servers cooperating in a failover relationship, where a server can  
never definitively state that its partners have not granted a lease to  
a given client.  A server can, however, definitively state whether a  
lease which has been balanced to it has not been assigned.

This is a scenario worth keeping in mind, and so I'll say that I was  
wrong before--there *is* a good reason for an access concentrator to  
resend a query after receiving an DHCPLEASEUNKNOWN response.  Also, I  
would say that my earlier description of the distinction between  
DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN was incorrect:  
DHCPLEASEUNASSIGNED is a definitive response (this address is  
definitely not assigned), while DHCPLEASEUNKNOWN is not (this server  
hasn't offered any leases matching the query, but some other server  
may have).

However, this doesn't change my opinion that there should not be a  
DHCPLEASEUNASSIGNED response for query-by-remote-id. :>  (Actually, it  
reinforces it.)

                 - Damien

---

From: Bud Millwood <[email-masked]>
Date: Mon, 10 Aug 2009 11:37:34 +0200

On Friday 07 August 2009, Damien Neil wrote:

> will have a specific list of remote IDs that it grants service to.

There is no guarantee that the server has a list of remote ids, but it's 
certainly possible. DHCPLEASEUNKNOWN seems like a reasonable response from a 
server that is explicitly configured to authenticate by remote ID.

If the server is *not* explicitly authenticating remote IDs, but instead is 
just recording those it has seen in the past, is a DHCPLEASEUNKNOWN response 
useful for the access concentrator?

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 10 Aug 2009 21:45:08 +0530

Reply in line.

Thanks,
Bharat

> Thereok is no guarantee that the server has a list of remote ids, but it's 

Yes. That is the right explanation for having DHCPLEASEUNKNOW for 'Query by remote-id'.

> useful for the access concentrator?

No. Actually it is not.

But the reason we kept it in the draft is to take care of the above situation.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Damien Neil <[email-masked]>
Date: Mon, 10 Aug 2009 11:42:58 -0700

> server that is explicitly configured to authenticate by remote ID.

This argument applies equally to the other query types in 4388,  
however: It's possible for a server to have as explicit list of client  
ids or MAC addresses, but those queries don't permit a  
DHCPLEASEUNASSIGNED response.

I did miss the most compelling argument against permitting  
DHCPLEASEUNASSIGNED responses to these queries: While there is  
necessarily a single source of truth regarding an address's  
assignment, there is no single source of truth for a client id or  
remote id.  That is, in the case of multiple servers offering  
redundant DHCP service for a link, no server can definitively state  
that none of the other servers have offered an address to a given  
client id or remote id.

                 - Damien

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 10 Aug 2009 11:53:11 -0700

> useful for the access concentrator?

It is entirely possible for a server to use an external source of
authentication by remote ID and thus to authenticate based on it
but not inherently know about remote IDs that are considered valid.

That said, I suppose such a server could probably consult the
external authentication source regarding a remote ID in response
to the DHCPLEASEQUERY.

On the topic of whether DHCPLEASEUNASSIGNED even makes sense, I
to side with Damien on this.

When queried by IP address, you can say that a /lease/ is
definitively unassigned or unknown depending on whether it is
balanced to you and known to be unassigned or may have been
assigned by a peer (or cooperating server!) -- i.e. unknown.

In any sane DHCP installation you really /can/ know that an address
is unassigned if either you are authoritative for the address
and no failover is involved or if failover is involved and it is
balanced to you. Any configuration in which that that is not true
is broken.

On the other hand, though, if you query by remote ID you will
never, ever, definitively be able to say that nobody else has
given a lease to that remote ID unless you have some extra-
protocular knowledge. Since remote IDs don't balance to one
server or another like leases (with failover), and since they
are not segregated to only be answered by either "me or not-me"
(cooperating DHCP servers), there is absolutely no way to ever
say for sure that neither a failover peer nor some cooperating
DHCP server has given a lease to a given remote ID.

That is ... unless the server has been administratively
configured in some way to promise it that it knows more than it
can otherwise guess (sort of like you can administratively
promise to one failover peer that its peer is dead to put it in
PARTNER-DOWN versus COMMUNICATIONS-INTERRUPTED).

I'm not sure that it's wise for the WG to publish a draft
suggesting that servers should try to tell the difference. It
seems like something very hard to determine in a DHCP server
without customer-specific code to ensure that UNASSIGNED really
is UNASSIGNED.

That said, though ... it seems to me that there's the very same
issue with query by client ID or query by MAC address, so perhaps
we've already committed the faux pas.

Does anybody actually have an implementation which differentiates
and chooses whether to send DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN
depending on ... something for query by Client ID or MAC address?

Regards,
Stephen

---

From: Damien Neil <[email-masked]>
Date: Tue, 11 Aug 2009 11:47:31 -0700

On Aug 11, 2009, at 5:44 AM, pavan_kurapati wrote:
> In a failover scenario, a RA would send LEASEQUERY to all the  
> servers configured. So, if one server has responded with  
> DHCPLEASEUNKNOWN, you can expect other to respond with an UNASSIGNED  
> or ACTIVE and Access Concentrator can handle the conflict by  
> accepting the definitive response compared to a non-definitive one  
> (UNKNOWN). Are we talking of periodic retries in the case where  
> response from other servers are lost?

In the case of query-by-address, the above sounds accurate.

In the case of e.g., query-by-MAC, however, the RA will never receive  
a DHCPLEASEUNASSIGNED response, because neither DHCP server can  
definitively state that the partner server has not granted an address  
to that MAC.

The following summarizes my understanding of the different responses:

DHCPLEASEACTIVE: Definitive statement that a lease exists for the  
given address, MAC, client-id, or remote-id.

DHCPLEASEUNASSIGNED: Definitive statement that no lease exists on the  
given address.

DHCPLEASEUNKNOWN: Non-definitive statement that the server queried  
does not know about an active lease associated with the given address,  
MAC, etc., but that some other server may have granted such a lease.

An RA may cache DHCPLEASEACTIVE and DHCPLEASEUNASSIGNED responses  
indefinitely.

If an RA receives a DHCPLEASEUNKNOWN response from every DHCP server  
serving a network, then it may cache the response indefinitely.   
(Although there is a potential hazard here, if an RA is incorrectly  
configured such that it doesn't know about all the DHCP servers for a  
network.)

If an RA receives a DHCPLEASEUNKNOWN response from one server and a  
DHCPLEASEACTIVE/DHCPLEASEUNASSIGNED from another, it should use the  
more definitive response.

If an RA receives a DHCPLEASEUNKNOWN one DHCP server, but no response  
at all from another, then it should not cache the response indefinitely.

Does that sound reasonable?

(Personally, I think the complexity of counting multiple  
DHCPLEASEUNKNOWN responses is probably not worth it, but that's a  
different question.)

              - Damien

---

From: Stephen Jacob <[email-masked]>
Date: Wed, 12 Aug 2009 07:45:59 -0700

On Tue, Aug 11, 2009 at 08:04:22PM +0530, pavan_kurapati wrote:
> I think both query by client ID and MAC do not permit UNASSIGNED
> response so they seem to be fine.

That is good. Upon re-checking RFC 4388, I agree with your assessment.

I think the authors of RFC 4388 got that right. They knew that it is
impossible to know whether some other DHCP server may have allocated
a lease to a client, so they cannot answer the question definitively.

In query by IP address, the question is:

	"Is this IP address leased?"

whereas in the other cases (by MAC, by client ID) the question is
different:

	"Does this client have any leases?"
	
In the latter it is simply impossible to know if another DHCP
server has leased any addresses to a client, and so it never makes
sense to say "UNASSIGNED" in response.

> If the server is explicitly configured for remote-IDs then I
> think there is no problem in returning an UNASSIGNED (or even an
> UNKNOWN). The problem comes when it is not explicitly configured
> for remote-IDs. In such a case, only 2 replies seem to be
> possible, i.e an ACTIVE or UNKNOWN. Can we state such a situation
> and allow UNASSIGNED in the draft?

I'm kind of uncomfortable with the draft allowing DHCPUNASSIGNED.

Where the question "Does this client have any leases?" was judged
to be a question which could not be answered "no" (UNASSIGNED)
definitively, the question of "Does any client with this remote-ID
have any leases?" is just as unanswerable unless the answer is
"yes".

The fact that the server doing the answering is "configured for
remote-IDs" doesn't mean that there are not other DHCP servers on
the network that are not. In order for your server to answer
"UNASSIGNED" for a remote-ID, you would have to have configured
it with promises about what other servers might do -- not just
have configured it to act in a certain way.

I think it is a bad idea to allow UNASSIGNED as it is really
quite hard to do so correctly and involves server administrators,
not just implementors, having to understand the subtleties enough
to configure DHCP servers with custom knowledge/promises about
other servers (or lack thereof) on the network.

I don't see it as operationally critical to return "UNASSIGNED"
versus "UNKNOWN" and so I don't think the draft should allow an
option which has an extremely high likelihood of not working how
it is meant to -- either due to implementor misunderstanding or
due to administrator understanding. It is just too confusing and
too likely to be misunderstood for a very dubious benefit.

Regards,
Stephen

---

From: Bud Millwood <[email-masked]>
Date: Thu, 13 Aug 2009 10:12:38 +0200

On Wednesday 12 August 2009, Stephen Jacob wrote:

You guys, I agree with your arguments.

It's a pretty specific setup to be configured to be authoritative for all 
remote IDs on the network. And I think that if we allow UNASSIGNED for such 
an esoteric environment, it's going to be begging to be semantically abused.

- Bud

---

From: pavan_kurapati <[email-masked]>
Date: Tue, 18 Aug 2009 17:49:37 +0530

Hello Damien,Stephen

Sorry for the delay. From the discussions, we agree with the consensus of WG about using only DHCPLEASEACTIVE and DHCPLEASEUNKNOWN for query by remote-id. We will remove the use of DHCPLEASEUNASSIGNED in our draft in the next version. However, I don't think we need to keep the condition of periodic retries for DHCPLEASEUNKNOWN for query by remote-id as required for query by IP or MAC or Client-ID(RFC 4388). I propose we keep the cache indefinitely. Please find replies below for some specific suggestions.

> configured such that it doesn't know about all the DHCP servers for a

I think we can ignore configuration related issues and assume that RAs would know all DHCP servers for a network. 
 
> more definitive response.

Yes

> at all from another, then it should not cache the response

I think this scenario is taken care by section 6.6 of RFC 4388 wherein an RA retries on exponential backoff mechanism to the server which did not respond. What we are proposing is that there is no need to retry to the server which "did respond" with a DHCPLEASEUNKNOWN. RFC 4388 states "The access concentrator SHOULD cache this information, but only for a relatively short lifetime, approximately 5 minutes", which in our opinion may not be required.

Thanks,
Pavan

> From: Damien Neil [mailto:[email-masked]]
> Sent: Wednesday, August 12, 2009 12:18 AM
> To: pavan_kurapati
> Cc: DHC-WG WG

---

From: Damien Neil <[email-masked]>
Date: Tue, 18 Aug 2009 09:28:30 -0700

On Aug 18, 2009, at 5:19 AM, pavan_kurapati wrote:
> I think this scenario is taken care by section 6.6 of RFC 4388  
> wherein an RA retries on exponential backoff mechanism to the server  
> which did not respond. What we are proposing is that there is no  
> need to retry to the server which "did respond" with a  
> DHCPLEASEUNKNOWN. RFC 4388 states "The access concentrator SHOULD  
> cache this information, but only for a relatively short lifetime,  
> approximately 5 minutes", which in our opinion may not be required.

There's one scenario in which retrying to a server which responded  
with a DHCPLEASEUNKNOWN may be useful, although I don't know if it is  
likely enough to justify the retry.

If two DHCP servers are involved in a cooperative failover  
relationship, and a routing issue prevents one of the servers from  
communicating with the RA while still allowing the two servers to  
communicate with each other, then that other server's response might  
change from DHCPLEASEUNKNOWN to DHCPLEASEACTIVE.  Yes, this is  
unlikely and convoluted; as I said, I don't know if it's worth  
designing for.

I would be interested to learn why the language regarding cacheing of  
DHCPLEASEUNKNOWN responses was originally included in RFC 4388.

                - Damien

---

From: Stephen Jacob <[email-masked]>
Date: Tue, 18 Aug 2009 10:21:07 -0700

I think we should retain the retry upon DHCPLEASEUNKNOWN.

See below for comments on why.

> unlikely and convoluted; as I said, I don't know if it's worth  

It is admittedly a somewhat contrived case, but the way I see it,
we have, for indefinite caching:

    Pro: Don't have to do quite so many DHCPLEASEQUERYs
    Con: Could deny service to a client/customer in a corner case

I suspect that the con is a bigger deal than the pro, so I suspect
that it is better to be safe than sorry and to retry periodically.

When would these extra DHCPLEASEQUERY messages occur and for how
many remote IDs? I would think only upon receiving traffic from
an unknown client, right? Each 'unknown' client could be a valid
client and so for each client it makes sense to occasionally
re-check. A message every 5 minutes is a pretty tiny overhead for
that, I suspect. I assume the access concentrator isn't, each 5
minutes, sending out a DHCPLEASEQUERY for every single
IP/MAC/client-id/remote-id that it got an UNKNOWN response for.

Another consideratin here is that if access concentrators such as
DSLAMs or CMTSes already have code for dealing with short-term
negative caching of DHCPLEASEQUERY responses, it is probably
simpler for them to have the caching semantics be consistent across
RFC 4388 and this draft.

> DHCPLEASEUNKNOWN responses was originally included in RFC 4388.

I would also like to know that. :)

My gut feeling is to maintain the same behaviour as RFC 4388 in
this respect unless we can come up with a compelling reason why
it would be better not to.

Regards,
Stephen

---

From: RAMAKRISHNADTV <[email-masked]>
Date: Thu, 27 Aug 2009 17:45:08 +0530

Let me consider the same scenario considered by Damien with a small
wrinkle.

Two DHCP servers are involved in a cooperative failover and LOAD BALANCING
relationship, and a routing issue prevents one of the servers from
communicating with the RA while still allowing the two servers to
communicate with each other.

In that case, suppose the reachable server responds with LEASE ACTIVE
with a set of IP addresses for a specific remote-id. Now, it is
possible that after syncing with the other server, there may be MORE IP
addresses associated with the same remote-id. Then, we may have
to retry even for LEASE ACTIVE response also?

Is this is a valid scenario?

-- Ramakrishna DTV.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Damien Neil [[email-masked]]
Sent: Tuesday, August 18, 2009 9:58 PM
To: pavan_kurapati
Cc: DHC-WG WG
Subject: Re: [dhcwg] Comments on        draft-ietf-dhc-leasequery-by-remote-id-02.txt

                - Damien

---

From: Damien Neil <[email-masked]>
Date: Thu, 27 Aug 2009 11:24:03 -0700

> Is this is a valid scenario?

Valid, I think, but unlikely.  Since a routing issue which prevents an  
RA from communicating with a server will also presumably prevent  
clients behind that RA from communicating with the server, it is  
unlikely that the unreachable server will have information of interest  
to the RA.

There are, however, some improbable-yet-possible cases where this  
scenario could happen.  If a routing issue interrupts communications  
between the two servers, a second routing issue then interrupts  
communications between the RA and one of the servers, and the first  
routing issue resolves, for example.

              - Damien

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 27 Aug 2009 14:19:37 -0700

> routing issue resolves, for example.

Perhaps an even simpler scenario is that of a backlog of failover
traffic (a large update queue), server B gives lease L to a client,
then network partition removes server B from the picture (entirely)
before it communicates with server A. RA queries, is told a list of
leases omitting L by server A. When server B comes back, it could
offer up the information that lease L was handed out to the client
were it asked.

Basically, this is the same as Damien's scenario but with lazy
updates taking the place of the first network partition, thus not
requiring multiple separate network partitions.

That said ... I suspect these issues are unlikely enough that they
may be addressed administratively if an issue arises.

Also, in a situation such as this, the lease could only be valid
for mclt, thus making it likely that it would be valid for a
/relatively/ short period of time and further decreasing the
likelihood of resolving any issue by re-querying after a delay.

Regards,
Stephen

---

From: pavan_kurapati <[email-masked]>
Date: Fri, 28 Aug 2009 13:42:41 +0530

Hello Damien,

Our point is that a similar scenario was quoted for DHCPLEASEUNKNOWN to justify periodic queries. If such a scenario can/does happen, a LEASEACTIVE would also need periodic queries to get complete information for a remote-id. If these scenarios are considered unlikely and can be ignored, my view is that it can be ignored for DHCPLEASEUNKNOWN as well. Are we missing something here? Please let us know your views. 

Thanks,
Pavan

> Sent: Thursday, August 27, 2009 11:54 PM
> To: RAMAKRISHNADTV; DHC-WG WG