Subject: [dhcwg] Lease updates after Relay Agent crash

From: pavan_kurapati <[email-masked]>
Date: Wed, 30 Jan 2008 15:55:41 +0530

Hi,

As part of DHCP implementation in our DSLAM we are facing an issue where we need to recover all the lease information after the DSLAM crash. The DSLAM in question here is a layer 2 device and acting as Layer 2 Relay Agent doing DHCP snooping.

The current implementation of LEASEQUERY (RFC4388) is  data driven., i.e Relay agent can query by MAC/IP/Client id only when the data starts flowing from the clients. This model does not work well as there will be a lot of load on DSLAM  if it has to trigger leasequery after traffic starts flowing from the clients . The preferred approach would be to get the lease information as soon as the device is up. There were couple of options that we explored to get around this problem

Option 1: Use the same concept as  DHCP v6 bulk leasequery. This option is useful when DSLAM is a layer 3 device. It needs to be extended to DHCPv4.  However, when DSLAM is acting as a layer 2 device (which is more predominant in this segment), DSLAM does not have IP address of its own and neither does it know about the server address. So it cannot establish TCP connection as suggested by the draft.  Configuring a temporary local ip address on dslam and finding server ip address dynamically (or static configuration) do not work out well and are more complex in deployments.

Option2  : Form a different query type in lease query based on  'remote-id'. In remote-id sub-option DSLAM can add connection name which is local and unique to the provider. As soon as DSLAM comes up and lines train up, DSLAM can trigger the leasequery without waiting for the traffic from the clients. This is a simple and most effective approach. As the servers also keep the mapping if remote-id is present this will be relatively easier to implement. The only issue here is that it is not a bulk update and has to be done on per line basis.

Option 3:  Use FORCERENEW message from server (RFC 3203). Trigger the server from Relay Agent to initiate this. This method had lot of issues  so we did not explore it further

Can we explore option 1 and 2? i,e for DSLAMs which can do layer 3, explore draft-stapp-dhc-dhcpv6-bulk-leasequery-00 to work on DHCP v4 and for  layer 2 based DSLAMs work on option 2 which is more simple?

Thanks,
Pavan Kurapati

**************** 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]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 30 Jan 2008 09:24:29 -0800

> Can we explore option 1 and 2? i,e for DSLAMs which can do layer 3, explore draft-stapp-dhc-dhcpv6-bulk-leasequery-00 to work on DHCP v4 and for  layer 2 based DSLAMs work on option 2 which is more…

I'm a fan of option 2.  In my opinion, the bulk leasequery over UDP
idea has a major deployability issue, which is that the server has to
keep state between bulk query packets in order to preserve the order
of the reply when the relay made the first request.  This is a big
thing to require...the database the server is managing is changing
all the time.  It would have to preserve the order across multiple
UDP packets at different times, maintaining the ability to 'rewind'
to a previous point for retransmission.  This is very different from
having to buffer the response into a TCP socket.

So it'd be my personal preference to explore option 2 until we find
a hurdle that makes option 1 exceedingly attractive.

I have a question;

How is option 2 different from option 1 in terms of the number of
queries the DSLAM must make?  Surely for every bulk response packet,
there would still be a query for that packet?

So I think it actually works out to the same number of packets, or
very near, especially when you consider DHCPv4 packet size
constraints.

And I have an option 4 which I make no statement as to the
applicability;

It's been suggested once or twice that there could exist a generic
XML markup that describes a DHCP server's lease database in the same
sort of terms you might get in DHCPLEASEQUERY.  Could the DSLAM,
which probably has some non-portable management address in rfc1918 or
something, be configured to use an http proxy, and request a
configured URL off of each of its downstream customers' providers'
servers?

This requires the DSLAM implement much more than just DHCP.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: pavan_kurapati <[email-masked]>
Date: Thu, 31 Jan 2008 09:47:23 +0530

Hi David,

Thanks for the response. Please find replies inline

Thanks,
Pavan
________________________________________
From: David W. Hankins [[email-masked]]
Sent: Wednesday, January 30, 2008 10:54 PM
To: DHC WG
Subject: Re: [dhcwg] Lease updates after Relay Agent crash

On Wed, Jan 30, 2008 at 03:55:41PM +0530, pavan_kurapati wrote:
>> Can we explore option 1 and 2? i,e for DSLAMs which can do layer 3, explore draft-stapp-dhc-dhcpv6-bulk-leasequery-00 to work on DHCP v4 >and for  layer 2 based DSLAMs work on option 2 which is more simple?

>having to buffer the response into a TCP socket.

Yes, sending response in TCP is a good option, but as I mentioned, it might be difficult to do on a Layer 2 device like DSLAM.

>there would still be a query for that packet?

In case of option 1, one query from DSLAM would suffice to get all the details. i.e if it queries by RelayID (which needs to be defined) server would have to send all the lease information belonging to that Relay agent in the TCP socket. In case of option 2, DSLAM would have to send a query for every line and the associated connection that comes up since the query is based on remote-id. But given the constraints other methods have, this is a better approach.

>This requires the DSLAM implement much more than just DHCP.

A good option, but as you said, a Layer 2 DSLAM would now have to implement much more than just DHCP snooping. So it might be a little more complex.

---

From: RAMAKRISHNADTV <[email-masked]>
Date: Thu, 31 Jan 2008 14:32:50 +0530

Hi Pavan,

Although option 1 (bulk lease query) is useful for layer 3 relay
agents, it is a good idea to support option 2 (lease query based on
'remote-id') in any case:

*. Bulk lease query is very complex or may not work for layer 2 relay
agents where as lease query based on 'remote-id' should work fine for
them.

*. Even layer 3 relay agents may find lease query based on 'remote-id'
useful. Occasionally if a line bounces and it needs to reestablish
the call, lease query based on 'remote-id" would be ideal rather than
getting bulk information and extracting the needed information out of
it.

Regards,
Ramakrishna DTV.

________________________________________
From: pavan_kurapati [[email-masked]]
Sent: Thursday, January 31, 2008 9:47 AM
To: David W. Hankins; DHC WG
Subject: RE: [dhcwg] Lease updates after Relay Agent crash

Hi David,

Thanks,
Pavan

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 31 Jan 2008 08:10:11 -0800

> In case of option 1, one query from DSLAM would suffice to get all the details. i.e if it queries by RelayID (which needs to be defined) server would have to send all the lease information belongin…

Ohh!  I got the bulk query drafts backwards.  I was thinking of the UDP
based bulk query in the original DHCPv6 leasequery draft.

If the DSLAM is capable of TCP (has an address it can use (or nat?) to
route to the DHCP server), then that is much preferrable.

The trick will be finding a way for the DSLAM to make a query for "all
addresses it cares about."  The problem is that its management address
is unlikely to be appropriate for the networks it serves (probably a
different VLAN), so searching for "all leases on the broadcast domain
that includes giaddr" may not return the right set.  Servers have to
cache relay agent information options, so using some key in the relay
agent options seems plausible, but I'm not sure of the standards
situation with relay agent sub-option code 3.  It's listed in our
sources as an IPv4 address, but it's listed in IANA as reserved with
incompatible usages.

And there may be some small consideration with regard to old software.
Not all software use straight cooked-UDP BSD sockets, ISC DHCP for
example uses some form of raw socket - BPF, DLPI, plain raw sockets,
whatever it can get its hands on - in order to strictly conform to
RFC2131 with regard to broadcast and source address restrictions.

Of course, we only do this for when we talk directly to a subnet, but
we keep doing it even when talking to relays, so.

It may be the TCP connection would need to be to some other port than
67, in order to avoid the excessive logging of errors on software that
does use the plain unfiltered raw socket.  Since we all speak DHCP
anyway, perhaps the port number could be delivered to the DSLAM in an
initial unicast DHCPINFORM?