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

Robert Raszuk <> Tue, 14 March 2017 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9B7C1314CF for <>; Tue, 14 Mar 2017 13:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJ-xt8t856Y9 for <>; Tue, 14 Mar 2017 13:45:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 551EF1314CD for <>; Tue, 14 Mar 2017 13:45:30 -0700 (PDT)
Received: by with SMTP id y76so258092743qkb.0 for <>; Tue, 14 Mar 2017 13:45:30 -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=6yK4Jpz0GbKvGZcCHi63uYR9XMDOLpnlpkO2MJZjKY8=; b=edvPCdzU2ncvSwWJSJQZs+i/LiGDIaYfDm3HLztxioLcit/VuZfjQfrZbBNTIX9VoJ FMveOcVrTc+awAxOIx/GjZwfwVZH44F2kLrE8dMwUw242erHwhEMpeavj8Fyy5cCDtRs Xl4QJZ74dB4xqXMttiEgBfgKD4X9isX2xDjzGbzNe+hGbE86v8HI4kew3oUlHcYi4YJT x0CfrvVq0dVAcD+oJEAJtaI7pBV/Kt/gP7lMRfFHVf2J+puugW1u6hgMj0LYbSLZ02+9 h+CJzlBjFV6AimPG4Yr1xbisjDNAQgmAN5F1N0DuwFbvX4SdNJbNHBGc+AtPX1D4vuoi 5Qug==
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=6yK4Jpz0GbKvGZcCHi63uYR9XMDOLpnlpkO2MJZjKY8=; b=X/QmKYqpSC4WRYo64pGRN9YIivDXNStooyOWGO6hcc+nTEqCTj2UE0wLCMDlxx3BV7 vqQFbw20VGIifsL3t4JU1JpmLnLChjtkl5+BOVq6E92JQtph9wU4fZ0HtNblEek+tzkP ErjkOjz4di5mJPL/Pt1HiLD4acAJvwzaINC8jlkvPnONGURH3puqHKwt3bIlFfi/mda2 V8olnyqkFjv1iy0m9BcbiobYx2JneVW59zCGfE1vL+gqfF+iMs6WqV6smEo6b17P+rzb 4446tMVQdF8rROQ7LZR146gKs0gMZJXCI/WlcsYkRLcJL0ll6Sc5h3tH9Xi/qHKyO/KH GUlA==
X-Gm-Message-State: AMke39kjy9BMZSQzd7PO54aDp05v7+cYIGUg8Yr2etb4ig3jV6/jF1xKkv3qNiJHwRG9arN9UnjoYWa4MSxD7A==
X-Received: by with SMTP id s4mr37591815qkd.101.1489524329420; Tue, 14 Mar 2017 13:45:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 14 Mar 2017 13:45:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Robert Raszuk <>
Date: Tue, 14 Mar 2017 21:45:28 +0100
X-Google-Sender-Auth: YOliGWvDviqMQN6rwVHwE-U7qjY
Message-ID: <>
To: Jeffrey Haas <>
Cc: Nick Hilliard <>, idr wg <>
Content-Type: multipart/alternative; boundary="94eb2c057a708a247d054ab6e868"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.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, 14 Mar 2017 20:45:32 -0000

​Hi Jeff,​

> I said RS does not need to bothered with that information.
> The relevant bit of procedure within this document to run BFD toward an
> eBGP
> nexthop and use it in the local decision process is of potential value even
> without the RS SAFI part of the protocol.  So, in this respect, I agree.

​Completely agree !

In fact to me this is basic 4271 as you should not use a path (even single
path) if you can not validate if the next hop to it is reachable.

I think we all in BGP did not pay that much attention to reachability on
multiaccess LANs ​as most peering happens on p2p links where the same
problem does not happen.

> The authors had previously discussed extracting this procedure from the
> document and are fine with doing so if it makes sense.

Makes sense. It should be done by default one way or another. /* Not sure
if BFD considering those "weak customer peering routers" is the best idea.

The one "common" use case where this may be of benefit outside of a
> route-server environment is BGP "VPNs" that are constructed using IPSEC
> tunnels with the network effectively an NBMA subnet.

​See all SD-WANs today need more then one path such that they make
forwarding decision by probing all alternative overlay links and based on
the applied logic switch over to better or lower cost or less delay path.
If you give them just single path this is all no longer possible. That is
what worries me in this the most if you would like to utlize this new NH