Subject: [v6ops] draft-patterson-intarea-ipoe-health

From: Fred Baker <[email-masked]>
Date: Sat, 9 Jun 2018 14:58:12 -0700

Looking for comments on draft-patterson-intarea-ipoe-health-00. The authors would like to discuss it in v6ops at IETF 102 (Montreal). Do folks find it interesting/useful?

The primary working group for this will be intarea, for reasons related to the charter. However, it would be useful to know that the problem is a general one, and get comments on the proposed solution.

Sent from my iPad

---

From: Simon Allard <[email-masked]>
Date: Mon, 11 Jun 2018 21:45:15 +0000

Hi Fred

IPoE Health is something we have struggled with. We are a NZ based ISP with a large IPoE customer base.

We are currently running our BNG's with 5 minute lease timers to try and get around the issue where the BNG declares the subscriber as dead and kills the session, however the client remains online until the lease expires.

We have had discussions with our CPE vendors around arp detection/resetting DHCP however those conversations have not gone well, with the CPE vendor saying that ARP and DHCP are 2 different things and can't be mixed. We also looked at doing something similar with DNS (3 DNS request fail and it turns DHCP into discovery mode), and BFD but nothing really got passed the whiteboard discussions phase.

If there was an accepted RFC we could point the vendors at, it would make those discussions much easier.

Cheers,
Simon
AS9790

Simon Allard | Development & Operations Manager
D: +64 9 550 2790E: [email-masked]
M: +64 20 1000 790W: vocusgroup.co.nz
A: Level 2, 1-7 The Strand, Takapuna 0622

---------- Forwarded message ---------
From: Fred Baker <[email-masked]>
Date: Sat, 9 Jun 2018 at 22:58
Subject: [v6ops] draft-patterson-intarea-ipoe-health
To: <[email-masked]>
Cc: <[email-masked]>

Sent from my iPad
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Job Snijders <[email-masked]>
Date: Mon, 11 Jun 2018 22:05:15 +0000

I agree there is an issue, multiple access providers confirmed they are
making (never great) trade-offs between the lease periods and potential
downtime for customers.

I think the proposed solution is interesting in that it seems quite
manageable to retrofit this in existing deployments through a software
update and avoiding the introduction of new protocols. This may not be the
approach with the most technical elegance and sophistication, but is
perhaps "just good enough" for the problem at hand. IETF yearns for
feedback from operators, and this draft is exactly that.

I encourage the authors to produce running code and run some trials to
validate the idea. It'll be hard to argue with proven ideas :-)

Kind regards,

Job

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Jun 2018 15:54:00 -0700

Thanks, Simon. This is being pursued in int-area, as it will require a DHCP change. However, it is an operational issue, which is where v6ops comes in.

> On Jun 11, 2018, at 2:45 PM, Simon Allard <[email-masked]> wrote:
> 
> Hi Fred
> 
> Simon Allard​	 | 	Development & Operations Manager
> D: 	+64 9 550 2790	 	E: 	[email-masked]
> M: 	+64 20 1000 790	  	W: 	vocusgroup.co.nz

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Jun 2018 15:54:44 -0700

Thanks, Job. This is being pursued in int-area, as it will require a DHCP change. However, it is an operational issue, which is where v6ops comes in.

> On Jun 11, 2018, at 3:05 PM, Job Snijders <[email-masked]> wrote:
> 
> I agree there is an issue, multiple access providers confirmed they are making (never great) trade-offs between the lease periods and potential downtime for customers.
> 
> I think the proposed solution is interesting in that it seems quite manageable to retrofit this in existing deployments through a software update and avoiding the introduction of new protocols. This may not be the approach with the most technical elegance and sophistication, but is perhaps "just good enough" for the problem at hand. IETF yearns for feedback from operators, and this draft is exactly that.
> 
> I encourage the authors to produce running code and run some trials to validate the idea. It'll be hard to argue with proven ideas :-)
> 
> Kind regards,
> 
> Job

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Jun 2018 08:51:54 +0200

Simon,

I can’t recall right now if we wrote the general idea down, but there is something similar alluded to in e.g 6RD. 

Make the assertion that the CPE is responsible for the forwarding state in the BNG. State is maintained with DHCP. Lost state in the BNG is detected by the CPE using something akin to BFD echo mode. 

I’d be happy if someone had time to write it up. 

Cheers 
Ole

> On 11 Jun 2018, at 23:45, Simon Allard <Simon.Allard=[email-masked]> wrote:
> 
> Hi Fred
>

---

From: Richard Patterson <[email-masked]>
Date: Tue, 12 Jun 2018 10:01:19 +0100

On Tue, 12 Jun 2018 at 07:52, Ole Troan <[email-masked]> wrote:

> Make the assertion that the CPE is responsible for the forwarding state in
> the BNG. State is maintained with DHCP. Lost state in the BNG is detected
> by the CPE using something akin to BFD echo mode.
>

Broadband Forum's TR-146 suggests the use of BFD Echo as a detection
mechanism, but it then only talks about triggering a renew, which often
times won't help.

I'm about to upload -01 of our draft which references TR-146, and now has a
section for BFD Echo.   This new section will prefer the use of BFD Echo as
the health check mechanism over ARP/ND when it is available.   If you could
take a look at it and let us know if it's in-line with your thinking please?

-Richard

---

From: Ole Troan <[email-masked]>
Date: Tue, 12 Jun 2018 11:56:44 +0200

Richard,

> Broadband Forum's TR-146 suggests the use of BFD Echo as a detection mechanism, but it then only talks about triggering a renew, which often times won't help.
> 
> I'm about to upload -01 of our draft which references TR-146, and now has a section for BFD Echo.   This new section will prefer the use of BFD Echo as the health check mechanism over ARP/ND when it is available.   If you could take a look at it and let us know if it's in-line with your thinking please?

Ah, yes that's where it ended up. ;-)
Of course it doesn't have to be an actual BFD packet for that matter. But BFD echo has the whole framework described, so that's probably useful to reuse.
The only thing required is that the CPE can send a packet to itself via the BNG.

Cheers,
Ole