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

Job Snijders <job@ntt.net> Mon, 03 July 2017 21:10 UTC

Return-Path: <job@ntt.net>
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 8C3A312F3D5 for <idr@ietfa.amsl.com>; Mon, 3 Jul 2017 14:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 b2chU3vMH90Z for <idr@ietfa.amsl.com>; Mon, 3 Jul 2017 14:10:29 -0700 (PDT)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D84130889 for <idr@ietf.org>; Mon, 3 Jul 2017 14:10:24 -0700 (PDT)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <job@ntt.net>) id 1dS8bv-0002Il-MU (job@us.ntt.net) for idr@ietf.org; Mon, 03 Jul 2017 21:10:23 +0000
Received: by mail-wr0-f176.google.com with SMTP id k67so239293398wrc.2 for <idr@ietf.org>; Mon, 03 Jul 2017 14:10:23 -0700 (PDT)
X-Gm-Message-State: AKS2vOy8OQSqgYSREQzMRzptZ7yHQmzFWaYZRHN0ZEn/JEYmLVHTpllr bOSAG39GapA8xzgwUwTWaf3ct09aHZIy
X-Received: by 10.223.177.129 with SMTP id q1mr34191432wra.82.1499116222378; Mon, 03 Jul 2017 14:10:22 -0700 (PDT)
MIME-Version: 1.0
References: <149909741417.22786.4679459342587499122@ietfa.amsl.com> <20170703160800.x6wcym2ma6jceqv7@Vurt.local> <FBD5248C-33C6-436C-8B01-FAE2658B0768@juniper.net> <20170703163846.224w6lxvbt4txqub@Vurt.local> <20170703173810.GA45648@Space.Net> <20170703175308.hembxkplaniz66wb@Vurt.local> <m2van9z3jp.wl-randy@psg.com> <CACWOCC8tPVD20SJ60h-=NGbPMG3Fae2a0TY5rMFb=EnN7H-C6Q@mail.gmail.com> <m2o9t1z1hj.wl-randy@psg.com>
In-Reply-To: <m2o9t1z1hj.wl-randy@psg.com>
From: Job Snijders <job@ntt.net>
Date: Mon, 03 Jul 2017 21:10:11 +0000
X-Gmail-Original-Message-ID: <CACWOCC_bQitHeR9tHc5tPsXmoSDDLQH764equTAHrP854fYh-A@mail.gmail.com>
Message-ID: <CACWOCC_bQitHeR9tHc5tPsXmoSDDLQH764equTAHrP854fYh-A@mail.gmail.com>
To: Job Snijders <job@ntt.net>, Randy Bush <randy@psg.com>
Cc: Gert Doering <gert@space.net>, idr@ietf.org
Content-Type: multipart/alternative; boundary="f403045e7c7ae997a50553703163"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lPEZFRoNiSRqbPcsapEQhKGruFo>
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: Mon, 03 Jul 2017 21:10:30 -0000

On Mon, 3 Jul 2017 at 22:53, Randy Bush <randy@psg.com> wrote:

> > I don't follow. If the route server facilitates you in setting up BFD to
> > all "nexthops of interest", the route server's job is done, right? Any RS
> > peer has the ability to locally verify reacahbility across the fabric and
> > route accordingly.
>
> route servers are for the small folk who can not do full mesh, let alone
> add path and other fancy things.  the rs IS their control plane, period.
>

If a device can't do add-path, can we really expect these devices to do
fancy things like opportunistic "route server assisted" BFD to all
next-hops of interest?

If we operate under the assumption that these clients can't support
receiving multiple paths through add-path, I envision a somewhat ugly
cadence:

1) Hey RS, can't reach A
2) Ok, here try reaching A via B
3) hey RS, I can't reach B either
Etc, etc

The above scenario might look small, but often problems at IXPs don't
affect (isolate) a single participant, but rather clusters of participants.
A challenging aspect of IXPs are the "ISLs" between sites.

If the RS is to receive and keep track of the state of who can reach who,
it should somehow create a clear benefit that visibly reduces the load on
the participant's devices. If the only benefit is "if the RS keeps track of
this state, the participant doesn't need to support ADD-PATH (but only
draft-ietf-idr-rs-bfd)", I'm skeptical whether I can get behind that
reasoning.

Kind regards,

Job