Hi Barbara, Thanks for the comments, my responses in-line, quoting snipped where appropriate:
On Tue, 31 Jul 2018 at 19:50, STARK, BARBARA H <bs7...@att.com> wrote: > The consensus view here is that BFD Echo, when implemented as described in > RFC 5881 and BBF specs, works. I don't have anyone asking for something more > complex than what has already been specified in BBF TR-146 (and TR-124 for > CPE, with management by TR-069 and the TR-181 data model parameters). There > is no requirement here for manual configuration, DHCP configuration, or > alternate DHCP mechanisms (Renew, Reconfigure, Rebind). I believe that this statement is a bit contradictory. TR-146 only specifies Renew as an action, and as you've mentioned below, this is often insufficient for an IPoE client to re-establish its session. Defining alternative actions is the primary motivation for this document. The configuration elements and the use of DHCP option for signalling of, were a tertiary consideration. > Getting vendors (CPE and BNG) to implement BFD Echo as currently specified is > painful. Defining something more complex (BFD Echo plus DHCP options plus > other configuration parameters and various methods of configuring) is > unlikely to be easier to get implemented. Defining something that doesn't > work as well as BFD Echo is undesirable. > > It was the BNG vendors who said they preferred the current BFD Echo solution. > Getting CE router vendors to implement is indeed very difficult. Convincing > vendors to implement is definitely the most difficult aspect of BFD Echo. This lack of full BFD support in the CE is the secondary motivation for creating this document. We considered it necessary to include ARP and ND as alternative methods that are hopefully already exposed to the application layer. (Although I'm not sure if this assumption is typically correct or not?). TR-146 briefly touches on the use of ARP Keep Alives, but only includes a requirement R-92 for it in the downstream direction. TR-146 also briefly touches on the use of Passive IPv6 NUD, and explains why this isn't a reliable detection method. We felt that expanding on the use of ARP Keep Alives to include upstream checking from the CPE, as well as the use of Active Neighbor Discovery probing instead of passive, was required. The idea is that these detection methods should be easily supportable by CEs, but with the trade off that their usage would put additional control-plane load on the BNG. If the consensus is that this additional health check mechanism is indeed superfluous, then focusing on a TR-146 -bis is probably the most appropriate next step. > A comment about CE routers: Although our CE routers do BFD Echo, we have (in > our labs) experimented with implementing a CE router on a Linux kernel and > discovered the kernel would not accept packets with a source address > belonging to itself. [The BFD echo is an IP packet with the destination and > source IPv4 addresses being identical and belonging to the CE router, because > of BCP 38.] This is just a comment for anyone wanting to experiment. Our CE > routers do support BFD Echo. That's an interesting observation, thank you for raising it. If we progress further with the document, I'll be sure to include this as a consideration. > Here is a quote related to DHCP Renew and Reconfigure: "The Renew and > Reconfigure approaches are useless as we found when we looked at that. It > doesn't help with an unplanned migration where the subscriber access is moved > (e.g., card or node failure requiring rehoming a DSLAM to a BNG different > port or node). In those cases you can't send a Renew or Reconfigure since > the IP context for the subscriber is lost." I agree. The current version of this document specifically rules out Reconfigure (and ForceRenew) as not being a viable alternative (Section 2). Likewise, this document also discusses the limitations of the Renew method (Section 5.1) and offers the alternative methods. It was left in there for backwards compatibility with TR-146, and because it may be useful in some networks. (and as Lorenzo noted, it will be further beneficial if BNG vendors can implement authentication based on the Renew messages alone) > To summarize: > I / we don't support Renew / Reconfigure or Rebind as options for what to do > when BFD Echo indicates failure of connectivity. No need for DHCP Option to > configure behavior for when BFD Echo fails. I / we do support BFD Echo. I / > we are neutral on the creation of DHCP options to configure BFD Echo > (TR-069/TR-181 configuration is ok for us). Defining alternative actions is the primary motivation for this draft, which is why a simple -bis style update to TR-146 might be sufficient, if no one sees benefit in the active ARP/ND methods, or the configuration parameters and DHCP option. As mentioned above, whilst Renew is the current default action specified, it's perceived to be the least effective of the methods and not preferred. I'd be happy with the removal of Renew and Rebind behaviours from this document, or as mentioned before, focusing on a single converged action that attempts a Renew before moving swiftly on to the more reliable approach of sending a Solicit/Discover. -Richard _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
