Re: [Int-area] [dhcwg] [v6ops] Intro to draft-patterson-intarea-ipoe-health-00

Ole Troan <otroan@employees.org> Thu, 04 October 2018 10:33 UTC

Return-Path: <otroan@employees.org>
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 46431130E10; Thu, 4 Oct 2018 03:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 V5duS9zWelV2; Thu, 4 Oct 2018 03:33:45 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7977130DFB; Thu, 4 Oct 2018 03:33:45 -0700 (PDT)
Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id B121DFECBC5C; Thu, 4 Oct 2018 10:33:44 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 6F4756E71B2; Thu, 4 Oct 2018 12:33:42 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAHL_VyAXuDnESoKcowBug-VTkw0_qpK-5qjnQ6ATz-cko2UgrA@mail.gmail.com>
Date: Thu, 04 Oct 2018 12:33:42 +0200
Cc: Barbara H Stark <bs7652@att.com>, dhcwg@ietf.org, "v6ops@ietf.org list" <v6ops@ietf.org>, int-area@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <56B2584A-CD70-4EA9-A7B1-06447B0F1667@employees.org>
References: <CAHL_VyDqrn4jmkWxqXJEgaBaJqy-RdqNvjPH=SWc5brpcScE4Q@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DED59D4@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyAXuDnESoKcowBug-VTkw0_qpK-5qjnQ6ATz-cko2UgrA@mail.gmail.com>
To: Richard Patterson <richard@helix.net.nz>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/PTS4AZ2uOZrCYHXyfFxybbsjZqw>
Subject: Re: [Int-area] [dhcwg] [v6ops] Intro to draft-patterson-intarea-ipoe-health-00
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 04 Oct 2018 10:33:47 -0000

>> I'm not sure DHCP configuration is really needed. It seems like overkill.
> 
> Other reviewers/commenters previously felt that this was a useful
> addition.  This would allow Network Operators to trigger or influence
> the connectivity check on CE routers that they are not in TR.069/etc.
> control of.


Requiring the DHCP option makes a big difference in deployability.
Without it, I can implement this feature today. With it, I have to wait until the DHCP option is standardised. And we would presumably get into a big debate about what CE routers should do in the cases where they don’t get a DHCP option. Should they try this mechanism anyway?

We have not requied explicit configuration in the other cases where we have recommended this mechanism. Ref. RFC5969.

While the echo mechanism requires some special provisioning on the local system (ensure that ingress filtering isn’t blocking packets with yourself as source) I am not aware of anything on the PE that woukd block this. If there is consensus on that, I think it’s perfectly fine to require this mechanism on by default in CE routers.
Although we might add some specifics to deal with a case where DHCP was successful, state in PE was correct, but health check still failed.

Cheers,
Ole