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

[Nick Hilliard <[e-mail]>]

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