Re: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27, 2015)

[Sunil Gandhewar <[e-mail]>]

Hi All,
I did not hear back from anyone. Did my email resolve the concerns raised?

In order to summarize all the concerns:
1.      What are the use cases, problem statement, motivation
2.      Why is the solution proposed is better that the known solution of short leases
3.      How to handle the situation where client remembers the lease after it is cleaned up at relay and server

Answers:
1.      Section 1.1 of the draft https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01 explains the motivation. There I described that for Service Providers the scale at a device is determined by two factors:
a.      IP addresses, which are plenty for IPv6 hence not a problem.
b.      Resources on the device as well as network - As an example let's say BNG supports 500K subscribers. In order to account for the cases of device replaced, client moves, etc, where one subscriber will be holding more than one lease at a time. Service Providers will have to reduce their subscription to e.g. 2/3rd of the capacity of the BNG i.e. 333K subscribers per box. Thus wrt subscribers it's under-subscribed to the 2/3rd of the capacity of the box. Whereas on the BNG there might be more bandwidth available as bandwidth is always oversubscribed e.g. 10:1 for residential subscribers. That means wrt bandwidth they can assume only one subscriber will be sending data out of 10 subscribers at any point in time. But wrt DHCP subscribers, they need to under-subscribe to 2/3rd of the capacity, just because at any point of time subscriber might be holding more than one lease.
      So the problem is that we should be able to release the binding when Relay knows that the client is no longer holding a particular lease.

2.      The short lease creates lots of DHCP control traffic on the DHCP server. The Call Setup Rate (CSR) is usually in terms of 500 calls per second. That means support 500 DORA/SARR along with radius authentication, creation of logical interface, program various routes, attachment of services,  QoS, policy routing for all the 500 subscribers within a second. BNG also have lot of other tasks to do along with this. BNG will also need to handle client logouts during the same time. Logout includes reverse of login i.e. removing services, routing policy, QoS, access routes, collect and send accounting information to the RADIUS, removing the logical interface. Adding burdon of Renew due to short leases will not scale the BNG box. Hence no Service Provider will opt for short lease as it affects the effective CSR.
a.      They may opt for having a Relay on DSLAM or somewhere close to the client, with asymetric lease i.e. taking longer lease from server and giving shorter lease to the client. When this first relay can detect the client is not renewing, it needs a way to inform server that the client is gone. That way is inroduced by this draft, explained in section 1.2.
b.      Relay being the closest to the client can detect that client is gone and inform server to clear the binding explained in section 1.2.

3.      As per the bullet 1 above, the real problem Sewrvice Providers are facing is when the client holds more than 1 lease at a time i.e. when client is replaced or moved. I was extending the usecase of detecting the client unavailability, which is what has objection. Please let me know if any of the following will address the concern:
a.      Having the configurable knob and network administrator enable it only when the client runs the liveness detecttion and restablish DHCP on network reconnect. This behavior is similar to DHCP over PPP as in case of DSL where DHCP restablishes when PPP reconnects.
                  This functionality SHOULD be a configurable behavior since there is
                  no clear way to distinguish between DHCPv6 client unavailable and
                  network unavailable. Having configurable behavior equips
                  administrator to enable this granular knob (send Relay Initiated
                  Release on DHCPv6 client's unavailability) at Relay only if it is
                  certain that such a situation will not occur or client will clear the
                  Internet-Draft DHCPv6 Relay Initiated Release October 2015
                  binding state and reestablish or the risk of such situation is being
                  accounted.
b.      OR Remove this usecase of generating the Relay Initated Release (RIR) on client unavailable and have the RIR only when client is replaced or moved. That way the client remembering the lease will never happen.


I hope that the 3a or 3b shall address everyone's concern.
Please let mw know if you have ideas, contributions or would like to rephrase any of the sections, I am open for suggestion. Thanks

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[e-mail]