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

From: Sunil Gandhewar <[email-masked]>
Date: Sat, 17 Oct 2015 12:34:32 +0000

Hi All,

Thank you all for your replies.

In this email please find my response to all the emails so far. Please let me know if I missed anything.

Multiple scenarios are described in the draft draft-gandhewar-dhc-v6-relay-initiated-release-01<https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01> (https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01) for DHCPv6 in section 1.1 e.g. device replaced,  client moved, Wi-Fi centers frequent login-logouts, etc where this functionality is needed. The problem scenario where client remembers the lease, may happen only in one out of the multiple cases described. It will happen if Relay wrongly generates Relay Initiated Release by mistaking the network disconnect as the client unavailable.

Section 1.3 describes many possible setups and configurations where this functionality is applicable and also points out where this is not applicable. In order to address the non-applicable scenarios,, the  draft suggests multiple solutions e.g. having the granular configurable knobs at Relay with which administrator can control when to generate the Relay Initiated Release. It also points out multiple examples on how to address in case one still configures e.g.
1.      To have liveness detection at the client and Relay, e.g. running BFD
2.      To have asymmetric lease at Relay. Server gives out longer leases e.g. few hours. Relay acts as proxy and gives out small leases e.g. 15 min to the clients. This helps the server to reduce the burden of handling frequent renews. I described this in more details below. When Relay identifies that Client did not renew the lease, it knows client is gone, but no way to communicate this to the Server.

I think all these are the different ways how one can identify that the client is really gone and not the network. However, I think, DHCP should provide a way (infrastructure) which can be used to clear such bindings. Should DHCP enforce which mechanism Relay should use to identify that the client is really gone? Section 1.3 also points out that there are no issues for the DSL based service providers as client reestablishes DHCP once underlying PPP gets established. The non-applicable scenario does not even happen. None of the above mentioned solutions are needed for these type of service providers.

>>>> I agree.   I don't remember support being shown at IETF-93, actually.   I said that I thought it was an interesting idea, but that should not be construed as support for the working group doing the work.

Sorry Ted if I misunderstood. You mentioned during my presentation at IETF-93: "In case this comes up after meetecho dies, I favor adoption of v4 draft", hence I considered it as support. Does this not mean support?

Some of the support emails are from the vendors who have already deployed the solution and using it since few years. The solution proposed in the draft was initially requested for clearing the binding administratively, where relay and server somehow went out-of-sync. Synchronizing the client state at all the network devices, is one of the pain-point for many Service Providers. This scenario is included in the draft. Then another service provider wanted to use this functionality where they were replacing the Set-top box and wanted this to be done automatically rather than administratively. Next was the requirement from another Service Provider where the relay was detecting that the client moved from one network to another. It became applicable where there were frequent logins and logouts at Wi-Fi Gateways. Although some of these supporting vendors might have joined the WG recently, they know IETF and RFCs very well, they might not be familiar to the culture of responding to the email in WG and the process. But if you see the email addresses, they are all authentic and have deployed the solution in their network.

>>> We see a claim that 95% of clients don't release before disconnecting, which seems likely to be true, but we don't hear why this is a problem

I thought I described it in section 1.1 where I clarified that not releasing the stale bindings reduces their Subscription rate. Service Providers need to deploy more BNG boxes to support the same number of customers as the scaling gets limited to the resources on the BNG. Please let me know if my wordings are not correct or need to rephrase. First paragraph from that section is again pasted for convenience at the bottom of this email.

>>>> It appears to be the case that this document is actually motivated by a use case where a WiFi provider wants to charge by the time unit

No, that's not the case. Box has limited capacity to scale. If stale clients are lying around, new clients will be denied the access as all the resources are exhausted on the box.

>>>> "why this particular solution is a better solution than using shorter lease times"

BNG may have either Server or Relay. BNG supports usually in the range of 512K clients or even more. With the short leases server has to deal with login rate as well as frequent renews. This causes even bigger performance problem.
Some vendors have implemented asymmetric leases i.e. Relay takes the longer lease from server and gives out short leases to the client. Since relay needs to deal with the smaller number of clients than Server, it can handle the frequent renews. The problem is when relay detects that the client did not renew, it knows client is gone but cannot initiate Release without the support of this draft. Asymmetric lease at relay helps here and I pointed it out in section 1.3.

>>>> From reading the draft, I think there is: 1) insufficient motivation for this approach, 2) no discussion of limitations of existing ways of dealing with the issue (e.g., short least times), and 3) no clear guidance on when/where this approach should (or should not) be used.
1. is addressed in Section 1.1 of https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01. Please let me know if this needs to be changed.
2. Short lease times at server burdens server to deal with logins and frequent renews, causing further performance issues. I described this further above.
3. Does the section 1.3 not enough? Please help in rewriting, I am open and willing to accept contributions.
What I am not getting is, everyone reiterating the same point that the information is not there in the draft. What am I missing here? Is it the language? Can't these sections be rephrased instead of rejecting the draft itself?

>>>>Yes, I too have concerns for this and feel it could easily be misused and result in a mess (many clients with duplicate leases). This is one reason I have been pushing to clarify where this can and cannot be used. (For example, it is 'safe' to use if the client is communicating over a circuit that gets torn down - and for the client to 'return' a new circuit needs to be started. But even then it may have issues if there are other devices behind the device the terminates the circuit - as they be unaware that the lease was 'released' on their behalf.)

Bernie, does the section 1.3 addresses your concern on where this is applicable and where not? I had been requesting you to please let me know if this can be done differently. Please help in rewriting, I am open and willing to accept contributions.
By having things configurable at Relay, wont' it isolate the situation? It is not possible to always have a full proof solution which is applicable in all the possible configurations and works ideally. But by having applicability section helps, rest of the Service Providers are not deprived of the solution.

I request all of you to please have one more read to the section 1.1, 1.2 and 1.3 in https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01 and let me know.
If you have any other suggestion on how to solve the problem or to rephrase these sections, please let me know your suggestions. Please send me your ideas and contributions so that we can update the draft accordingly. By not adopting the draft we are punishing all the other Service Providers who will not face such issues in their network and deprive them from the usefulness of the functionality. There are many Service Providers who are in need of this draft. I am willing to accept contributions and ideas in solving this problem. If there's something missing or can be done better way, why not come together and contribute to make it better solution. I welcome all the ideas, solutions and contributions.

>>>>To Brian's comment (separate email), it is interesting that none of the material from Slide 4 of https://www.ietf.org/proceedings/93/slides/slides-93-dhc-2.pdf made it into the draft as motivation for the original Relay Release feature? Or did I miss it?
It's already there, isn't it this? Please let me know Brian what is missing.

1.1. Problem Description
While providing an IPv6 address or IPv6 Prefix to the DHCPv6 Client,
Service Providers (e.g. Broadband Service Providers), creates a
logical interface per client, programs various routes (e.g. access
routes, framed routes) for the client to access the network and
services, attaches services (e.g. voice, video, data), maintains
policy, applies QoS. Along with these resources there is a need for
memory and bandwidth per client. Since all these resources are
limited on a network device (e.g. Broadband Network Gateway), it
defines the scaling capacity of the device. Since the availability
of the IPv6 addresses is large, subscription rate for the Service
Providers is thus limited by the availability of the resources on
their network device.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]

---

From: Sunil Gandhewar <[email-masked]>
Date: Wed, 21 Oct 2015 13:52:28 +0000

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.
[email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 21 Oct 2015 19:01:42 +0000

I think most of the problem here is that there is so much here that it is unclear and confusing. There's a lot of "In some provider networks" and a lot of possibilities but less clear direction. There are no RFC 2119 keywords used in this material.

I think restructuring this material in a way where it is clear as to when this feature MUST NOT be used would be useful. Even better, restructure to say that this feature MUST ONLY be used when the following criteria are met. Or something similar. This means moving it later (so you can use RFC 2119 keywords - generally they aren't used in abstract/introduction material).

Also, the v6 document has a lot more material about this; the v4 document needs to have more (there are differences between DHCPv4 and DHCPv6). Breaking the v4 Introduction text into multiple sections would be an improvement.

The v6 discusses "client is replaced" and "client replacement" but it isn't clear as to how this is determined and is different from a device that has lost connectivity or has been powered down. Does "client replacement" require some operator action to indicate to the relay that this device has been replaced?

And:

   This functionality described in Section 1.2 is useful for clearing

   the client binding administratively, client replacement, frequent

   client login and logout without sending RELEASE (e.g. at Wi-Fi

   centers) or where client moves frequently without sending RELEASE

   (e.g. mobile networks).  All these situations can be detected by the

   first DHCPv6 network device.  Thus this functionality is applicable

   to all these situations without any problems.

I think this last sentence kind of means: I can stop reading the rest of the material as I'm good to enable this feature?

Your statement above, "By having things configurable at Relay, wont' it isolate the situation?", is that yes but only if operators clearly understand when to configure it. (Draft also has it configured at the server.)

Also  this issue is much more complex too because there may be cases where it can be used in specific subscriber's ("customer premise") configurations but not in others. For example, in DOCSIS 3, it may be possible to use this when the eCM and eRouter are in the same box since then if the eCM is detected "down", the eRouter information can also be released. But if they aren't in the same box, this isn't necessarily possible. So, I think the simple configure at first DHCPv6 network device or server misses this point. There clearly are some networks where it may be "all or nothing", but there are others where it may be specific to an individual "subscriber".

I will say that some of this is very difficult to describe clearly (while "we" mostly know what you mean, it is important that this is clear to operators which may not know all of the considerations).

Anyway, as is clear from the discussion that work is still required on these documents - but that isn't unexpected of individual submissions undergoing WG Adoption discussions (again, I will point to https://tools.ietf.org/html/rfc7221#section-2.2).

-          Bernie

From: Sunil Gandhewar [mailto:[email-masked]]
Sent: Saturday, October 17, 2015 8:35 AM
To: [email-masked]
Cc: Bernie Volz (volz) <[email-masked]>; Dan Seibel <[email-masked]>; Ted Lemon <[email-masked]>; Brian Haberman <[email-masked]>; Sunil Gandhewar <[email-masked]>
Subject: RE: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27, 2015)

Hi All,

... (rest dropped to avoid message bloat)

---

From: Sunil Gandhewar <[email-masked]>
Date: Sat, 24 Oct 2015 03:00:40 +0000

Thanks Bernie, I accept your comments and will accommodate in the next version.

Regards,
Sunil Gandhewar
Juniper Networks, Inc.
[email-masked]

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 12:32 AM
To: Sunil Gandhewar; [email-masked]
Subject: RE: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27, 2015)

And:

-          Bernie

From: Sunil Gandhewar [mailto:[email-masked]]
Sent: Saturday, October 17, 2015 8:35 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; Dan Seibel <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; Brian Haberman <[email-masked]<mailto:[email-masked]>>; Sunil Gandhewar <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27, 2015)

Hi All,