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

[Jeffrey Haas <[e-mail]>]

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