Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt

Robert Raszuk <robert@raszuk.net> Wed, 05 July 2017 15:05 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8800B132A49 for <idr@ietfa.amsl.com>; Wed, 5 Jul 2017 08:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 J4w0nPmJvmar for <idr@ietfa.amsl.com>; Wed, 5 Jul 2017 08:05:08 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 06854131D51 for <idr@ietf.org>; Wed, 5 Jul 2017 08:05:08 -0700 (PDT)
Received: by mail-io0-x236.google.com with SMTP id z62so87324767ioi.3 for <idr@ietf.org>; Wed, 05 Jul 2017 08:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AFIHDDbw9bUiWL64H6Db20jxLjJYWjB4hjN3pkd2FVI=; b=o5KIl8AyOKg+cMx/2DYc/wh3VDRiHJF1HQZbZXzv6n4p4kjf3QZcLsQFtAQSNA71c6 TmGwy7F+sZi/V69SigpwbsvSMCklXjjHrY1WJwUEO7sDg9xubuQFdnbP1bVAq6UOr1Cg l3iugqWfLGfytCObvhbsvn7C9IOKpZ1kqsHlPIIPQO3sTs1ZLEKnmsegIhxplLMWe+Vx 9mgRjm1+UWW5WZP49QUn/WOO6h+rzyc4yyhcZQuUwg9o8+lLIxCnkQG9gEdxxRBPU56W zljUsKhAMA6mU7e+rgHdcD5sAw9w0GQZILlrnVAQwKjdS9cHkFiCnDMQJ3OOj3V35MIy eKuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AFIHDDbw9bUiWL64H6Db20jxLjJYWjB4hjN3pkd2FVI=; b=XOsHpnZgZKg95Nj2/hmwIxsb+WCJ1QsU3jdpK+iD+nKAHO3jkG8ZTzAD1gcpaZGDXI 8jFucEoli0gbFOm3/l4eRX0RgKbUqObrD+TYcegIeHdk6pSTidWTj0KFPATrbsN+IHmJ vsbu0zjN30NKCBiTms4Qo2wd5olntnTbnyg7fuioy+gttwByig8G5ced8kXC1G84XP1B 8R861RcdbXs2D4loVI8NOe5hhQeSV0yG/7tMpMvZsbgzF1kMa64HUu30RWaTOTpjLvoR inUvDkCEECetrEQYuqbW5Yqe0exWj1bRxLnjNP5ZmvOS2QcEaDQqBYU2Uk0tf1d3QpO2 fyQA==
X-Gm-Message-State: AKS2vOxlmotTON5O2hQ6MozfchZjYFL5m7fJcI7pfJ3IldxRsmtq3LJK DIkFAnSLm/X+nD53nAlObJvKlzBD7rNy
X-Received: by 10.107.128.30 with SMTP id b30mr31675979iod.179.1499267107198; Wed, 05 Jul 2017 08:05:07 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:05:05 -0700 (PDT)
Received: by 10.79.32.15 with HTTP; Wed, 5 Jul 2017 08:05:05 -0700 (PDT)
In-Reply-To: <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net>
References: <20170703175308.hembxkplaniz66wb@Vurt.local> <m2van9z3jp.wl-randy@psg.com> <CACWOCC8tPVD20SJ60h-=NGbPMG3Fae2a0TY5rMFb=EnN7H-C6Q@mail.gmail.com> <m2o9t1z1hj.wl-randy@psg.com> <CACWOCC_bQitHeR9tHc5tPsXmoSDDLQH764equTAHrP854fYh-A@mail.gmail.com> <BF65C4DC-D2F5-41AF-8454-D43B403E328B@juniper.net> <CACWOCC9cmz7ARnWNowCCEu3Rt_NiyuWgJMZ3pWfmxZ_BO8Ovjw@mail.gmail.com> <292534ED-98BC-49A0-82A2-45B6688F851D@juniper.net> <CACWOCC_KTzJLQAJf_j4ZqM1oJSFq9JcyT7aAPLGf3+2Ess7BBA@mail.gmail.com> <09BFF794-6899-4DA5-8EF5-DDF86513BFBA@pfrc.org> <20170704104840.mg5bflnmmjlv4jbi@Vurt.local> <20C02BA3-5C13-46FB-AFE8-85D61E469EA1@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 05 Jul 2017 17:05:05 +0200
X-Google-Sender-Auth: EA3sVkRDF2N_pjToeXqE6UWZQLI
Message-ID: <CA+b+ERmJRbhwa5Eut4+KwxqmAcaBM3fSvL1-zjrxBfZur6QxjA@mail.gmail.com>
To: "John G. Scudder" <jgs@juniper.net>
Cc: idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f8b12591f7d055393539f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4eGOLUEhNrIRDxj_jYSHBQRefW0>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 15:05:10 -0000

Hi John,

You are describing the situation where client notices next hop down,
notifies RS but does not get new path till other clients also report the
same next hop as down.

Is this really a good idea ?

Note that due to selective policy only very few clients may get given path
so your heuristic would now also need to account for static or dynamic
(signalled with communities) policies.

Well I have nothing against machine learning or AI, but do we really need
it here on RSes ?

Thx
R.

On Jul 4, 2017 17:55, "John G. Scudder" <jgs@juniper.net> wrote:

> One observation regarding the "RR won't scale if it has to do per-client
> route selection" concern -- it seems to me it would be entirely feasible
> for an implementation to associate some figure-of-merit with each next hop,
> a function of its reported reachability by each of its indirect peers. That
> figure-of-merit could be used during traditional (not per-client) route
> selection. The general idea would be "if one other client can't reach you,
> that's their problem, if dozens of other clients can't reach you, maybe we
> should choose a different next hop if we've got one" [*]. Think of it as
> making the binary resolvability condition of RFC 4271 9.1.2.1 fuzzy.
>
> I think specifying the function would be beyond the scope of this (or
> really, any) draft since it's "just policy". But it demonstrates there's
> some potential benefit from the proposal without going all the way down to
> per-client route selection.
>
> --John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>