Re: [Idr] RS BFD draft

Jeffrey Haas <> Tue, 18 April 2017 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FFD7127876 for <>; Tue, 18 Apr 2017 13:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P8XTSe4XjX7Z for <>; Tue, 18 Apr 2017 13:31:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DA4A21243FE for <>; Tue, 18 Apr 2017 13:31:15 -0700 (PDT)
Received: by (Postfix, from userid 1001) id A5DF61E332; Tue, 18 Apr 2017 16:38:23 -0400 (EDT)
Date: Tue, 18 Apr 2017 16:38:23 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: Jeffrey Haas <>, idr wg <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] RS BFD draft
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, 18 Apr 2017 20:31:17 -0000

On Fri, Mar 31, 2017 at 09:34:08AM -0500, Robert Raszuk wrote:
> To your point of assymetry ...
> If the assymetry happens between clients placed in different rib groups of
> the given RS to corellate it is really ugly and breaks all today's code
> running as BGP route servers in the field.
> Besides for say UDP streaming unidirectional connectivity is not that bad
> to withdraw reachability just because symmetry is not there.
> Last most IX clients may have other connectivty outside of IX fabric in one
> or both directions so even TCP would work.

For posterity for the mailing list, Robert and I had this discussion

In particular, this refers to the point covered in section 4.2 of the RS-BFD
draft.  This is where the route server may tell one peer about routes with a
given nexthop but not tell the other peer about *any* routes with the
nexthop for that first peer.  Since BFD requires a pair of endpoints over
which to provision a session, it is necessary for the route server to make
sure both sides are informed about both sides/nexthops even if routing only
advertises them one way.

> Bottom line I agree on the need to document as BCP NH tracking part of the
> draft between IX clients, but new SAFI seems to me not to be a best idea.
> Best,
> R.
> PS. If client does not support add-path it can use different sessions as
> described by RFC6774.

The RS-BFD proposal doesn't preclude other mechanisms for advertising
alternate paths.  I'd be interested in hearing about RS operators that have
any intentions of deploying BGP add-paths[1] or diverse paths.

-- Jeff

[1] It should be noted that add-paths is considered problematic in the
traditional eBGP route distribution scenario.
draft-pmohapat-idr-fast-conn-restore was originally drafted to address that
case for traditional service provider networks.  

> _______________________________________________
> Idr mailing list