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

Robert Raszuk <> Mon, 13 March 2017 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 814821295B3 for <>; Mon, 13 Mar 2017 05:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQ0ASsgKe3KN for <>; Mon, 13 Mar 2017 05:33:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5B6D1295A8 for <>; Mon, 13 Mar 2017 05:33:26 -0700 (PDT)
Received: by with SMTP id 1so220176647qkl.3 for <>; Mon, 13 Mar 2017 05:33:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v+JslLP7etPBM2rpOXv0w0tYTBV4xmgQhvZ3OMHzH70=; b=Y1uUOEaFKR93xd2bAbWfWCyqJlz4qweiY5DXFp91C7D1PmNPF02lFbuavLk9UoaAeZ Mo83IyllR86dnnXF+fFe/sC/dqrYkDU3b072jcKHjEiKnSZvQOdAq5gfOsGIZoE2ZK8b 7wMj/y0hogZRqDekbibEEAETtqvtIk0ZljUus6uBvn9puzveEwdikCv1Ja0MQHRPpmdr cbKBB9LFYSyGygMGLwTGM8l66fEJ4Mw4nbQcpdBxfscNU4j2bMYUlWTg649+wwoIgX2j wOx8ZocCphcv0GhGv/E1WEKuL/xeh1BxudEjr92NMkUS7JZeuYbjFawyRsJNn0pAzj8k y9cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v+JslLP7etPBM2rpOXv0w0tYTBV4xmgQhvZ3OMHzH70=; b=Fv2msirr+OAZA+Rr9uQx1Z8RY+xeDLgKgHiHOe0n8i1DT+mdU5AKjo9tWKRKeimrEj ZjDI1yxVqvNWLi8Np0J6D2FauGO5+N6vfKGy8C1cw/47hHpEO7OLe0Yt1haxo5hRUUiK 6gcjlZdtGrw3ART1wzYc3cfrOMf7B0QjNhAxLgD/NoUwWIh8Ljs6bMxVS79oHO2ncHf5 Q6/RPLLxCgbdDEIiiG1CnXTlhJ/nDEuBK/UMRYanqgxh0/CFVRP+dbk+WYx48ief5NV1 DUKSo6dT4BuRrgRayyxz5YTi0WHnvyv+N9KpoErbctmHczGXdq89Za/vIgX5eIKPk4Uy Movw==
X-Gm-Message-State: AMke39nzXDGcCK2akV7K97eQSQTpK5Pn37reO7goSXzSPGmBS1k1RFTqAgS08/9oTl3LxkYA+K9MAqr1iflyHg==
X-Received: by with SMTP id s4mr30326612qkd.101.1489408405897; Mon, 13 Mar 2017 05:33:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Mar 2017 05:33:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Robert Raszuk <>
Date: Mon, 13 Mar 2017 13:33:25 +0100
X-Google-Sender-Auth: K2XgldIhQdkq4TunftxIZNN_zMI
Message-ID: <>
To: Randy Bush <>
Content-Type: multipart/alternative; boundary="94eb2c057a70f5adb0054a9beacc"
Archived-At: <>
Cc: Interminable Discussion Room <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Mar 2017 12:33:28 -0000

> let's break tradition and actually see what the document says.

​Let's also break tradition and become a bit open minded to look at bigger
picture vs just consider on one specific solution to the problem.

> Abstract
>    When route servers are used, the data plane is not congruent with the
>    control plane.  Therefore, the peers on the Internet exchange can
>    lose data connectivity without the control plane being aware of it,
>    and packets are dropped on the floor.

​That not correct if you do it right. If you can reach A via NH1 and NH2
and RS propagates both of those NHs to clients - it is up to clients to
validate those NHs and choose one which they prefer for forwarding at a
given point of time.

RS does not need to be part of that game at all.

> ​   ​
> This document proposes the use
>    of BFD between the two peering routers to detect a data plane
>    failure,

​BFD can be extended to work without protocol, object tracking ​can used,
passive or active probes traversing next hops etc ... but it's a local
matter on the client.

In fact it remains interesting to see what timers are required to handle
BFD to say 1000 peers from a single box.

Now comes BFD security with maintaining different MD5 keys across 1000
peers ! The draft says read RFC5880 and that's what is there.

> ​a​
> nd then uses a newly defined BGP SAFI to signal the state
>    of the data link to the route server(s).

​Signalling anything to route servers is not needed. It puts us all back to
late 80s' or early 90s' on how networks were running at that time.

and, if you wander over to the referenced route server docco, you'll see
> that it already deals with alternate paths.

​It's not about "dealing with them" ... it is about distributing them to
the clients so clients can use them.