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

Gert Doering <gert@space.net> Thu, 16 March 2017 07:38 UTC

Return-Path: <gert@space.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 EEA1A126FB3 for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 00:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 HigDRCXIgfXU for <idr@ietfa.amsl.com>; Thu, 16 Mar 2017 00:37:59 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (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 17D6D126DFB for <idr@ietf.org>; Thu, 16 Mar 2017 00:37:56 -0700 (PDT)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 38151618BA for <idr@ietf.org>; Thu, 16 Mar 2017 08:37:54 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id F3B00604A9; Thu, 16 Mar 2017 08:37:53 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id EED598713; Thu, 16 Mar 2017 08:37:53 +0100 (CET)
Date: Thu, 16 Mar 2017 08:37:53 +0100
From: Gert Doering <gert@space.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Job Snijders <job@instituut.net>, Gert Doering <gert@space.net>, idr wg <idr@ietf.org>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ao30A/m+fEOaAmiA"
Content-Disposition: inline
In-Reply-To: <CA+b+ERmxQkH75tbotT16hsZvqrvMVsX0G_zyY1ofA=kTZZzZ0w@mail.gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/_JgUqehDamMgkksq4ZnB5a-EdOI>
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 07:38:02 -0000

Hi,

On Wed, Mar 15, 2017 at 11:38:31PM +0100, Robert Raszuk wrote:
> Thank you Job !
> 
> So this means that every third or second customer in first two IXes
> respectively connect to exchange with at least two edge routers or it could
> be the same CE router with two interfaces :).

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).


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)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279