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

Robert Raszuk <robert@raszuk.net> Thu, 16 March 2017 09:29 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 D786E126C23 for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 02:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Hkd42zI_GP4d for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 02:29:31 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 238FD126DD9 for <idr@ietf.org>; Thu, 16 Mar 2017 02:29:31 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id r45so32569377qte.3 for <idr@ietf.org>; Thu, 16 Mar 2017 02:29:31 -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=u/f7kjDBvOBQieUJKaqO5MTQvbLVvBvCGEe35CzrjFE=; b=QkRtEkzhCixYuORhxssQiAEysyAZTEHz3lkgfeKDzdJiQ1tmtjlSSsf5dS+JgVQNpi LTLoeofOQbX9ul5ibmsTbgoQtGrA7HE/GKWsVG+e33uJ5OaRANQqelTt0S/XGuMKvSlL 0FNQ/skUe6uArPdRUgRqxHy7v6bkgQpGzrsJYRC4NpoC3Cp8fISSrY3T/V95Ul87bsMC KSlilHgF09q5jtm/f3GRQscZjnDKZZWAdjxpsSQdFfyUKq3eIV4qvHEfV+JKdQ+81aUX Mgb0ZTrKARrSDNL/zp9R8N8JXd9CQ/mg/Tqg3+RCn97iTOkgTL9WxU8bWO+72pP4IOqB 6PaA==
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=u/f7kjDBvOBQieUJKaqO5MTQvbLVvBvCGEe35CzrjFE=; b=h9YYz3NeCjzSrqfKHL07O0gGH2UCcZj/T5kdxvOc4XX73atFKBwOalF//KqzpdT9IF S96GsD+Ezh87kklkjhHkvpMSA/dMBAAXu/dDCt0f6Snd8LHm/DTw8P9LzxPMu49eIbra gSUOTrU6UxEdTB0TfvswM+eV3iBrcZEgPVlCQ/eovw6BGh9jKCx3JDkl4/k8yi5C4fTZ pXuoNm7O+cMmeDKy2Dn/R9bGb0Yr4gTqcaxWt2pSfcpQKwcIQec6y1S7odfl/HaeV/Mu OHSPim9iz/oHXCNddVIm8DrzC4OzGdEViFgicKICO1gflra8lvIzZYsvd5ZG+Mw/vEGK VG2A==
X-Gm-Message-State: AFeK/H1lDYq/V9VvHOLKq1C4uSHafh3bma+h8C+2DQ2BYDkNZItbncSX7reor3nysJPEsMs3oRB8+QNdYUabuA==
X-Received: by 10.200.53.209 with SMTP id l17mr6953625qtb.281.1489656570181; Thu, 16 Mar 2017 02:29:30 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.140.42.181 with HTTP; Thu, 16 Mar 2017 02:29:29 -0700 (PDT)
In-Reply-To: <20170316073753.GE2367@Space.Net>
References: <CA+b+ERkt6MJUPR-4WX0LYZ9CG1FoNX-g4=hnqFB9iQy8WfKOww@mail.gmail.com> <20170315000326.GO12864@pfrc.org> <CA+b+ERmWUL-pVwjW8Vq+Vz8UzYDpcVBZxxhtM6WFqhmG+r35WA@mail.gmail.com> <58C95A05.3030107@foobar.org> <20170315195050.GT12864@pfrc.org> <CA+b+ERn-uya3kB-FgXvfFjdK-hPmj-W-mv_T+TnbEAfkzR8Hfg@mail.gmail.com> <20170315212656.GD2367@Space.Net> <CA+b+ER=MnejDq5JNyNUHvf7mV7vkFehbeE65a_5cqFUsTEAzZA@mail.gmail.com> <CACWOCC-gAPbV0fdraHkkjhSo=Tc_YUFWMTOjx311a2XDJZMDmQ@mail.gmail.com> <CA+b+ERmxQkH75tbotT16hsZvqrvMVsX0G_zyY1ofA=kTZZzZ0w@mail.gmail.com> <20170316073753.GE2367@Space.Net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 16 Mar 2017 10:29:29 +0100
X-Google-Sender-Auth: _z6_xqPV9d49p_RepuSmJ2JCl6k
Message-ID: <CA+b+ER=92wsFQefzw=R6myCeSXfhsPiL3UgHiZ0mcMpsHHTwnQ@mail.gmail.com>
To: Gert Doering <gert@space.net>
Cc: Job Snijders <job@instituut.net>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a1143c7b0b406eb054ad5b225
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/HmG5G3vLaZnQtTPylCs6CxRRx84>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.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: Thu, 16 Mar 2017 09:29:33 -0000

Hi Gert,

There's large ISPs connecting with up to 4 routers to the IXP (so, same
> peer AS has multiple possible nexthops).
>
> There's also smaller ASes buying upstream from two or more ISPs that are
> all connected to the same IXP (so, same origin AS has paths through
> different neighbouring ASes at the same IXP).
>

Well ​for one I just went through talking to multiple large ISPs to get
transit via IXes and the answer is NO. They all (except one) said only
direct peering with fiber. And the one who accepts to come via IX clearly
requires direct eBGP session.

So even if ISP is connecting to IX he is not offering free transit so his
routes will not be downloadable from RS. That is the main point here.



> Optimizing the "route server shall distribute multiple paths" is only
> half of the solution.  More interesting for me is "where do I need to
> point my vendors to, to get them to implement proper black-hole
> detection in the forwarding path, so the BGP NH can be invalidated?"
> (I'm not aware of any gear that will do this right now, as in "if
> IPv4 ARP or IPv6 ND fails, mark NH as invalid and look for other paths
> in BGP" - but I'm always willing to learn)
>

​Cisco IOS classic/XE + NX object tracking is a cool feature quite unknown
as no marketing force was promoting it. You can run it even on Sup720 and
set frequency of probing accordingly :) ​I use it every day.

Juniper have had similar tool, but less flexible.

Asking vendors (or extend BFD spec) to support BFD livness detection to set
of destinations (say your current active next hops) without protocol may be
a wise move too.

But if we know that in real deployments only 0%, 33% or 50% nets have path
redundancy on RS sending information there in the new SAFI .. such that
single path nets lost reachability to next hops on all or some clients will
do no good.

​Thx,
r.​