Hi Barbara, Thanks for your review once again. Responses in-line:
On Wed, 3 Oct 2018 at 01:13, STARK, BARBARA H <bs7...@att.com> wrote: > Name: IPoE Health Check sounds more like a marketing name than a name that > gives me some sense of what the capability actually does. I think it might be > easier for people to get a sense of what this does if its name better evoked > its function, like "IPoE Connectivity Check". The "oE" is relevant since the > function does place requirements on which MAC addresses to use. If it weren't > for that, I would have said it could be used for IP over anything. "Health" > is too vague a term. OK, we can work on the name. > Abstract/Introduction: Starting with discussion of PPPoE and BFD Echo is very > confusing. I much prefer documents to start by telling me what they're about. > This document seems to be primarily about defining this IP connectivity check > function. Info about PPPoE and BFD Echo is really just background info. I > would recommend leading with something like "This document defines a > mechanism for CE routers with IP over Ethernet WAN interface to > periodically test IP connectivity between it and the first hop router. This > mechanism is intended to be used by CE routers that do not implement the BFD > Echo mechanism for testing IP connectivity." I don't think PPPoE needs to be > mentioned in the abstract, at all. In the Intro, PPPoE background should > probably be the last paragraph, instead of the first. Totally agree with regards to the abstract. Are you OK with the existing introduction section referencing PPPoE and BFD Echo to provide the background, if we reword the abstract to focus on this document? > > On a related note... > "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 an alternative health check > mechanism." > ... isn't an accurate description of this document. This document defines a > connectivity check mechanism that can be used by CE routers that don't > support BFD Echo. > > CE is "Customer Edge" and not "Customer Equipment". It's not synonymous with > "CPE". "CE Router" is a "Customer Edge Router". It's called this because it's > at the edge of the customer premises network, as opposed to a router in the > interior of the customer premises network or a router in an access network. > "CPE" is properly a word that can be applied to any service-provider-supplied > "Customer Premises Equipment", including set-top boxes, VoIP ATAs, > ISP-supplied CE routers, etc. A CE router is not necessarily supplied by the > ISP. OK, we can standardise on using "CE router". > > IPoE Client: I don't see a need to create yet another term for a CE router > with an IPoE WAN interface. I find the term "client" in this case a little > odd, since there isn't really a client/server relationship in the context of > either IP or Ethernet or IP over Ethernet. Understand from the literal sense, but in context "IPoE" is generally synonymous with DHCP, in which there is a client/server relationship. We can, however, avoid this term if it's deemed confusing. > > "Non-default static parameters SHOULD override any signalled via a > dynamic means (e.g, DHCP or TR-69)." > TR-069, like SNMP and netconf, is not considered a dynamic means of > configuring devices. It's generally considered a means of supplying "static" > configuration. > > The relationship with BFD Echo is very confusing. I would suggest a > relationship along the lines of: If BFD Echo and <name of this mechanism> are > both supported, the CE router MUST attempt to use both mechanisms to test IP > connectivity upon receiving a DHCP-assigned IP address or prefix. If BFD Echo > is successful, the CE router MUST cease using <name of this mechanism> and > continue only with BFD Echo. If <name of this mechanism> succeeds and BFD > Echo does not, the CE router MUST cease using BFD Echo and continue only with > <name of this mechanism>. OK, will try to clarify this. > > I'm not sure DHCP configuration is really needed. It seems like overkill. Other reviewers/commenters previously felt that this was a useful addition. This would allow Network Operators to trigger or influence the connectivity check on CE routers that they are not in TR.069/etc. control of. > > Recovery behavior for BFD Echo (per TR-124i5) is "Unless overridden by > configuration, by default after a failure of 3 successive BFD echo intervals, > the RG MUST issue a DHCP renew message following a random jitter interval > between 1 and 30 seconds." I think it would be good if we had consistent > behavior, independent of mechanism. Or is there a good reason to have > different behaviors for different connectivity checks? Our current defaults were simply chosen based on an existing implementation of similar functionality. I agree, consistent defaults would be good, I'll review the default values in TR124i5 and adjust accordingly. > > The version of TR-124 referenced in the references section doesn't actually > include BFD echo requirements. The most recent version is TR-124i5, which is > available at > https://www.broadband-forum.org/technical/download/TR-124_Issue-5.pdf. Will update the reference. > > "If all DHCPv6 leases have expired, either naturally or proactively > with IPoE health checks, an IPoE client acting as a router, SHOULD > withdraw itself as a default router on the LAN, following requirement > G-5 of [RFC7084], Section 4.1." > Since the referenced RFC7084 requirement is a "MUST", I would make it a MUST > here, too. Good catch, will update. Thanks again for taking time to review the document. -Richard > > > > -----Original Message----- > > From: v6ops <v6ops-boun...@ietf.org> On Behalf Of Richard Patterson > > Sent: Tuesday, June 05, 2018 4:03 PM > > To: int-area@ietf.org; v6...@ietf.org list <v6...@ietf.org>; dh...@ietf.org > > Subject: [v6ops] Intro to draft-patterson-intarea-ipoe-health-00 > > > > 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://urldefense.proofpoint.com/v2/url?u=https- > > 3A__datatracker.ietf.org_doc_draft-2Dpatterson-2Dintarea-2Dipoe- > > 2Dhealth_&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC- > > 8sc8SY8Tq4vrfog&m=FsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > > VTwchGJI&s=PlUBOvZt82phRMfoJpQQ--BeqgUeIP_QKKl6uSOdXA4&e= > > > > 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 > > > > _______________________________________________ > > v6ops mailing list > > v6...@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=LoGzhC- > > 8sc8SY8Tq4vrfog&m=FsoSwjTvxj08keS6f_DYpmlby-FM9C5m-G- > > VTwchGJI&s=PQDjf2K7lKp7HxtDXAqe1ce3u8xCq8vLbnHcTQjgRlw&e= _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
