Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-health-02.txt

From: Richard Patterson <[email-masked]>
Date: Tue, 19 Jun 2018 17:15:27 +0100

Thanks for the comments on and off the v6ops list, we've published a
new version of draft-patterson-intarea-ipoe-health.
The major changes can summarised as:
 - Emphasised preference for use of BFD echo as the health check mechanism.
 - Removed lifetime expiration from Behaviour 2 and clarified usage.
 - Updated Behaviour 3 with instructions for whilst mid-renew/rebind.
 - Reworded multihoming section.
 - Added Acknowledgements.

Please continue providing feedback, and if anyone has a relationship
with DHCP client developers, or CPE vendors, we'd love to start a
dialogue there too.

-Richard

On 19/06/2018, 17:07, "[email-masked]"
<[email-masked]> wrote:

    A new version of I-D, draft-patterson-intarea-ipoe-health-02.txt
    has been successfully submitted by Richard Patterson and posted to the
    IETF repository.

    Name:draft-patterson-intarea-ipoe-health
    Revision:02
    Title:IPoE Client Health Checking
    Document date:2018-06-19
    Group:Individual Submission
    Pages:13
    URL:
https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-02.txt
    Status:
https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/
    Htmlized:
https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-02
    Htmlized:
https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health
    Diff:
https://www.ietf.org/rfcdiff?url2=draft-patterson-intarea-ipoe-health-02

    Abstract:
       PPP over Ethernet clients have the functionality to detect path
       unavailability by using PPP Keepalives.  IP over Ethernet does not
       have this functionality, and it's not specified when an IP over
       Ethernet client should consider its WAN connectivity down, unless
       there is a physical layer link down event.

       This document describes a way for IP over Ethernet clients to achieve
       connectivity validation, similar to that of PPP over Ethernet, by
       using BFD Echo, or ARP and Neighbor Discovery functions.

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 19 Jun 2018 16:40:40 +0000

Hi Richard,

I have a few more comments:

-	What is the behavior for “If the IPoE client is already in the renew or rebind state when Behaviour 2 is triggered”? Should it be the same as Behavior 3?
-	SHOULD the client use RAPID COMMIT option for Behaviors 2 and 3?

-	Missing a diagram for the problem statement: Can you show please, using a simple diagram, how DHCPv6 lease  becomes stale?
-	Provide diagrams for all options, showing how a client recovers after an edge router outage. For example, if 3.3 ND NUD finds the edge router is unreachable, show the benefits of RENEW and SOLICIT options and how the client will communicate to off-link destinations using the old or a new DHCPv6 address.
-	Provide a diagram showing how a router outage between a Relay Agent and ISP can be detected (i.e. RA from the edge router) and how the client can recover connectivity to off-link destinations.

Regards,
Dusan.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Richard
> Patterson
> Sent: Tuesday, June 19, 2018 12:15 PM
> To: [email-masked] list <[email-masked]>
> Subject: [v6ops] New Version Notification for draft-patterson-intarea-ipoe-
> health-02.txt
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth-
> 2D02.txt&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iC
> rhIoUWB8YLZU23029sMQGQ2kY&m=FJwQBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=z2SDIZx5ZVqdDeX-
> F6F67UYa7QvoYqztNWIJaxqLEno&e=
>     Status:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth_&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=FJwQBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=v7aXpuARxNSzpA9cRkgYk_zrCma9a
> CS3zwIAOYxY6Ps&e=
>     Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dpatterson-2Dintarea-2Dipoe-2Dhealth-
> 2D02&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=FJwQBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=bxaObQg7CeYxZYVk-DrSo0sni-
> BAS8x3Mwh7u4lJx5g&e=
>     Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3i
> CrhIoUWB8YLZU23029sMQGQ2kY&m=FJwQBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=g-
> iDyHsg_HC3Hm4GDywY1OczDjzknyiSlKLbOI5ZMX8&e=
>     Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dpatterson-2Dintarea-2Dipoe-
> 2Dhealth-
> 2D02&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=FJwQBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=1AjfSVnLtdB6QP659cG8DnYEu12Bb
> DzQKSG6zZM_bOY&e=
> 
>     Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=FJw
> QBzILW8V8e-
> 2AqJY0R5EYzgeOPNYEjbQNZVrGXAA&s=10QVM0z8_GmvllVmpYP3ok2y4lhX
> bM1oAYgbqrZFark&e=

---

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

Hi Dusan,

Thanks again for your comments.  I'll answer in-line below:

> -       What is the behavior for “If the IPoE client is already in the renew or rebind state when Behaviour 2 is triggered”? Should it be the same as Behavior 3?

This is less of a concern than Behaviour 3, as Behaviour 2 does not
send a release.  However I can include wording to allow any ongoing
renew and rebind attempts to complete.  Would that sufficiently cover
it do you think?

> -       SHOULD the client use RAPID COMMIT option for Behaviors 2 and 3?

We could add a "MAY use Rapid Commit", I'm just not sure if it's
required, as it's already covered in RFC3315, Section 22.14.
Perhaps adding a lowercase "may use rapid commit to expedite the
recovery process" guidance as opposed to a requirement.  What do you
think?

> -       Provide a diagram showing how a router outage between a Relay Agent and ISP can be detected (i.e. RA from the edge router) and how the client can recover connectivity to off-link destinatio…

I'll have a think about how best to depict these scenarios and get
back to you with some suggestions.

-Richard

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 19 Jun 2018 20:10:17 +0000

Hi Richard,

Please see inline.

Regards,
Dusan.

> From: Richard Patterson [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2018 4:02 PM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: [email-masked] list <[email-masked]>
> Subject: Re: [v6ops] New Version Notification for draft-patterson-intarea-
> ipoe-health-02.txt
> 
> Hi Dusan,
> 
> > -       What is the behavior for “If the IPoE client is already in the renew or
> rebind state when Behaviour 2 is triggered”? Should it be the same as
> Behavior 3?
> 
[[Dusan]] 
[[Dusan]] Yes. Behavior 2 can be initiated any time, including during RENEW or REBIND process. DHCP client behavior should be defined for that use case.

> recovery process" guidance as opposed to a requirement.  What do you
[[Dusan]] 
[[Dusan]] Lowercase 'may' will suffice.

> 
> > -       Missing a diagram for the problem statement: Can you show please,
> using a simple diagram, how DHCPv6 lease  becomes stale?
> > -       Provide diagrams for all options, showing how a client recovers after an
> edge router outage. For example, if 3.3 ND NUD finds the edge router is
> unreachable, show the benefits of RENEW and SOLICIT options and how the
> client will communicate to off-link destinations using the old or a new
> DHCPv6 address.
> > -       Provide a diagram showing how a router outage between a Relay
> Agent and ISP can be detected (i.e. RA from the edge router) and how the
> client can recover connectivity to off-link destinations.
>