Re: [Int-area] [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion

Richard Patterson <richard@helix.net.nz> Wed, 01 August 2018 10:17 UTC

Return-Path: <richard@helix.net.nz>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB80D127333 for <int-area@ietfa.amsl.com>; Wed, 1 Aug 2018 03:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NPgsDqHBZGi for <int-area@ietfa.amsl.com>; Wed, 1 Aug 2018 03:17:37 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F382E12426A for <int-area@ietf.org>; Wed, 1 Aug 2018 03:17:36 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id 72-v6so8856260itw.3 for <int-area@ietf.org>; Wed, 01 Aug 2018 03:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=EkjBGkEUg+5/EeH6bwiP8GCM+aG3wz5f0MDOkwKheXc=; b=x0tMzVn8xgYT6yDxBVssp1Msta1pw++NJri0yIwO6c/9UxV+x9I3nNPB3v96YT9yqz tXDFs3gCx/Du+9ob47K/++gQxYDrp0e9xi98aQGnITNS4c9Y5/wdWgGJx/+Y8NPZuTzE cUT9tsmqiCE2OZVVXTLsZm9jSg/4WVdvfqAtlPs+z6nkj5BhbUvLcda1sZzkwZgJQzy+ ZWAzBlnGVZcxTnn8P93oZyzwdd1NODYv4VGy6oXlrczeHpZg9H9TYRUypg1H1xD+qEf1 vWJpOONC25wX4NDE37iGpqa1yQq4BgY0MGMe//HLzW4SUVVp73M9nmCd5fcgD1R2J61Z 1Y3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=EkjBGkEUg+5/EeH6bwiP8GCM+aG3wz5f0MDOkwKheXc=; b=MvobC5rfarnMmX5xU0ddVeeqeLlzBRt1wdBfjOQQUI+jRrPzec0hXCZFoGJnu6F5ma K2Kop2Ur7Xm9p8YpdT5eqXL2aYX4kkytezU2mvRaq5/CrtA1znrj6AEaa4Tgm37ymCu9 tWeCQGeVxJ/Q0/qZB3RXXqX+n/3De2jd2jqRwbcac4b7/IsOEW0yYmfGg5S1lBzbgde8 Y5vQqHR0MXOpD7OdGOw0jxd1hQVyvvNIqUxqSvNwtilLr2cEszktrj8z4c/qV534Rjqn Q+iLKx679M7v395ab25deOrM7cvbXvBusFIBtx5SwQyN5J79w4VeoLCpkx9KgSIMS3Es QS2g==
X-Gm-Message-State: AOUpUlHQP29w9Cpos224psqL91p3XHcRz69Gqfwn2+Dp/KyVbEvO5ahD oXAc1vb/PhEN7sk1b4dUwX77cghgTwU=
X-Google-Smtp-Source: AAOMgpetO8FPc3ajNm8mD3FjRmtcNhpU/92XvZ6SomjZa84IZZaLKRbbZZWNXr3AvLnza4Fr54fb8A==
X-Received: by 2002:a24:f6cc:: with SMTP id u195-v6mr2804939ith.47.1533118655680; Wed, 01 Aug 2018 03:17:35 -0700 (PDT)
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id r126-v6sm3162894ita.26.2018.08.01.03.17.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 03:17:35 -0700 (PDT)
Received: by mail-io0-f179.google.com with SMTP id q19-v6so15568093ioh.11; Wed, 01 Aug 2018 03:17:34 -0700 (PDT)
X-Received: by 2002:a5e:9706:: with SMTP id w6-v6mr2630558ioj.257.1533118654807; Wed, 01 Aug 2018 03:17:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAHL_VyBF7Pwo5oFchffhkLMF+8kR1RurNG6QGwYhJT_HjqXf9A@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE61603@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE61603@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Richard Patterson <richard@helix.net.nz>
Date: Wed, 1 Aug 2018 11:17:23 +0100
X-Gmail-Original-Message-ID: <CAHL_VyDJ5T1H7y9_O2LN3LHsgrQ95z_RKuwLDQC5qKcNA7Xobg@mail.gmail.com>
Message-ID: <CAHL_VyDJ5T1H7y9_O2LN3LHsgrQ95z_RKuwLDQC5qKcNA7Xobg@mail.gmail.com>
To: bs7652@att.com, int-area@ietf.org, "v6ops@ietf.org list" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/OmV7esYsNlZmZ1s9Iqdo6tjluiM>
Subject: Re: [Int-area] [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2018 10:17:41 -0000

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