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

From: Richard Patterson <[email-masked]>
Date: Mon, 2 Jul 2018 20:02:35 +0100

Hi Dusan,

I haven't had a chance to mock up these diagrams that you've requested.

Is the current narrative unclear enough that we need all these
diagrams? Is there any alternative wording that might help?
Are you thinking topology, or rather state/swimlane style diagrams?

-Richard
On Tue, 19 Jun 2018 at 17:40, Mudric, Dusan (Dusan) <[email-masked]> wrote:
>
> 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
> >
> > 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://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:
> >        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
> >
> > _______________________________________________
> > 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: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 16 Jul 2018 20:36:51 +0000

Hi Richard,

I suggest using simple topology diagrams. Most new drafts that talk about a network component outage and its impact on address selection/assignment use simple diagrams. They should be enough to depict the problems when a reachability is lost and to demonstrate the solutions.

Thanks,
Dusan.

> From: Richard Patterson [mailto:[email-masked]]
> Sent: Monday, July 02, 2018 3:03 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?
> > -       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.
> >