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 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
