Re: [Idr] RS BFD draft
Jeffrey Haas <jhaas@pfrc.org> Tue, 18 April 2017 20:31 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD7127876 for <idr@ietfa.amsl.com>; Tue, 18 Apr 2017 13:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8XTSe4XjX7Z for <idr@ietfa.amsl.com>; Tue, 18 Apr 2017 13:31:15 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DA4A21243FE for <idr@ietf.org>; Tue, 18 Apr 2017 13:31:15 -0700 (PDT)
Received: by slice.pfrc.org (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 <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: Jeffrey Haas <jhaas@juniper.net>, idr wg <idr@ietf.org>
Message-ID: <20170418203823.GC9688@pfrc.org>
References: <CA+b+ERnHAdrQa1f-b7st3QBjzbFS1zvktkGCAppRuqGkf8Vnhg@mail.gmail.com> <CA+b+ER=E1FV4=-W9jcHG4ih0GeE2O1jDXKNAZhEe+nENEHAiYg@mail.gmail.com> <CA+b+ERkfV4C++arFCBXnyjgkA-FtcqMmd8_9UcbKLWxR32h1EQ@mail.gmail.com> <CA+b+ERkvu296sqD_bi41++RqHiV-f+4cUpb1BPrhE6HsxeueqA@mail.gmail.com> <CA+b+ERk+XP5DvuZStYW=e1uGRWDWE-PiPdwhtkHiVK7hFui7_g@mail.gmail.com> <CA+b+ERmapG68ysZ4=6uDAH=Z+fRaprzgsyQASP4aYD=OTea_Qg@mail.gmail.com> <CA+b+ERkZ-WY5FWiDu_k=1+7tUHEApYj+mMLqZiFzTWGuvHLjGA@mail.gmail.com> <CA+b+ER=MBiFno8CDv9JgpFFmJz4cuDe_tQhm+AHx5njxJy6p6Q@mail.gmail.com> <CA+b+ER=3qy_096Q61FBQgkRSt8j0P1NTQ+EFVit0XEnWvLp6mg@mail.gmail.com> <CA+b+ERmuGSZBcboZDsRo1NDb3dsRozmcEW77KWLyzyjxK8ezww@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+b+ERmuGSZBcboZDsRo1NDb3dsRozmcEW77KWLyzyjxK8ezww@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/guNqgEt5vk7cW4uAZim_S8kgSm4>
Subject: Re: [Idr] RS BFD draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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 off-list. 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 > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr
- Re: [Idr] RS BFD draft Jeffrey Haas
- Re: [Idr] RS BFD draft Nick Hilliard
- Re: [Idr] RS BFD draft Gert Doering
- Re: [Idr] RS BFD draft Robert Raszuk
- Re: [Idr] RS BFD draft Nick Hilliard
- [Idr] RS BFD draft Robert Raszuk