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]>]

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


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


From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Thursday, October 22, 2015 12:32 AM
To: Sunil Gandhewar; [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)

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 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:[e-mail]]
Sent: Saturday, October 17, 2015 8:35 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>; Dan Seibel <[e-mail]<mailto:[e-mail]>>; Ted Lemon <[e-mail]<mailto:[e-mail]>>; Brian Haberman <[e-mail]<mailto:[e-mail]>>; Sunil Gandhewar <[e-mail]<mailto:[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)

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.

... (rest dropped to avoid message bloat)