STARK, BARBARA H
2018-10-03 00:13:28 UTC
I've gone through the document, but not in extreme detail. Here are some comments based on my quick reading.
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.
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.
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.
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.
"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>.
I'm not sure DHCP configuration is really needed. It seems like overkill.
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?
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.
"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.
Barbara
> -----Original Message-----
> From: v6ops <v6ops-***@ietf.org> On Behalf Of Richard Patterson
> Sent: Tuesday, June 05, 2018 4:03 PM
> To: int-***@ietf.org; ***@ietf.org list <***@ietf.org>; ***@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
> ***@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=
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.
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.
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.
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.
"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>.
I'm not sure DHCP configuration is really needed. It seems like overkill.
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?
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.
"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.
Barbara
> -----Original Message-----
> From: v6ops <v6ops-***@ietf.org> On Behalf Of Richard Patterson
> Sent: Tuesday, June 05, 2018 4:03 PM
> To: int-***@ietf.org; ***@ietf.org list <***@ietf.org>; ***@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
> ***@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=