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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 13 Oct 2015 16:19:40 +0000

Hello:

This mail initiates a call for adoption for the following documents as DHC WG work items:

                draft-gandhewar-dhc-relay-initiated-release, DHCP Relay Initiated Release (http://tools.ietf.org/html/draft-gandhewar-dhc-relay-initiated-release)

draft-gandhewar-dhc-v6-relay-initiated-release, DHCPv6 Relay Initiated Release (https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release)

PLEASE NOTE: As there were many emails in support of this work recently, you do NOT have to resend your support. Based on these emails and the support shown at the IETF-93 DHC WG session, we assume the WG supports adopting these documents. So, we are primarily looking to see if anyone opposes the adoption and their objections to that adoption. Of course, if you did not indicate your support already, please feel free to do so.

While the WG is primarily focused on working on DHCPv6, we are also including the DHCPv4 document in this case as it can be argued that this would help the IPv4 address shortage (as addresses can potentially be reused earlier than they might otherwise be).

There are currently 2 IPR claims against each of these drafts. (Please see http://datatracker.ietf.org/wg/dhc/documents/ as this could change at any time.)

Tomek and I will determine the consensus after Oct. 27th.

-          Bernie

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 16 Oct 2015 14:31:54 +0900

On Wed, Oct 14, 2015 at 1:19 AM, Bernie Volz (volz) <[email-masked]> wrote:

> PLEASE NOTE: As there were many emails in support of this work recently,
> you do NOT have to resend your support. Based on these emails and the
> support shown at the IETF-93 DHC WG session, we assume the WG supports
> adopting these documents. So, we are primarily looking to see if anyone
> opposes the adoption and their objections to that adoption. Of course, if
> you did not indicate your support already, please feel free to do so.
>
This document does not address the fact that if the DHCP relay issues a
release, the client is still configured with a non-expired lease and thus
has no way to know that its configuration is broken.

I this we should not adopt the document until we know that this concern can
be resolved.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Oct 2015 14:46:31 -0400

On Oct 16, 2015, at 1:31 AM, Lorenzo Colitti <[email-masked]> wrote:
> I this we should not adopt the document until we know that this concern can be resolved.

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.   I would like the emails that were "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 useful, why this particular solution is a better solution than using shorter lease times, and if they could characterize why they believe that to be the case.  This proposal makes a change to the DHCP state machine that can definitely produce interop problems and is likely to be poorly understood by operators, leading to surprises for them when their customers start calling.

It is possible that some of the conjecture in the introduction is actually supported by operational experience, but if so, we get limited information.   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, and why the right fix is for the relay agent to initiate a release.

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, and wants to use relay agents’ ability to snoop on the wire to make educated guesses as to whether clients are connected or not.   It’s not clear to me that DHCP is even the right way to solve the problem.   If it is, what is the economic motivation for doing something other than setting the lease interval to a fraction of the billing period (e.g., 15 minutes)?

This is a significant modification to the DHCP protocol, with very sketchy justification.   I am not going to say that the working group should never consider any such thing, but we need to think about whether this is the right solution before we start working on it as the solution.   I note that several operators chimed in saying that they think it’s a good idea, but several of them said almost exactly the same thing, every one of them is a newcomer to the working group, and no discussion occurred about why this is a good idea; all that we got was a bunch of people saying they thought it was a good idea.   I don’t think that’s enough to justify adoption.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 16 Oct 2015 19:32:20 +0000

Hi:

WG Chair Hat OFF …

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.)

We’d have some customers with nightmares when other devices stored state and somehow lost synchronization with the DHCP server … this is similar.

I do believe that some places are already doing this by generating Releases messages (though perhaps the authors can confirm) and likely have not seen issues in that setting because it meets the criteria I mentioned above. But once this is out of the bag, I feel it will be used in places it shouldn’t be and that will end in lots of issues and giving DHCP a black eye. It breaks the basic guarantee that DHCP provides – from RFC 2131:

      o Guarantee that any specific network address will not be in
        use by more than one DHCP client at a time,

I too am not in much favor of this. But by taking on this work, we could benefit the community by clarifying where it may be used and by making it clearer to the devices (DHCP server, Relays) involved what is going on (and potentially to reject the action).

Also taking on work means it goes under control of the WG – but that does not guarantee that it will actually ever become an RFC (perhaps because the WG abandons it or the IESG does not approve of the work).

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, October 16, 2015 2:47 PM
To: Lorenzo Colitti <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; [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)

On Oct 16, 2015, at 1:31 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
I this we should not adopt the document until we know that this concern can be resolved.

---

From: Dan Seibel <[email-masked]>
Date: Fri, 16 Oct 2015 14:28:48 -0600

I probably should have provided some more information in my support of these drafts and how I think they could be useful.  One particular use case that I have seen for this would be a situation where the dhcp server(s) and dhcp relay become out of sync in the following example (which we have encountered recently):

Dhcp relay agent on a edge router (BNG) has two dhcp servers that it relays requests to (Server 1, Server 2).  These servers “should" be maintaining state between them for a given address pool.

Client A comes online and gets IP address 10.1.1.1 from Server 1.
Client B comes online and gets IP address 10.1.1.1 from Server 2.  The BNG sees this duplication and drops the request.  Client B is not able to get an address, and as far as Server 2 is concerned Client B just hasn’t responded back to it’s offer and continues to offer this same address out to Client B with each discover that it gets.

Now in theory the above issue shouldn’t happen if the dhcp servers are operating like they should etc.  However these types of issues do come up more often than I would care to see and if there is some other way to provide more resiliency in the whole process I would like to see that.

The reality is that BNGs using dhcp relay will usually maintain dhcp state of the active clients as this is used for creating forwarding tables, providing anti-spoofing protection etc.  If there is an enhancement to the dhcp protocol that will enable the dhcp relay agent to communicate with the server to help solve some out of sync issues I think that is a good idea.

"I do believe that some places are already doing this by generating Releases messages (though perhaps the authors can confirm) and likely have not seen issues in that setting because it meets the criteria I mentioned above.”

I know of a couple vendors that do the above already (usually do a mac ping/ NS to the client and if there is no response then the relay sends a release).  One enhancement to this process the drafts would add is a way to see how many releases are happening from the actual client release vs releases from the dhcp relay do to other reasons.

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

Shorter lease times can help in some situations, but when operating networking equipment that has 10s of thousands of leases to maintain and deal with lowering lease times can only go so far before you start to hit resource / scalability issues on the BNG.

thanks

Dan

From: dhcwg <[email-masked]<mailto:[email-masked]>> on behalf of "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 1:32 PM
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[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:

WG Chair Hat OFF …

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, October 16, 2015 2:47 PM
To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; [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)

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Oct 2015 16:28:56 -0400

Hi all,

> This mail initiates a call for adoption for the following documents

I am speaking strictly as an interested bystander...

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.

None of the above three points are new, I think I saw all three points
made by other people on the list.

I think there should be some focus on determining if approaches like
short least times address the issue before developing a new set of
message exchanges.

Regards,
Brian

> 
> 
> draft-gandhewar-dhc-relay-initiated-release, DHCP Relay Initiated
> Release
> (http://tools.ietf.org/html/draft-gandhewar-dhc-relay-initiated-release)
>
>  draft-gandhewar-dhc-v6-relay-initiated-release, DHCPv6 Relay
> Initiated Release
> (https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release)
>
> 
> 
> 
> PLEASE NOTE: As there were many emails in support of this work
> recently, you do NOT have to resend your support. Based on these
> emails and the support shown at the IETF-93 DHC WG session, we assume
> the WG supports adopting these documents. So, we are primarily
> looking to see if anyone opposes the adoption and their objections to
> that adoption. Of course, if you did not indicate your support
> already, please feel free to do so.
> 
> 
> 
> While the WG is primarily focused on working on DHCPv6, we are also
> including the DHCPv4 document in this case as it can be argued that
> this would help the IPv4 address shortage (as addresses can
> potentially be reused earlier than they might otherwise be).
> 
> 
> 
> There are currently 2 IPR claims against each of these drafts.
> (Please see http://datatracker.ietf.org/wg/dhc/documents/ as this
> could change at any time.)
> 
> 
> 
> _______________________________________________ dhcwg mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 16 Oct 2015 20:53:49 +0000

Client A comes online and gets IP address 10.1.1.1 from Server 1.
Client B comes online and gets IP address 10.1.1.1 from Server 2.  The BNG sees this duplication and drops the request.  Client B is not able to get an address, and as far as Server 2 is concerned Client B just hasn't responded back to it's offer and continues to offer this same address out to Client B with each discover that it gets.

Of course, these document don't address the issue you raised - first, because the Relay could not release the offer from Server 2; you'd need a Relay-Decline mechanism. Also, if the address were released (not declined), the server might just reallocate it when the client retransmits. Declines are different than releases because it tells the server not to reuse the address (at least for a period of time).

While proper use of failover should prevent these issues, they do occur (though rarely). They occur mostly because of operator error because they panic when something goes wrong with failover and make mistakes (such as un-configuring failover but leaving both servers running).

---

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?

-          Bernie

From: Dan Seibel [mailto:[email-masked]]
Sent: Friday, October 16, 2015 4:29 PM
To: Bernie Volz (volz) <[email-masked]>; Ted Lemon <[email-masked]>; Lorenzo Colitti <[email-masked]>
Cc: [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)

Dhcp relay agent on a edge router (BNG) has two dhcp servers that it relays requests to (Server 1, Server 2).  These servers "should" be maintaining state between them for a given address pool.

Client A comes online and gets IP address 10.1.1.1 from Server 1.
Client B comes online and gets IP address 10.1.1.1 from Server 2.  The BNG sees this duplication and drops the request.  Client B is not able to get an address, and as far as Server 2 is concerned Client B just hasn't responded back to it's offer and continues to offer this same address out to Client B with each discover that it gets.

Now in theory the above issue shouldn't happen if the dhcp servers are operating like they should etc.  However these types of issues do come up more often than I would care to see and if there is some other way to provide more resiliency in the whole process I would like to see that.

"I do believe that some places are already doing this by generating Releases messages (though perhaps the authors can confirm) and likely have not seen issues in that setting because it meets the criteria I mentioned above."

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

thanks

Dan

Hi:

WG Chair Hat OFF ...

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.)

We'd have some customers with nightmares when other devices stored state and somehow lost synchronization with the DHCP server ... this is similar.

I do believe that some places are already doing this by generating Releases messages (though perhaps the authors can confirm) and likely have not seen issues in that setting because it meets the criteria I mentioned above. But once this is out of the bag, I feel it will be used in places it shouldn't be and that will end in lots of issues and giving DHCP a black eye. It breaks the basic guarantee that DHCP provides - from RFC 2131:

Also taking on work means it goes under control of the WG - but that does not guarantee that it will actually ever become an RFC (perhaps because the WG abandons it or the IESG does not approve of the work).

-          Bernie

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.   I would like the emails that were "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 useful, why this particular solution is a better solution than using shorter lease times, and if they could characterize why they believe that to be the case.  This proposal makes a change to the DHCP state machine that can definitely produce interop problems and is likely to be poorly understood by operators, leading to surprises for them when their customers start calling.

It is possible that some of the conjecture in the introduction is actually supported by operational experience, but if so, we get limited information.   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, and why the right fix is for the relay agent to initiate a release.

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, and wants to use relay agents' ability to snoop on the wire to make educated guesses as to whether clients are connected or not.   It's not clear to me that DHCP is even the right way to solve the problem.   If it is, what is the economic motivation for doing something other than setting the lease interval to a fraction of the billing period (e.g., 15 minutes)?

This is a significant modification to the DHCP protocol, with very sketchy justification.   I am not going to say that the working group should never consider any such thing, but we need to think about whether this is the right solution before we start working on it as the solution.   I note that several operators chimed in saying that they think it's a good idea, but several of them said almost exactly the same thing, every one of them is a newcomer to the working group, and no discussion occurred about why this is a good idea; all that we got was a bunch of people saying they thought it was a good idea.   I don't think that's enough to justify adoption.

---

From: Dan Seibel <[email-masked]>
Date: Fri, 16 Oct 2015 15:06:51 -0600

Since I am new to this excuse the question if it is obvious, but could the draft be "enahanced" by the working group to broaden the scope beyond relay-release?  As part of the process would adding say a Relay-decline mechanism be something that could be looked at?

Dan

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, October 16, 2015 2:54 PM
To: Dan Seibel; Ted Lemon; Lorenzo Colitti
Cc: [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)

---

-          Bernie

thanks

Dan

Hi:

WG Chair Hat OFF ...

-          Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 16 Oct 2015 21:22:09 +0000

Dan:

When a draft is an individual submission, it is up to the authors as to whether they will take suggestions or not.

When a draft is a WG work item (I.e., adopted by the WG), the changes to the draft are driven by the consensus process – changes need to be discussed and agreed upon (though usually that is based on suggested changes and if no one objects, the change is made).

You may want to see https://tools.ietf.org/html/rfc7221:

   1.  Remind current draft owners that they are transferring change
       control for the document to the IETF.  (This is a particularly
       significant point for a document covered by proprietary
       interests, because it typically entails a negotiation between the
       current owners and the IETF, including a formal agreement.)

And:

2.2.  Criteria for Adoption

   No formal specification for working group 'adoption' of a draft
   exists; the current document is meant to provide a description of
   common activities for this, but again note that it is not normative.

   There are some basic considerations when deciding to adopt a draft:

   *  Is there a charter milestone that explicitly calls for such a
      document?

   *  Is the topic of the I-D within scope for the working group?

   *  Is the purpose of the draft sufficiently clear?

   *  Does the document provide an acceptable platform for continued
      effort by the working group?

   *  What are the process or technical objections to adoption of the
      draft?

   *  Is the draft likely to be completed in a timely manner?

   *  Does the intended status of the document seem reasonable to the
      working group?

   *  If not already in scope, is a simple modification to the charter
      feasible and warranted?

   *  Does the draft carry known intellectual property rights issues?

   *  Is there strong working group support for working on the draft?

   Adoption has some basic pragmatics:

      Rough consensus:  Working group agreement to adopt is not required
         to be unanimous [RFC2418].

      Initial, not final:  The writing quality is not required to be
         "ready for publication", although writing quality can be a
         problem and does need explicit attention; although not
         mandatory, it is good practice to check whether a new working
         group draft passes [IDNITS].

      Adoption, not approval:  The document is not required to already
         contain a complete and/or sufficient solution, although of
         course this can be helpful.  Equally, adoption by a working
         group does not guarantee publication of the document as an RFC.

      Group, not Chairs:  Concerning the draft, the position of the
         Working Group Chairs has no special authority, except to assess
         working group consensus.

   REMINDER:  Once a working group adopts a draft, the document is owned
      by the working group and can be changed however the working group
      decides, within the bounds of IETF process and the working group
      charter.  Absent explicit agreement, adopting a document does not
      automatically mean that the working group has agreed to all of its
      content.  So a working group (or its charter) might explicitly
      dictate the basis for retaining, removing, or modifying some or
      all of a draft's content, technical details, or the like.
      However, in the absence of such constraints, it is worth having
      the adoption process include a sub-process of gathering working
      group concerns about the existing draft and flagging them
      explicitly.

The REMINDER is important since even the comments raised during the Adoption call don’t necessarily prevent adoption. They may just point to areas that require further work by the WG.

- Bernie

From: Dan Seibel <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2015 at 5:06 PM
To: Bernie Volz <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[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)

Since I am new to this excuse the question if it is obvious, but could the draft be “enahanced” by the working group to broaden the scope beyond relay-release?  As part of the process would adding say a Relay-decline mechanism be something that could be looked at?

Dan

Cc: [email-masked]<mailto:[email-masked]>

Of course, these document don’t address the issue you raised – first, because the Relay could not release the offer from Server 2; you’d need a Relay-Decline mechanism. Also, if the address were released (not declined), the server might just reallocate it when the client retransmits. Declines are different than releases because it tells the server not to reuse the address (at least for a period of time).

---

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?

-          Bernie

From: Dan Seibel [mailto:[email-masked]]
Sent: Friday, October 16, 2015 4:29 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: [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)

thanks

Dan

Hi:

WG Chair Hat OFF …

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Oct 2015 17:59:18 -0400

> I too am not in much favor of this. But by taking on this work, we could benefit the community by clarifying where it may be used and by making it clearer to the devices (DHCP server, Relays) invol…

Perhaps so.   However, 

> Also taking on work means it goes under control of the WG – but that does not guarantee that it will actually ever become an RFC (perhaps because the WG abandons it or the IESG does not approve of…

This is completely untrue, and you’ve seen it go the other way, Bernie.   Not recently, I admit, but we used to have all sorts of experiments going on with DHCPv4 that were blessed in retrospect.   What I mean by untrue is as follows:

1. If people don’t like what the working group is doing, they can still experiment on their own.
2. If people conclude that the working group is not going to work on this, they might convince the ISE to publish it.
3. If the working group adopts something, there is a general presumption that the working group is going to bring it to completion.   If you do a consensus call, and nobody objects, the presumption is that the document has consensus, because the working group adopted it.   So the adoption call isn’t quite as lightweight as you’re suggesting.   I realize that in practice we’ve adopted things and dropped them _many_ times in the past, but in principle adoption is a significant action.
4. If the working group puts forward a draft, the IESG is _very_ unlikely to refuse to publish it.   Speaking as a former IESG member, I can attest that the IESG will generally publish a document even over the objection of an AD unless the responsible AD concludes that it shouldn’t be published.   They may ask for heavy revisions, but I think that’s extremely unlikely in this case—the bulk of DHCP expertise in the world is embodied in this working group, and the IESG is unlikely to quarrel with us if we decide some proposal is safe.

So I really encourage you to hold off on adopting this until we feel more confident about it, rather than adopting it and _then_ trying to get confident about it.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Oct 2015 18:08:19 -0400

> Now in theory the above issue shouldn’t happen if the dhcp servers are operating like they should etc.  However these types of issues do come up more often than I would care to see and if there is…

To paraphrase, "The DHCP server software I am using does not have a working failover implementation, and consequently I would like the DHCP protocol to be changed in order to address the failings of that server."   I’m sorry, I know that’s a bit cold, but seriously, this is a solved problem.   A protocol extension that makes DHCP less reliable in order to address a lack of reliability in a server seems like the wrong thing to do.

> The reality is that BNGs using dhcp relay will usually maintain dhcp state of the active clients as this is used for creating forwarding tables, providing anti-spoofing protection etc.  If there is…

DHCP leasequery?

> I know of a couple vendors that do the above already (usually do a mac ping/ NS to the client and if there is no response then the relay sends a release).  One enhancement to this process the draft…

A ping test tells you that the client is unreachable at the time of the test.   It doesn’t tell you whether it is actually offline, nor whether it has forgotten its lease.

> Shorter lease times can help in some situations, but when operating networking equipment that has 10s of thousands of leases to maintain and deal with lowering lease times can only go so far before…

Scalability on the BNG?   This is the first I’ve heard of that.   Can you expand on this?   The BNG is just a relay agent, right?   Where’s the scalability issue there?

---

From: Dan Seibel <[email-masked]>
Date: Fri, 16 Oct 2015 16:41:49 -0600

No that isn’t cold, that would normally be my response to “solve my misconfigured / buggy device by you changing what you are doing”.  I was curious if there is the potential to add another layer of resiliency without obviously making dhcp worse.

DHCP leasequery?

Yes thanks for reminding me, this could potentially help a number of situations.

Sorry, “MAC ping” should have read ARP/NS.  Which works fine to detect if a client gateway has been disconnected or is unreachable but yes can’t tell you if it has forgotten it’s lease.

BNGs would do more than just relay dhcp traffic.  They would usually need to maintain state of all the dhcp sessions to create forwarding tables etc.  This involves processing all dhcp traffic that passes through them.  They also may do authentication/ accounting on every dhcp request.  Short lease times can also be a major issue if you have some sort of interruption between the relay and the clients causing them to loose their leases.  When the connectivity is restored you end up with a dhcp discovery storm of thousands of clients trying to obtain service all at the same time.  Short and long dhcp leases each have their pros and cons, and trying to find the balance seems to be a bit of an art.

Dan

---

From: Benoit Lourdelet <[email-masked]>
Date: Wed, 21 Oct 2015 14:18:10 +0000

Hello Lorenzo and Bernie,

I read section 1.1  of this document  https://tools.ietf.org/html/draft-gandhewar-dhc-v6-relay-initiated-release-01 .
It is addressing the issue you are referring to.
Adding to that the explanations that Sunil gave to the list on this very topic, I feel that the concern is addressed.
If there is a need to create a sub section of 1.1 to signal that a particular block of text addresses "client is still configured with a non-expired lease”, I thing Sunil will agree to amend his draft.

That said, this draft addresses real day-to-day operational concerns of a number of Service Providers. We should adopt it so they can deploy a well-defined standard solution.

regards

Benoit

From: dhcwg on behalf of Lorenzo Colitti
Date: Friday, October 16, 2015 at 7:31 AM
To: "Bernie Volz (volz)"
Cc: "[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)

On Wed, Oct 14, 2015 at 1:19 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:

This document does not address the fact that if the DHCP relay issues a release, the client is still configured with a non-expired lease and thus has no way to know that its configuration is broken.