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

Jeffrey Haas <> Tue, 14 March 2017 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B7A1293F4 for <>; Tue, 14 Mar 2017 14:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.003
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mx92USqFbjfJ for <>; Tue, 14 Mar 2017 14:42:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CF1F126FDC for <>; Tue, 14 Mar 2017 14:42:07 -0700 (PDT)
Received: by (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 <>
To: Nick Hilliard <>
Cc: IETF IDR Working Group <>
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] 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:42:08 -0000


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

>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