I went to my internal experts and had a chat with them about this draft. Here
is some feedback on the draft.
Everyone I talked to agrees that keeping the IPoE "connection" up on access
loops is important. [This relates to my saying at the v6ops session that
Richard was right about this being a problem that he needs to solve in his
network.]
However...
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).
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.
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.
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."
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).
More comments in-line, below.
Barbara
> -----Original Message-----
> From: Richard Patterson
>
> Following on from the Q&As and hallway chats at IETF102, I've captured a few
> questions for further discussion on the lists.
>
> - BFD Echo: Still requires a full BFD implementation. Do we continue to
> specify BFD Echo specifically, as per TR-146, or do we rather specify a new
> "loopback" packet format to perform the same function, without full BFD.
BFD Echo works, and has been successfully implemented by many vendors. I / we
see no need to define a new mechanism.
> - Complexity: Do we need to define all 4 Behaviours? Would it help with
> adoption if we remove the Renew and Rebind behaviours, and focus on the
> latter 2 behaviours that are more likely to facilitate session
> re-establishment? (Perhaps combine behaviours 0,1,2 in to a
> converged method? i.e., attempt a single renew, and rebind before moving
> to solicit/discover)
No, this complexity is not needed. Renew/Reconfigure is not useful. Rebind is
also not needed. CE router does not need to be triggered -- failure of BFD Echo
is sufficient trigger getting DHCPv4 and RS/RA/DHCPv6 processes started.
> - Complexity2: Do we need to define 3 different health check methods?
> BFD Echo-style, ARP/ND, and Passive. I think that BFD Echo-style
> and active ARP/ND checks are both worthwhile specify, but dropping passive
> checks for simplicity is probably a good idea.
No, we don't need complexity. Only one mechanism is needed. BFD Echo works.
> - Engage Vendors: Current behaviour of silently discarding of Renew
> messages is seen as a violation of RFC2131. I agree that vendors could
> implement authentication on Renews, with additional complexity of
> validating current and pass lease-state. It doesn't entirely mitigate the
> problem, but would expedite client recovery somewhat.
I / we don't support additional IPv4 DHCPv4 mandates on CE routers.
> - Engage Broadband Forum: Discuss the problem and current limitations with
> their recommendations in TR-146, perhaps help drive a Broadband Forum
> equivalent of a -bis.
The best way to engage BBF is direct communication. IETF WGs and liaisons have
very little influence in getting BBF to do work. Individuals (especially
individuals willing to step up and be an editor or find someone to be an
editor) are significantly more influential. If you want to try to get something
done, I suggest you directly talk to Dave Allen and David Sinicrope (both of
Ericsson, where Dave Allen chairs the BBF group who does BNG requirements and
David Sinicrope is the BBF-IETF liaison officer). I am engaged in BBF CE router
("residential gateway", TR-124) specs, but am not willing to be a champion for
this. What you really need to be successful with BBF is more ISPs (at BBF) to
support you and/or your CE router and BNG vendors. I don't recommend trying to
get v6ops or int-area to try to drive BBF for you.
> I think engaging BBF is a good thing to happen anyway, but there are
> additional features of this draft, such as configurability and signalling of
> parameters via the DHCP option, and alternative behaviours.
> Do people think that these additional features warrant progressing this draft
> or something similar within the IETF, or should focus be shifted to working
> with the BBF on simply amending their TR-146?
I think the understanding of this problem at IETF is in short supply. The BNG
and non-DOCSIS ISP CE router vendor experts and non-DOCSIS ISP access network
experts are at BBF. I don't support progressing this draft in IETF.
As a final note -- for any solution to be meaningful (wherever the work is
done), the vendor representatives who can commit to implementing must be
engaged.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
