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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CFA9131535 for <>; Tue, 14 Mar 2017 14:08:39 -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 5L9UUwQgJZ4x for <>; Tue, 14 Mar 2017 14:08:37 -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 AEBF6129B33 for <>; Tue, 14 Mar 2017 14:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3272; q=dns/txt; s=iport; t=1489525717; x=1490735317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uGPNSBwR7xBm0pMT4Y06gKdr8bSPpTF5hXZcU+RW6cs=; b=YI1UPibpmR+DT88YeTrcHRRlRMXpMpZhuJIn8Frkr+8ii9gfOeRnOjHp Tw29RS+ZBBDUTIWF0oeTqGTA88HrPnOhyKBsezYAotu2nZYU+lQSKvs7B yp1sxulxOGE6ZNww8A7Ssoh0q0rGLi3cQxYVxyRanpWNWka5DJVvHujbK E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,165,1486425600"; d="scan'208";a="218540624"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2017 21:08:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2EL8Pvs000841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Mar 2017 21:08:25 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 14 Mar 2017 16:08:25 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 14 Mar 2017 16:08:24 -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//sAtXgAKMygD//8REAA==
Date: Tue, 14 Mar 2017 21:08:24 +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:08:39 -0000


Is the assumption here that the client routers have routing view limited to what’s provided by the Route Server? If not, then wouldn’t Client Routers benefit from having to invalidate the path learned from the remote client router as soon as the connectivity check failed?

Of course, Client Routers conveying the lack of NLRI reachability per NH to the Route Server, and expecting Route Server to provide a different NHs of the NLRIs, and expecting it to be functional, while still attracting the traffic for unreachable destinations since the Loc-RIB is still pointing to the unreachable NH for the affected NLRIs.

I wonder whether be useful here.

Rajiv Asati
Distinguished Engineer, Cisco

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

    I'll let the other comments in this thread stand on their merit.  However, I
    did want to respond to one specific point here:
    On Mon, Mar 13, 2017 at 11:45:25AM +0100, Robert Raszuk wrote:
    > I am afraid you have completely missed my point.
    > I never said clients must not detect other clients liveness before using it
    > for best path selection and in their local data planes.
    > 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.
    The authors had previously discussed extracting this procedure from the
    document and are fine with doing so if it makes sense.
    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.  
    -- Jeff
    Idr mailing list