Re: [Int-area] [v6ops] Intro to draft-patterson-intarea-ipoe-health-00
Hi Barbara, Thanks for your review once again. Responses in-line: On Wed, 3 Oct 2018 at 01:13, STARK, BARBARA H 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 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 and > continue only with BFD Echo. If succeeds and BFD > Echo does not, the CE router MUST cease using BFD Echo and continue only with > . 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
Re: [Int-area] [v6ops] Intro to draft-patterson-intarea-ipoe-health-00
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 toperiodically 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 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 and continue only with BFD Echo. If succeeds and BFD Echo does not, the CE router MUST cease using BFD Echo and continue only with . 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 On Behalf Of Richard Patterson > Sent: Tuesday, June 05, 2018 4:03 PM > To: int-area@ietf.org; v6...@ietf.org list ; 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- >
