Re: [v6ops] SLAAC host moving between networks

Mark Smith <markzzzsmith@gmail.com> Sat, 10 November 2018 00:20 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D20D12D7EA for <v6ops@ietfa.amsl.com>; Fri, 9 Nov 2018 16:20:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 l9Q4YJ54ZX5S for <v6ops@ietfa.amsl.com>; Fri, 9 Nov 2018 16:20:48 -0800 (PST)
Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 8FA5E1277CC for <v6ops@ietf.org>; Fri, 9 Nov 2018 16:20:48 -0800 (PST)
Received: by mail-oi1-x229.google.com with SMTP id g188-v6so2966344oif.8 for <v6ops@ietf.org>; Fri, 09 Nov 2018 16:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o1F6eYQD2SFdE6o5xXH2IVa8JwuO97+hBDWar3AXTeg=; b=gVSNfyfDwfGxMIrSz+n59MtQyHuldmBlMWRXUA/12wm0g6UpCl7nJ5eOT0LIcdubXD BLcWFcM3tNkFgMniJrG4/Gh5HVNw8oABuigrUepjhBBk4Ho1+nAkoUQTYdObP3aY8iBO DfK155sROUxYbcKuY9YHfL9wQIotuJzj8tegzoiv9yFZcon/ADO2JFjYjFVO4MePd/UW uBw2NrGYCtV/aS6iZc+wR2/UeVAql1tKlf7BNhaClu3Zt9JbKyKAozUb9yJSSjV6av1B lGZnkfUY3wELfUm1wiIUWhLociF6zpzTX1g4Qaakl+2YBC07wu1ua5jz4UIa7KmAuQaB CFfQ==
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:cc; bh=o1F6eYQD2SFdE6o5xXH2IVa8JwuO97+hBDWar3AXTeg=; b=ZXGxrovR05exStYn0f4XUO4G9KwPK1CdX705NspxhkCz1lzhfFPtjfUoAowUdWjZSK 86ILl7BGNLh1mEuncDYqx70izUJYNIrpByryGt/eVeJkKD472OSvP0TWW6QmdfD0ULgp 8VNGN2U+0ex/OnM0GUiMAJouAF7DxfNDXCCCJwy7w8X+YYr3VjAOgAfXfPBAl1MXni72 obK5VkUj9I5G28ri22e1TuP/57V0yCwmIBeFWxgMMjvl8J1YgfUtSvbRKAGiimIsKV3i FGZSCdrV7hwqKBGLWFfHyIqsygaNYihxnu+V0krR6xqsX1hWdCPa/g4OrTMNdzbYO3O0 88nw==
X-Gm-Message-State: AGRZ1gJgqTW2tj2CRsjjh6CVWYa6kvjkeJRXVetjmx094b8KwfYZRzPI GxMJ7Y2UVQo2YtDAUhr6NRQKQgVroZGq8Le3T0o=
X-Google-Smtp-Source: AJdET5cz2mzZkpXn3lsolgNkkD2q4odrJedN74SNhh7Fc9gh2mZ1ap8CVp9tZ7AILROAKl360Hsd5VuvqbqmnL0RObA=
X-Received: by 2002:aca:e484:: with SMTP id b126-v6mr6402795oih.60.1541809247507; Fri, 09 Nov 2018 16:20:47 -0800 (PST)
MIME-Version: 1.0
References: <20181106113438.ud37g6ht6vaxtbif@imap.narrans.de> <A9C4EA19-B89A-4B14-86E1-233AB50B1B4A@consulintel.es> <m1gK0hy-0000FkC@stereo.hq.phicoh.net> <81785dd3-9013-e802-934a-3d6c1b8f87bf@foobar.org> <3899E3F6-BD5D-47CA-8040-CD67E0229216@consulintel.es> <9883628c-1132-0026-2818-911654f23af2@asgard.org> <CAO42Z2zUAr2TijebYNqXjz4qs3goN1FcUseaKMR7SXCOJwqVkQ@mail.gmail.com> <c03c4c8e-c50b-89f3-bc53-d3cf4e3ce5fe@asgard.org> <CAO42Z2wh=YRePKqR7p9BKSy0aSd4a3Xc6kpZYujS4OtNKEk4sg@mail.gmail.com> <CAHL_VyAuonunetU947O8yzrFCj3E63PenE8ft7CzX0qGYhVLkg@mail.gmail.com>
In-Reply-To: <CAHL_VyAuonunetU947O8yzrFCj3E63PenE8ft7CzX0qGYhVLkg@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 10 Nov 2018 11:20:20 +1100
Message-ID: <CAO42Z2yvJ7ZGP=F26cV-jW=ENdTpB18MaspY8BniQv75qCGB6w@mail.gmail.com>
To: richard@helix.net.nz
Cc: Lee Howard <lee@asgard.org>, v6ops list <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8t9hPJzijm8Oir5F0fK4_-pH5Ds>
Subject: Re: [v6ops] SLAAC host moving between networks
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2018 00:20:51 -0000

On Fri, 9 Nov 2018 at 20:31, Richard Patterson <richard@helix.net.nz> wrote:
>
> On Fri, 9 Nov 2018 at 02:42, Mark Smith <markzzzsmith@gmail.com> wrote:
> > BRASes and CPEs both send keepalives to detect this event if it is
> > disruptive to packet flow.
>
> When using PPP[oE], sure, but what about IPoE?

So I don't have first hand experience with IPoE, however I have to
assume that since it has been used for HFC networks universally for in
the order of 15+ years, and a broadband ADSL network I know of for the
past 10 or more years, that is fundamentally a solved problem.
Otherwise it would be well known that there are hanging
sessions/RADIUS accounting problems with HFC/IPoE networks, and I
expect it would have fallen out of favour as an access method by now.
There's been plenty of time for that to happen.

The bit of research I've done in the past (about 10 years ago now),
and verified now is that they're using things like ARP ping and ICMP
echo request/response in addition to DHCP to create and maintain
session state.

For example, the copyright date on this presentation is 2007, and that
describes how IPoE new sessions are established and how session
failure is detected via a number of methods (DHCP lease expiry, ARP
ping failure, ICMP ping failure).

http://www.swinog.ch/wp-content/uploads/2018/07/The_Evolution_from_PPPoE_to_IPoE_sessions.pdf

And here is a description of how another vendor is doing it (the same way)

https://www.juniper.net/documentation/en_US/junos/topics/concept/subscriber-management-dhcp-liveness-detection.html

> A problem we're trying to solve with draft-patterson-intarea-ipoe-health
>

I think the only and a major criticism of the above methods is that
they're using BRAS control plane resources for this liveness testing,
and that can become considerable with 1000s of subscriber sessions on
a BRAS.

Having CPEs use forwarding plane verification i.e. sending traffic
that is looped through the forwarding plane of the BRAS, back to the
CPE, rather than CPEs using keepalives methods that are processed by
the control plane of the BRAS (including PPP LCP Echo Request/Reply in
a PPPoE scenario), would help remove a useful amount of load from BRAS
control planes.

Regards,
Mark.


> -Richard