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

"Rajiv Asati (rajiva)" <> Tue, 14 March 2017 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDE5513153A for <>; Tue, 14 Mar 2017 14:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.623
X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id psu5YOL-8lvJ for <>; Tue, 14 Mar 2017 14:11:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 244F7131547 for <>; Tue, 14 Mar 2017 14:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3438; q=dns/txt; s=iport; t=1489525882; x=1490735482; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WyPgAFGQUBALJHsNj633KfZfCXkUp3l+tI/NowCP87U=; b=FEARQ13eyFpwIEA2noOI3Jky2416uLJVZJbf/VU+BwUIsfo+wTfMB3V4 3Mjjmz70aR1cCoLXSghjgsv71ZlWcgR5moZDOikLnJXpSTWXBNI1nfwg8 35nOeWlz+eGlpVr5VSoPal8h6C3y4IdbuE/rO4RvV7nkDJv+7ZSEg/bdl 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,165,1486425600"; d="scan'208";a="218547241"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 21:11:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2ELBLZk017045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 21:11:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 16:11:20 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 16:11:20 -0500
From: "Rajiv Asati (rajiva)" <>
To: Jeffrey Haas <>, Robert Raszuk <>
CC: idr wg <>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
Thread-Index: AQHSmnRjZQMhW6yq5kum3Hd4lOeZoKGSjLmAgABQ7oCAAAtWgP//sAtXgAKMygCAAADqAIAABbgA//++dAA=
Date: Tue, 14 Mar 2017 21:11:20 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 21:11:24 -0000

>    For third party nexthops, you can have persistant bad forwarding.  Normal
>   BGP procedure doesn't help you here.

Agreed. Unless BGP bestpath selection considers (event-driven) NH liveliness check, the blackholing problem would continue.


-----Original Message-----
From: Idr <> on behalf of Jeffrey Haas <>
Date: Tuesday, March 14, 2017 at 5:05 PM
To: "" <>
Cc: "" <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

    On Tue, Mar 14, 2017 at 09:45:28PM +0100, Robert Raszuk wrote:
    > 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.
    For first party nexthops, BGP timers can address this to some extent.
    BGP timers are too long, hence BFD.
    For third party nexthops, you can have persistant bad forwarding.  Normal
    BGP procedure doesn't help you here.
    So, we agree that the case isn't given good attention in the core specs.
    > > 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
    The new SAFI is targeted specifically for the RS case and hasn't received
    specific consideration for other use cases yet.  Feel free to kick off that
    as a topic, although I'd suggest doing so separably from the rs-bfd thread.
    -- Jeff
    Idr mailing list