Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 16:22:51 +0000

Something that came up in discussions with an ISP recently: the CPE router doc doesn't require that the CPE router retain DHCP configuration between reboots.   This was identified as an issue in the case of power outage recovery—if the DHCP server is overloaded because a large number of machines come back at once, the CPE router might fail to use the network for an extended period of time, even though it still, in theory, has a valid configuration.

Is this something that's been discussed?   Any thoughts?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2012 16:45:12 +0000

Ted,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, August 16, 2012 12:23 PM
To: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

>Something that came up in discussions with an ISP recently: the CPE router doc doesn't require that the CPE router retain DHCP configuration between reboots.   >This was identified as an issue in the case of power outage recovery-if the DHCP server is overloaded because a large number of machines come back at once, the >CPE router might fail to use the network for an extended period of time, even though it still, in theory, has a valid configuration.

>Is this something that's been discussed?   Any thoughts?

Sorry, I am not aware of the issue you speak of. If more details can be provided, we can discuss the issue. However, there is no text in rfc6204bis that mandates the CPE router retain DHCP configuration between reboots?  The subtle point is with one DHCPv6 requirement in W-5 mandates the DHCPv6 DUID from RFC 3315 be persistent between reboots.  However, for the DUID persistence, the CPE does not need to retain the DUID between reboots.  The CPE just generates the DUID-LL and the DUID is persistent across CPE reboots.

Thanks,

Hemant

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Aug 2012 16:53:24 +0000

Ted:

Can you define what you mean by reboots? For example, is this restricted to the eRouter (eCM+eRouter) when the eCM triggers a reboot because it detected the cable link went down? This does seem like a worthwhile recommendation - though there are pros and cons to it because one reason the eCM might have rebooted was because of a configuration change and if the server isn't able to handle the load, the Confirm (3315)/Rebind (3633) would also not be processed leaving the CPE without definitive information.

If this were to include power failures, how would the CPE know how much time has elapsed while it was down which could cause more significant issues because of the lease time -- and having to maintain a clock via battery backup is probably not a good idea.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, August 16, 2012 12:23 PM
To: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

Something that came up in discussions with an ISP recently: the CPE router doc doesn't require that the CPE router retain DHCP configuration between reboots.   This was identified as an issue in the case of power outage recovery-if the DHCP server is overloaded because a large number of machines come back at once, the CPE router might fail to use the network for an extended period of time, even though it still, in theory, has a valid configuration.

Is this something that's been discussed?   Any thoughts?
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 16:53:40 +0000

On Aug 16, 2012, at 12:45 PM, Hemant Singh (shemant) wrote:
Sorry, I am not aware of the issue you speak of. If more details can be provided, we can discuss the issue. However, there is no text in rfc6204bis that mandates the CPE router retain DHCP configuration between reboots?  The subtle point is with one DHCPv6 requirement in W-5 mandates the DHCPv6 DUID from RFC 3315 be persistent between reboots.  However, for the DUID persistence, the CPE does not need to retain the DUID between reboots.  The CPE just generates the DUID-LL and the DUID is persistent across CPE reboots.

No, I'm talking about remembering DHCP configuration information across reboots.   If DHCP hands out an address with a one-week lifetime, and then there's a power outage a day later, the CPE should have retained that address and should go through the RFC3315 Confirm processing to validate it, but should use it anyway unless the Confirm gets a negative response.   Similarly with Prefix Delegation (Confirm processing for PD is something that's not yet standardized, but it's in process in the working group, so you'd have to decide whether you can tolerate a normative reference to that draft).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:06:53 +0000

On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote:
If this were to include power failures, how would the CPE know how much time has elapsed while it was down which could cause more significant issues because of the lease time -- and having to maintain a clock via battery backup is probably not a good idea.

I'm specifically referring to power outages.   If the CPE doesn't get a response from a Confirm, doesn't it get to use the address?   The question about the clock is interesting, but it seems like a safe assumption that a power cycle is short; if it's long, and wasn't the result of a power outage, the Confirm transaction will prevent anything bad from happening.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:10:21 +0000

On Aug 16, 2012, at 12:58 PM, David Miles wrote:
Is this saving from 4 messages to 2 messages enough? Perhaps there are better ways to address the DHCP scalability issue through the use of more distributed DHCP infrastructure.

The point is that if you don't get a response to a Confirm, presumably you can continue using the address, whereas if you toss your old state and start over, you can't.

It's not strictly a scalability issue—any sort of prolonged outage on the DHCP server following a power failure would do it.   The idea is just to have a fallback position in case for whatever reason the DHCP server can't respond.   For instance, suppose there's a temporary DHCP server outage coincident with the CPE device being power cycled.   We want it to come back up even so, right?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Aug 2012 17:11:00 +0000

The Confirm doesn't return remaining lifetimes or confirm actual leases - all it confirms is that the client hasn't moved (i.e., the prefixes being used by the client are still valid for where it is connected).

So, if the lease have indeed expired, there would be nothing to indicate that.

Again, I think if the CPE knows it is just a reboot or has battery backup to keep a clock running, it would be fine for it to retain the lease information across reboots.

But if not, this would be a bad idea - unless the client were to do a Renew or Rebind when it came back instead of using Confirm.

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 1:07 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:32:32 +0000

On Aug 16, 2012, at 1:11 PM, Bernie Volz (volz) wrote:
The Confirm doesn’t return remaining lifetimes or confirm actual leases – all it confirms is that the client hasn’t moved (i.e., the prefixes being used by the client are still valid for where it is connected).

But if not, this would be a bad idea – unless the client were to do a Renew or Rebind when it came back instead of using Confirm.

I would be happy to see a requirement that says that if the device has a clock that survives power cycles, it should Confirm the binding rather than starting from scratch.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 16 Aug 2012 17:50:08 +0000

Service providers have been dealing with "simultaneous" mass repowering of routers for a long time. There currently exist requirements for multiple retries of all necessary protocols, at random intervals (within reasonable limits). I believe that all requirements necessary for such staggered retries are in place, and are sufficient for dealing with mass coming-on-line. I also believe that maintaining DHCP configuration across reboots is undesirable. If we were to say anything, I would prefer to forbid it, rather than mandate it. But, I don't think we need to be saying anything at all, because, thankfully, I'm not aware of devices that maintain DHCP config across reboots.

I don't believe that the scenario of mass power outage that takes out massive quantities of CE routers + the DHCP server, but that leaves all other access network elements intact is a probable scenario. As such, I don't think it's worthy of a requirement.

It ain't broke. Please, let's not "fix" it.
Barbara

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Aug 2012 17:57:18 +0000

Yes, that would be fine with me as well. Though not sure how realistic it will be as keeping the cost of these devices down is likely a key factor (a less costly solution is likely a capacitor that would keep the clock alive for a short duration).

And, given where this document is in the pipeline, do you really think this is worth it?

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 1:33 PM
To: Bernie Volz (volz)
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2012 19:46:28 +0000

The -10 was published today to address review in the IESG.  Thus we really should stay away from adding any new requirement to rfc6204bis.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, August 16, 2012 1:57 PM
To: Ted Lemon
Cc: Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

-        Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 19:53:04 +0000

On Aug 16, 2012, at 3:46 PM, Hemant Singh (shemant) wrote:
The -10 was published today to address review in the IESG.  Thus we really should stay away from adding any new requirement to rfc6204bis.

Okay, sorry—I didn't realize it was in IESG review.   Maybe in 6204bisbis...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 16 Aug 2012 19:57:01 +0000

No problem, Ted.  6204ter be OK.  We call bisbis as tertiary.

Thanks,

Hemant

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 3:53 PM
To: Hemant Singh (shemant)
Cc: Bernie Volz (volz); Operations Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

Okay, sorry-I didn't realize it was in IESG review.   Maybe in 6204bisbis...