Subject: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00

From: Richard Patterson <[email-masked]>
Date: Tue, 5 Jun 2018 21:02:40 +0100

Hi All,

The above new draft has been posted to address an operational problem
that exists with current IPoE (non-PPPoE) fixed line broadband
services.
It can be found here:
https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/

Hopefully the draft covers the problem statement sufficiently, but in
summary, PPPoE makes use of LCP echo/replies to detect WAN failures,
DHCPv4/6 currently has no such mechanism.
After backhaul migrations or BNG maintenance/failure, an IPoE client
can be left with a stale DHCP lease for up to the Valid Lifetime.

This draft proposes the use of regular ARP and ND for link monitoring,
to proactively expire DHCP leases early, and to trigger renewals or
getting a new lease from scratch.

The intarea WG was chosen as it doesn't neatly fit within the charters
of either v6ops or dhc, and because it proposes new DHCPv4 and DHCPv6
Options. Although we expect discussions in both of these WGs as well.

Thanks for comments already received from Ian, and Bernie, that helped
shape this -00.

-Richard

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jun 2018 10:51:20 +0200 (CEST)

Hi,

I'd like to bring attention to this draft. It's trying to solve a problem 
when using IPoE and when to consider WAN being down (RFC7084), if there is 
no physical link-down.

I had an idea to use the ND state of the RA sending router, if ND to that 
doesn't work for a certain amount of time (perhaps we can even use the 
existing ND state and just monitor it), and if that indicates that 
connectivity has been dead sufficiently long, kick down DHCP T1 timers and 
try to renew, and if that is not successful, expire DHCP PD completly and 
do everything RFC7084 says to do.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 8 Jun 2018 22:59:24 +0900

NUD is not necessarily a good signal for this since by typically it is
quiet for quite a while (30s with no traffic), and then suddenly gets
impatient (if there is no response to at least one out of three packets 1
second apart, it declares a failure).

It makes a lot of sense for a host that can use upper-layer hints from TCP
or other transport-layer protocols, but not so much for a router.

On Fri, Jun 8, 2018 at 5:51 PM Mikael Abrahamsson <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jun 2018 16:05:32 +0200

Hi,

> or other transport-layer protocols, but not so much for a router.

For a router, BFD seems to one of the few things that IETF seems to be
able to agree on.  Thus, implementations exist, and especially on the ISP
side, vendors actually implement this somewhere distributed nowadays...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jun 2018 16:11:45 +0200 (CEST)

On Fri, 8 Jun 2018, Gert Doering wrote:

> able to agree on.  Thus, implementations exist, and especially on the 
> ISP side, vendors actually implement this somewhere distributed 
> nowadays...

Are you aware of BFD implementations suited to be implemented on the HGW? 
I believe this is going to have to be run in echo mode without BFD needed 
to be supported on the ISP side.

---

From: Richard Patterson <[email-masked]>
Date: Fri, 8 Jun 2018 15:14:29 +0100

> side, vendors actually implement this somewhere distributed nowadays...

Sadly it's not widely supported on consumer routers, and full BFD
would be quite heavy.

Broadband Forum's TR-146 actually already discusses this issue and
suggests the use of BFD echo.
In the next version of this draft will reference TR-146, as well as
prefer BFD echo as the health check mechanism if it's available.
The IPOE_HEALTH DHCP Option interval and limit parameters will
continue to be used, as will the behaviours defined once they're
reached.

-Richard

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jun 2018 16:19:10 +0200

Hi,

> to be supported on the ISP side.

I haven't yet run any of this, but Google turned up a few hits

 https://github.com/dyninc/OpenBFDD
  "an open source implemnentation of the BFD protocol"

 https://github.com/thehajime/kbfd
  "ancient Linux BFD (...) implementation"
  [as a linux kernel module, plus a zebra/quagga patch to tap into
   kBFD for, BFD control and reporting]

 https://docs.cumulusnetworks.com/display/CL35/Bidirectional+Forwarding+Detection+-+BFD
  (only echo mode, page talks about FRRouting, frrouting.org does not 
   mention BFD though)

 BIRD seems to have a BFD module

so - not sure if any of these are suitable for a memory- and CPU-starved
CPE, but "BFD the protocol" isn't hard, the tricky bit would be "hook 
into the state signalling logic of your router firmware"...

Gert Doering
        -- NetMaster