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

Job Snijders <> Tue, 04 July 2017 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4311B131543 for <>; Tue, 4 Jul 2017 02:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DVWXZP1oVVqH for <>; Tue, 4 Jul 2017 02:26:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1B57F12EB31 for <>; Tue, 4 Jul 2017 02:26:50 -0700 (PDT)
Received: by with SMTP id w126so189943256wme.0 for <>; Tue, 04 Jul 2017 02:26:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hpfsOW84eIbHGzpttNIxPZRde4oxr/E/Ds3L3Al8JHU=; b=A6xmkT1Qo1Ew3XfpsOGwaDA05lmmsHldFw+P8iTezhk9o+HHXT+auOnLEMnMABpAJL L1tBBGhbHWRfL7abIQAy54hv5eemPvOMLe3rkNtkvVjyNqCQ50MendB2YKeQ/UNv3CGV uxh/vWRwqNrcAiIZp/X4f9+ehaJ/+gCMArWFgwbqNkfQ0IB6bbE+rv94LenUTr9pMrN2 NpBNOVn2152FUW68XliHcr2VmKlhUkWktOtuip/+C2BpiEEKs1fGTGoM6vSnQOM1sAd2 9TkdYIMNT8LHbpsnm4HFheaBZ5vCDGA0Abr0cnEKuyFL0ArxJKWz9VwFKuhw0EFLKJ2n QbRg==
X-Gm-Message-State: AKS2vOzWe0XfW6MCF/47IuRyIjqjuzNTQqSeWJ0cOz/IZHg2ctMV6qi6 FEeuCAaaXkd5ShiZ
X-Received: by with SMTP id b6mr15177239edd.81.1499160409340; Tue, 04 Jul 2017 02:26:49 -0700 (PDT)
Received: from localhost ([]) by with ESMTPSA id b30sm8853881edd.6.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jul 2017 02:26:48 -0700 (PDT)
Date: Tue, 4 Jul 2017 11:26:46 +0200
From: Job Snijders <>
To: Gert Doering <>
Cc: Robert Raszuk <>, idr wg <>
Message-ID: <20170704092646.yzahxshfjc5o66pg@Vurt.local>
References: <> <> <> <> <> <> <> <> <> <20170704083853.GJ45648@Space.Net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170704083853.GJ45648@Space.Net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jul 2017 09:26:53 -0000

On Tue, Jul 04, 2017 at 10:38:53AM +0200, Gert Doering wrote:
> On Tue, Jul 04, 2017 at 12:31:17AM +0200, Robert Raszuk wrote:
> > If client talks add-paths you send them two paths. You may send them
> > more if they wish so.
> > 
> > It is just broken desing to signal failure between nodes to get new
> > paths.  PIC has proven this long time back.
> > 
> > What this is about is really a new idea of sdn controller with bgp
> > and distributed bfd for weak clients.
> > 
> > Now maybe we could understand what are those weak clients who can
> > not handle two paths for a given net ?
> What makes you assume that these two paths will *work*?
> IXPs are big (like, 600 nodes), and there might be a partial outage
> that kills off everything behind one 100G link in a 4x 100G bundle ->
> 100+ remotes are gone.
> Two paths won't do much good then, if both next-hops are in that set.

Yes, two paths won't help when faced with catastrophic events (where
large clusters of participants of the IXP go offline). But should it?

In that case the IXP participant will have to use other means (IP
transit, private peering) until the IXP has been repaired (usually done
within a few hours?)

We already observed that path _diversity_ isn't that great at IXPs in
the sense that often there is only a single path towards a prefix:

I posit that it is safe to assume that other (non-RS) paths will always
exist (via transit, other peering), and as such in the trade-off between
keeping more state at the RS vs trying to keep the RS lean and mean, the
design parameters should be as following:

    - the main purpose of this draft is to ensure that each RS
      participant sets up BFD sessions to the other participants of
      interest, the main purpose is _not_ to ensure there are always
      paths even if half the IX is on fire. The priority should be quick
      fault detection, not to "make the best use of the IX under any and
      all circumstances".

    - we should work from the assumption that if a client supports
      draft-ietf-idr-rs-bfd, it will also have support for ADD-PATH. If
      we cannot assume this, I'd like to understand why.

    - explicitly consider scalability issues. The bigger internet
      exchanges are struggling with their current route server load, so
      if IDR adds any computational cost to their list of tasks, it'll
      need to properly justify that.

    - The technology facilitate setting up the minimum required set of
      BFD sessions, not the maximum.

Kind regards,