Re: [dhcwg] WG Adoption call for draft-gandhewar-dhc-relay-initiated-release and draft-gandhewar-dhc-v6-relay-initiated-release

[김우태 <[e-mail]>]

Hi, All

I'm in support of this proposal to be evaluated as to whether they
identified specific use cases the authors were aware of in real-world
deployments where this work would be very useful, why this particular
solution is a better solution than using shorter lease times.

In real-world, if using shorter lease times, there are so many things to
consider. One of things is that DHCP server have to process dhcp messages
as many as shorter lease time. It may also impacts on dhcp relays. In
perspective of ISP, it's not good idea to use shorter lease time, not to
use this proposal.

Best Regards,
Utae



-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of dhcwg-request@ietf.
org
Sent: Saturday, October 17, 2015 9:35 PM
To: [e-mail]
Subject: dhcwg Digest, Vol 138, Issue 25

Send dhcwg mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/dhcwg
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of dhcwg digest..."


Today's Topics:

   1. Re: I-D Action: draft-ietf-dhc-dhcpv6-yang-00.txt (Linhui Sun)
   2. Re: WG Adoption call for
      draft-gandhewar-dhc-relay-initiated-release and
      draft-gandhewar-dhc-v6-relay-initiated-release (Expires Oct 27,
      2015) (Sunil Gandhewar)


----------------------------------------------------------------------

Message: 1
Date: Sat, 17 Oct 2015 10:33:48 +0800
From: Linhui Sun <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-yang-00.txt
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="utf-8"

Hi all,

We have updated the WG version for the DHCPv6 YANG model. The major changes
from the version in Prague include,

1) Resolve the DUID issue by defining an union type.

2) Add "new-or-standard-option" container for the model extensibility and
also provide a generic form to configure options.

3) Fix the YANG model grammar errors, fulfill the description of data nodes.

Could you please review the draft and your valuable comments are more than
welcome.

Best regards,
Linhui

2015-10-16 19:27 GMT+08:00 <[e-mail]>:

>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Dynamic Host Configuration Working 
> Group of the IETF.
>
>         Title           : YANG Data Model for DHCPv6 Configuration
>         Authors         : Yong Cui
>                           Hao Wang
>                           Linhui Sun
>                           Ted Lemon
>                           Ian Farrer
>         Filename        : draft-ietf-dhc-dhcpv6-yang-00.txt
>         Pages           : 84
>         Date            : 2015-10-16
>
> Abstract:
>    There has no unified method to configure DHCPv6 server ,relay and
>    client itself, always pre-configured manually by operators.
>
>    IETF netmod WG has developed a general data model for NETCONF
>    protocol, YANG data model [RFC6020].
>
>    This document defines a YANG data model for the configuration and
>    management of DHCPv6 server, DHCPv6 relay and DHCPv6 client.  With
>    this model, the operators can configure and manage the devices by
>    using NETCONF.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-yang/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-00
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20151017/e71945a
4/attachment.html>

------------------------------

Message: 2
Date: Sat, 17 Oct 2015 12:34:32 +0000
From: Sunil Gandhewar <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: Sunil Gandhewar <[e-mail]>, "Bernie Volz \(volz\)"
	<[e-mail]>, Ted Lemon <[e-mail]>
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)
Message-ID:
	
<[e-mail]
ook.com>
	
Content-Type: text/plain; charset="us-ascii"

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.
[e-mail]




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20151017/3d45f2e
c/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg


------------------------------

End of dhcwg Digest, Vol 138, Issue 25
**************************************