Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

Let's also observe that while strict mode works fine for IGPs for BGP in
general it may be cause of a bit of surprise.

Imagine this is used on IBGP side and sessions to RR are getting dropped
while there is nothing wrong with reachability and quality of paths to
actual next hops.

Therefor shouldn't this discussion be moved a bit up to enhance the way we
validate the quality of next hop reachability before using paths containg
them vs heavy hammer to put the actual session down ?

I am sure Rajiv can be happy to enhance his proposal along those lines.

Unless this is only for p2p ebgp session I am not sure this proposal of bgp
strict mode as presented today is actually a good idea.

Best,
R.

On Thu, Mar 28, 2019, 13:04 Robert Raszuk <robert@raszuk.net> wrote:

> Hi,
>
> As commented on the mic for partially loosy links I would like to see
> hooks in BGP outside of BFD to determine if BGP session is to be
> established or torn down.
>
> Specifically using existing tools like rpm or ip sla probes ...
>
> Thx
> R.
>
> On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> In IETF 104, Rüdiger responded that he'd like to see BFD in BGP be used to
>> prove that a link is "stable enough" before we even announce routes.
>>
>> As I mentioned at the mic, the critical issue is that we have varying
>> implementations of when BFD must be up in differing implementations with
>> regard to the BGP FSM.  E.g. Up before we start the transport session
>> (Connect), or Up before we transition to Established, or Up after
>> Established.
>>
>> The proposal from Mercia and Acee effective summ to "if BFD strict
>> negotiated, wait for BFD to come up before transition to Established".
>> This
>> provides a common point for implementations to interoperate.  There is
>> still
>> potentially issue with older implementations that relied on BFD to be Up
>> before BGP starts its TCP session; however upon supporting this feature we
>> implicitly add an option where the behavior is changed.
>>
>> Back to Rüdiger's point: He has a desire that the session is stable before
>> we start announcing routes.  In BGP RFC parlance, we do not exchange our
>> routes in the Update-Send process until stability is declared.
>>
>> While this is doable, how do you negotiate what level of stability is
>> desired?  BFD, without extensions, mostly will simply declare the session
>> Down when enough packets are lost.  If the link quality is very bad, this
>> should happen quite quickly. If the link quality is partially lossy, BFD
>> doesn't help.  (However, see
>> https://tools.ietf.org/html/draft-am-bfd-performance-00)
>>
>> -- Jeff
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>