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

Nick Hilliard <nick@foobar.org> Tue, 14 March 2017 21:21 UTC

Return-Path: <nick@foobar.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 3DE5F13155B for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 C74xNkhYIe0n for <idr@ietfa.amsl.com>; Tue, 14 Mar 2017 14:21:23 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F967131555 for <idr@ietf.org>; Tue, 14 Mar 2017 14:21:22 -0700 (PDT)
X-Envelope-To: <idr@ietf.org>
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v2ELLKQr049104 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for <idr@ietf.org>; Tue, 14 Mar 2017 21:21:20 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <58C85ECE.3080109@foobar.org>
Date: Tue, 14 Mar 2017 21:21:18 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.11 (Macintosh/20170302)
MIME-Version: 1.0
To: IETF IDR Working Group <idr@ietf.org>
References: <148924277112.2960.17904473852401253352@ietfa.amsl.com>
In-Reply-To: <148924277112.2960.17904473852401253352@ietfa.amsl.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zw8-I5ldvRzoEEk5_C7mbpYwhTw>
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:21:25 -0000

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.

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.

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.

Nick