Subject: Re: [dhcwg] Lease updates after Relay Agent crash

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Feb 2008 16:00:06 -0500

BTW:

We probably made the original DHCPv6 bulk lease query (UDP based) more
complicated than it had needed to be. Part of the reason for that is the
DHCPv6 lease query is more client oriented and also the framework was
there to provide lots of different query types.

I haven't looked into it carefully, but it would seem that for DHCPv4 we
could just add a new lease query message which would be a
"DHCPLEASEQUERYNEXTADDRESS" which would interpret the existing "Query by
IP address" as specifying the last address returned and requesting that
the "next" address be returned. 

This still has the performance (latency) issue of one request/response
per lease, but does avoid having to go to TCP.

Of course, I think the TCP approach used for DHCPv6 would be far
superior as there is one request with many potential responses flowing
over a TCP session.

---

I'm somewhat confused by the "TCP is a problem for a layer 2 device"
statement as so is UDP. Note the following text in RFC 4388:

     o The giaddr MUST be set to the IP address of the requester (i.e.,
       the access concentrator).  The giaddr is independent of the
       "ciaddr" field to be searched -- it is simply the return address
       of the DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN
       message from the DHCP server.

       Note that this use of the giaddr is consistent with the
       definition of giaddr in [RFC2131], where the giaddr is always
       used as the return address of the DHCP response message.  In some
       (but not all) contexts in RFC 2131, the giaddr is used as the
       "key" to access the appropriate address pool.  The DHCPLEASEQUERY
       message is one of those cases where the giaddr MUST NOT be used
       as such a "key".

This is because the normal htype/hlen/chaddr fields are used to specify
the client being queried for; they are not available for layer 2
communication.

So, if your DSLAM has no IP address with which to communicate, it isn't
going to be able to do (UDP) DHCPLEASEQUERY either.

- Bernie
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 4 Feb 2008 16:05:59 +0530

Bernie,

> there to provide lots of different query types.

I agree.

> per lease, but does avoid having to go to TCP.

I think what Pavan is looking at is to get all the lease information for
a given Access Concentrator in one go. This will be useful in avoiding
the data traffic coming to control path which will happen with current
DHCPLEASEQUERY mechanism.

> superior as there is one request with many potential responses flowing

Yes. I think Pavan proposed TCP because that takes care of reliability,
retransmission stuff and it makes sure that all the lease information
for a given Access Concentrator has been received.

BTW, as mentioned before this does not completely remove the requirement
of doing normal LEASEQUERY. Existing LEASEQUERY would be useful in cases
where a line bounces and we need to get details for just one connection.

> statement as so is UDP.

Yes. But in case of UDP, Layer 2 Relay Agent can generate a DHCP
leasequery similar to a DHCP client generates a DHCPDISCOVER message. We
have suggested an extension of existing DHCP leasequery mechanism [RFC
4388] in one of our previous draft [This draft has expired and we would
be submitting a new version shortly].

>  Note the following text in RFC 4388:
> 

This is not the case. Even a DHCP client without an IP address is able
to communicate using UDP when it generates DHCPDISCOVER and DHCPREQUEST
messages. In our draft, we have suggested that Layer 2 Relay Agent would
generate a LeaseQuery with source IP address as 0.0.0.0 and destination
address as 255.255.255.255. This LeaseQuery is sent towards the Layer 3
Relay Agent and Layer 3 Relay Agent process it similar to how it would
have handled other DHCP messages i.e. populate 'giaddr' and send it to
the configured DHCP servers.

There are some issues here but they have been resolved after some
discussion on DHC WG mailing list and we have described them in our
draft. I hope this answer your question.

Thanks,
Bharat

PS: You can take a look at the older version of this draft at
http://www.potaroo.net/ietf/idref/draft-joshi-dhc-layer2-relay-agent/

PPS: Please look at section 7.2.1 which talks about generating
leasequery messages.

**************** 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***
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: pavan_kurapati <[email-masked]>
Date: Mon, 4 Feb 2008 22:05:06 +0530

Yes, What I mentioned was to use TCP based bulk lease query in case of Layer 3 Relay Agents where establishing the TCP connection is possible. Since Layer 2 Relay Agents do not have an IP address and also DHCP Server's address this option is difficult . The current leasequery mechanism is data driven hence I proposed query by 'Remote-ID' as a solution to get the lease details reliably without waiting for the traffic to be initiated. As Bharat pointed out, generating leasequery in Layer 2 Relay Agent itself needs to be defined which we did in our earlier draft.

Thanks,
Pavan

________________________________________
From: Bharat Joshi
Sent: Monday, February 04, 2008 4:05 PM
To: Bernie Volz (volz)
Cc: pavan_kurapati; DHC WG
Subject: Re: [dhcwg] Lease updates after Relay Agent crash

Bernie,

I agree.

Thanks,
Bharat