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

Richard Patterson <richard@helix.net.nz> Tue, 31 July 2018 15:36 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 180A5130EDF for <int-area@ietfa.amsl.com>; Tue, 31 Jul 2018 08:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tkzyxmZoz9XV for <int-area@ietfa.amsl.com>; Tue, 31 Jul 2018 08:36:37 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 00F3A130EF4 for <int-area@ietf.org>; Tue, 31 Jul 2018 08:36:35 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id w11-v6so13411146iob.2 for <int-area@ietf.org>; Tue, 31 Jul 2018 08:36:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=CTcqnnosxfWbH+CPVC3fC4YFqKDVdVuXBr6bV+eFkWI=; b=u2PFvEF7JU9k26HALSLC15okU/d5dO7qlNGGgBRwUY1qdAhsVNNZcZAA1L7xTqQ2tf 6pI4fynLG5vqYO9gygIxJyq23OebJCILncal98J5AZ3MhhI6WwQTCpIbrZa242M0K1FC uT4vYoyPGfPipaN5ssZNUhIfFpkh/v8hn2/P8Bam8iHGlgBVFynGmxBBSyMbFPsWV/7E MyIEipGOKMeX/SeKP3kIVY+VLtGX8Po7uhXsY8X/C8cogtdzXAdm5MFfCK34//Ms9rDc 3S/laYjA32QaDkA0+hTECqUEOhHz1+UD/JBopv/NlKhLaQnrwDy4L+sdOmBDLN96YIfc COPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CTcqnnosxfWbH+CPVC3fC4YFqKDVdVuXBr6bV+eFkWI=; b=sFlmQassx3FJ6sQEW3pyU/DFCr3yfeVs8SHaU18nxohJ62ioT20C+msbD7lwU6sUuu EzjLFmLwQ2QJwQOifC/GWZETQuKGeP1dDqLyd8pDJRekZNC9DvLmA2CEpbpMO+mdfJKQ lcO7MNhSkCGFMlIgrkJGAafCo/FAkYOH2mmRRlvfyU9Y0iik2kUPDYRauXZHxzEXvHlW rxqzZwOdJ7niWRNF7Kr4RzAxrdsnYrwGWjDJisB7QqW2g939BIG52YidUHeLCEp3Pf/9 lqnXXwDM4GlipDOW/FL6BPcMmf8nkFZtSMjda4afAMmyrqSRxsKe6fFIA/bzC1YGFlSz JAmg==
X-Gm-Message-State: AOUpUlGJnEXaUmTEB5046vqulhHOTrTT1hjCCBehZtfIEgOWPDVemcgL zvasP+6BsYerAsZ+MCarH502iOWVb10=
X-Google-Smtp-Source: AAOMgpf+GqglPsqwoQPezSzrED6UoMu/XAnbuY/CDvxAr4vHeWoWkSp2+WVsGgy6OhqUfHlefUYl4Q==
X-Received: by 2002:a6b:6e19:: with SMTP id d25-v6mr198279ioh.55.1533051395142; Tue, 31 Jul 2018 08:36:35 -0700 (PDT)
Received: from mail-it0-f43.google.com (mail-it0-f43.google.com. []) by smtp.gmail.com with ESMTPSA id u139-v6sm946461ita.1.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 08:36:34 -0700 (PDT)
Received: by mail-it0-f43.google.com with SMTP id h23-v6so4948139ita.5; Tue, 31 Jul 2018 08:36:34 -0700 (PDT)
X-Received: by 2002:a02:9f98:: with SMTP id a24-v6mr20920036jam.136.1533051394407; Tue, 31 Jul 2018 08:36:34 -0700 (PDT)
MIME-Version: 1.0
From: Richard Patterson <richard@helix.net.nz>
Date: Tue, 31 Jul 2018 16:36:23 +0100
X-Gmail-Original-Message-ID: <CAHL_VyBF7Pwo5oFchffhkLMF+8kR1RurNG6QGwYhJT_HjqXf9A@mail.gmail.com>
Message-ID: <CAHL_VyBF7Pwo5oFchffhkLMF+8kR1RurNG6QGwYhJT_HjqXf9A@mail.gmail.com>
To: int-area@ietf.org, "v6ops@ietf.org list" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/s4rFlcx-gaejn-VZsYeobuqh1Z0>
Subject: [Int-area] 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: Tue, 31 Jul 2018 15:36:39 -0000

Following on from the Q&As and hallway chats at IETF102, I've captured
a few questions for further discussion on the lists.
For those yet to review the draft, it can be found here:

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

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

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

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

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