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

Jeffrey Haas <jhaas@pfrc.org> Tue, 14 March 2017 21:42 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 66B7A1293F4 for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level:
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[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 Mx92USqFbjfJ for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:42:07 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1F126FDC for <idr@ietf.org>; Tue, 14 Mar 2017 14:42:07 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 8F5E61E33B; Tue, 14 Mar 2017 17:48:17 -0400 (EDT)
Date: Tue, 14 Mar 2017 17:48:17 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Nick Hilliard <nick@foobar.org>
Cc: IETF IDR Working Group <idr@ietf.org>
Message-ID: <20170314214817.GI12864@pfrc.org>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com> <58C85ECE.3080109@foobar.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <58C85ECE.3080109@foobar.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9hvMK6IcJ0NFh1sgGSo_8-u-PjI>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt
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, 14 Mar 2017 21:42:08 -0000

Nick,

On Tue, Mar 14, 2017 at 09:21:18PM +0000, Nick Hilliard wrote:
> the text states:
> 
> > 5.1.  Route Server Client Procedures for NHIB Changes
> > 
> >    When entries are added to the a route server client's Adj-NHIB-In for
> >    a route server peering session, it will then attempt to verify
> >    connectivity to the BGP nexthop for that entry.  The procedure
> >    described in this specification utilizes BFD; other mechanisms are
> >    permitted but are out of scope of this document.
> 
> It might be an idea to explicitly acknowledge that some clients may want
> to selectively filter out NHIB on the basis that they don't want to
> establish bfd sessions to those particular NHs.  There could be many
> reasons for this, e.g. reliability of bfd on the remote side,
> reliability of bfd on the local side.  This would require some selection
> mechanism to be implemented on the client.

We had some text in earlier internal versions of the document that tried to
make this explicit.  I believe the text that remains is appropriately
permissive but maybe not as explicit as you might like:

:   At the route server, the Adj-NHIB-Out for each client is populated
:   with the next hops from its Loc-RIB.  If the BGP capabilities learned
:   during BGP session setup identify a next hop as compatible with this
:   proposal, this is reflected in the NHIB.  Initially, it is assumed
:   that the client router is able to reach its next hops which is stored
:   in the NHIB.  If a next hop is added to the NHIB for a particular
:   client, a route SHOULD be added to the router server's Adj-NHIB-Out.

The SHOULD is the relevant point.  This didn't make it into the sections for
explicit NHIB behavior, and probably could use some emphasis in a future
revision.

>From the client procedure side:
:   If the client can not establish a BFD session with an entry in its
:   NHIB, the next hop is put it in the Adj-NHIB-Out for backward
:   compatibility.

> A couple of other things:
> 
> 1.  if a route server client stops announcing prefixes to the route
> server but still accepts prefixes, do all bfd sessions to it also get
> torn down?  Or is the purpose of the RS Adj-NHIB-In to ensure stickiness
> of bfd sessions?  If this is the case, it should be mentioned explicitly
> because otherwise the feedback loop looks ... well, a bit peculiar.

Section 5.2:


:   In the event that a given client that supports this feature does not
:   provide any routes containing BGP next hops that would be used to
:   populate an Adj-NHIB-Out entry, the route server SHOULD advertise an
:   entry for such a router using the provided self-originated entry.
:   This permits the provisioning of BFD peering sessions for continuity
:   check when route exchange via the route server is asymmetric and one
:   client has routes from a second client, but not vice-versa.

> 2.
> >                    It is incorrect provisioning for an IXP client which
> >    is using a Route Server to have a BGP session with another IXP
> >    client.
> 
> lolno, if I'm reading this correctly.  It's quite usual to have
> bilateral + multilateral sessions configuration between router pairs.

I suspected the sanity check might bounce here. :-)

We'll update the wording accordingly.  The main consideration is the new
SAFI doesn't get negotiated and start transitively propagating the state.

It might be worth adding verbiage about ensuring RS-Reachable SAFI have an
AS_PATH that is consistent with directly connected peers instead.

-- Jeff