Med, I've just pushed -04 out before the cutoff deadline this evening. Hopefully I've correctly integrated your comments.
A new version of I-D, draft-patterson-intarea-ipoe-health-04.txt has been successfully submitted by Richard Patterson and posted to the IETF repository. Name: draft-patterson-intarea-ipoe-health Revision: 04 Title: IP over Ethernet (IPoE) Session Health Checking Document date: 2018-07-02 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-patterson-intarea-ipoe-health-04.txt Status: https://datatracker.ietf.org/doc/draft-patterson-intarea-ipoe-health/ Htmlized: https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-patterson-intarea-ipoe-health Diff: https://www.ietf.org/rfcdiff?url2=draft-patterson-intarea-ipoe-health-04 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 is not specified in the IETF 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 mechanism 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. On Mon, 2 Jul 2018 at 19:21, Richard Patterson <rich...@helix.net.nz> wrote: > > Hi Med, > > Thanks once again for your review, comments, and support. > I'll address your bullet points in-line below. I'll try to get a -04 > out incorporating your feedback before the cut off. > > > On Mon, 2 Jul 2018 at 09:29, <mohamed.boucad...@orange.com> wrote: > > The main comments: > > * Use 3 as default retry interval value (consistent with BBF TR-124 and > > some existing implementations). > > Have reworded the parameter definition to: > - Limit (Integer): The number of failed consecutive checks before an > action is taken. Default value: 3. > > > * Generalize the procedure to cover any dynamic configuration means (DHCP, > > as an example among others). > > I agree for the most part, but I'm unsure about considering TR-69 as > dynamically signalled. I was treating TR-69 as a method for local > configuration (which we've now changed to static in -03). > I think the idea is the same though, so I'll work your suggested wording in. > > > * Add a guard to prevent loopback and multicast addresses as alternate > > target @ > > Is saying that the field must be a unicast address sufficient, or do > you want to specifically call out loopbacks and multicast? > > > * Double check some part of the text to reflect that both interval and > > retry-interval are now used. > > > > I do support this effort to be adopted in dhcwg or int-area. > > > > Cheers, > > Med _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
