Subject: Re: [Idr] draft-jdurand-auto-bfd-00

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Sat, 4 Jul 2015 00:19:28 +0000

Hi all,

> Acee and Jeff Haas find this to be a useful solution to consider for FRR and BGP.

Thanks a lot for the discussion during the call it was interesting.

> At the interim, it was suggested it would be useful for you to discuss on the mail list:
> ·         The differences between (draft-ietf-idrrs-bfd/draft-ymk-idr-bfd) with your draft on the mail list?

The main difference I believe is that draft-jdurand-auto-bfd-00 targets a solution without any requirement on the IXP route server. As the goal is to have a way to react when there are problems on an IXP we thought it was better not to rely on anything from the IXP, and give IXP members full capability to detect issues and implement solutions on their own.

Very briefly (I’ll let author give more info), draft-ietf-idr-rs-bfd uses BGP NH-SAFI on RS and client routers to share information of all client routers. Client routers then know about eachothers and setup BFD sessions to test their mutual reachability. Results of the tests are sent to RS (again using NH-SAFI). Policy can be applied on RS.

draft-jdurand-auto-bfd proposes that members simply setup BFD sessions with all BGP next-hops seen through the RS, and implement policy for received routes based on BFD session state. No requirement on the IXP. IXP members are autonomous.

The 2 drafts are quite short and I’d encourage people interested to read in order to see the other differences.

> ·         Any conflict between protection a BGP session at an IXP and protecting the connectivity of a prefix?

Well at this stage I don’t see any conflict but I haven’t spent much time studying this. I’m happy to hear from the group.

> ·         Any way this proposed standard changes BFD.

As we don’t want to keep BFD sessions forever in case we don’t need them anymore we spent quite some time studying session ageing. If member A does not receive routes from B (via RS), it would desire to stop BFD session. But we cannot do that if for some reason B receives routes from A (B would still need the BFD session with A). We propose to use BFD.Localdiag to signal interest in continuing BFD. Feedback from BFD people welcome here.

Please give us feedback!

> I’m sure I missed a few other valuable questions, but there seems to be real interest in you leading a discussion on this point.   You can lead this discussion on this thread or on the WG Adoption thread.
>  
> Sue
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 4 Jul 2015 12:42:39 +0200

Hello Jerome,

I read your draft and I would like to express strong support for it.

In fact I can see number of use cases completely outside of IX space too.

Three minor comments:

1.

"routers can automatically try to establish a new adjacency
for every new BGP next-hop."

Comment: Imagine that you are receiving 10 or 20 paths for a given net
(obviously each with different next hop). Does it make sense to establish
BFD session to all of those next hops if you are not doing ECMP load
balancing actively to all of them ? Perhaps a comment in the draft on that
would be helpful.

2.

"If next-hops for the remote system are no longer being received,
the following occurs:"

Comment: I am a bit not clear on your notion of next hops being received or
not being received. If you have session established you have updates and
withdraws. If you received the update most likely (well except some new
SAFIs which do not enforce next hop) you also get next hops. If you get
withdraw you remove them.

So to me the new flag  "Continuing Auto-BFD" is really not needed and could
be just removed or if needed (which I doubt) replaced by a simple timer
saying that after last withdraw for a given NH you bring BFD down in X sec.
That would also allow to move the draft to informational status and perhaps
progress is faster :)

3.

In case you have an implementation which already supports today
establishing a session to BGP peering address perhaps a deployment
consideration could be added to discuss the recommended prefernece .. ie.
show advantage to have a session to next hops if for example GR is enabled.

In any case great idea and I would say it is one of those low hanging
fruits :)

Cheers,
R.

On Sat, Jul 4, 2015 at 2:19 AM, Jerome Durand (jerduran) <[email-masked]
> wrote:

> > ·         The differences between
> (draft-ietf-idrrs-bfd/draft-ymk-idr-bfd) with your draft on the mail list?
>
> The main difference I believe is that draft-jdurand-auto-bfd-00 targets a
> solution without any requirement on the IXP route server. As the goal is to
> have a way to react when there are problems on an IXP we thought it was
> better not to rely on anything from the IXP, and give IXP members full
> capability to detect issues and implement solutions on their own.
>
> Very briefly (I’ll let author give more info), draft-ietf-idr-rs-bfd uses
> BGP NH-SAFI on RS and client routers to share information of all client
> routers. Client routers then know about eachothers and setup BFD sessions
> to test their mutual reachability. Results of the tests are sent to RS
> (again using NH-SAFI). Policy can be applied on RS.
>
> draft-jdurand-auto-bfd proposes that members simply setup BFD sessions
> with all BGP next-hops seen through the RS, and implement policy for
> received routes based on BFD session state. No requirement on the IXP. IXP
> members are autonomous.
>
> Well at this stage I don’t see any conflict but I haven’t spent much time
> studying this. I’m happy to hear from the group.
>
> As we don’t want to keep BFD sessions forever in case we don’t need them
> anymore we spent quite some time studying session ageing. If member A does
> not receive routes from B (via RS), it would desire to stop BFD session.
> But we cannot do that if for some reason B receives routes from A (B would
> still need the BFD session with A). We propose to use BFD.Localdiag to
> signal interest in continuing BFD. Feedback from BFD people welcome here.
>
> Please give us feedback!
>
>
>
>
> > I’m sure I missed a few other valuable questions, but there seems to be
> real interest in you leading a discussion on this point.   You can lead
> this discussion on this thread or on the WG Adoption thread.
> >
> > Sue
> >

---

From: David Freedman <[email-masked]>
Date: Sat, 4 Jul 2015 11:11:58 +0000

Hi 

>Comment: I am a bit not clear on your notion of next hops being received or not being received. If you have session established you have updates and withdraws. If >you received the update most likely (well except some new SAFIs which do not enforce next hop) you also get next hops. If you get withdraw you remove them.
>So to me the new flag  "Continuing Auto-BFD" is really not needed and could be just removed or if needed (which I doubt) replaced by a simple timer saying that after >last withdraw for a given NH you bring BFD down in X sec. That would also allow to move the draft to informational status and perhaps progress is faster :)

Well, this was designed to address the problem of asymmetry (I.e, to make the BFD symmetric), in the case that we no longer see prefixes attached to a next hop (i.e, another IXP participant), we may still be advertising prefixes with ourselves as a next hop (i.e, through the RS, to them) and may want to keep the session from being torn down between the pair of us as a result. The flag is there really for the partner to let us know that it is still seeing routes from us (since we have no idea where they are being sent), and that we should not prune the session between us, simply because we see no routes from him.  
 
Dave.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 5 Jul 2015 01:30:44 +0200

Hi David,

Why do you need full BFD for auto-bfd as opposed to utilize S-BFD (Seamless
BFD) which is effectively unidirectional ?

Thx,
R.

On Saturday, July 4, 2015, David Freedman <[email-masked]>
wrote:

> Hi
>
> >Comment: I am a bit not clear on your notion of next hops being received
> or not being received. If you have session established you have updates and
> withdraws. If >you received the update most likely (well except some new
> >So to me the new flag  "Continuing Auto-BFD" is really not needed and
> could be just removed or if needed (which I doubt) replaced by a simple
> timer saying that after >last withdraw for a given NH you bring BFD down in
> X sec. That would also allow to move the draft to informational status and
> perhaps progress is faster :)
>
> Well, this was designed to address the problem of asymmetry (I.e, to make
> the BFD symmetric), in the case that we no longer see prefixes attached to
> a next hop (i.e, another IXP participant), we may still be advertising
> prefixes with ourselves as a next hop (i.e, through the RS, to them) and
> may want to keep the session from being torn down between the pair of us as
> a result. The flag is there really for the partner to let us know that it
> is still seeing routes from us (since we have no idea where they are being
> sent), and that we should not prune the session between us, simply because
> we see no routes from him.
>
> Dave.
>
>
>
>
>
>

---

From: David Freedman <[email-masked]>
Date: Sat, 4 Jul 2015 23:56:40 +0000

>Why  do you need full BFD for auto-bfd as opposed to utilize S-BFD (Seamless BFD) which is effectively unidirectional ?

We don't (need this) at all, but auto-bfd was not written with seamless BFD in mind (since classical BFD is what is out in the field now),
but I take your point, perhaps we should include the case where S-BFD will be used, in such case, of course, the flag can
be dispensed with.

Dave.

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Thu, 9 Jul 2015 16:20:21 +0000

Any other comment from the group?

Thanks!

Jerome

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 13 Jul 2015 15:59:43 -0400

[re-ordering the top posting to bottom]

> Any other comment from the group?

S-BFD isn't fully uni-directional, otherwise it wouldn't be bi-directional.
:-)

The important property from S-BFD is that no specific session needs to be
provisioned.  Regular BFD would still need to have a session bootstrapped
from gleaned information - BGP nexthops in our discussions.

It really should be understood that plain BFD can't quite do what this draft
intends to do since it requires alterations in the Diag code behavior for
signaling.  I'm going to suggest again wearing my BFD hat that this is not a
good idea in trying to move a BFD version of this proposal along.  But as
noted above, S-BFD won't have this particular issue.  The main issue is that
S-BFD is a very new feature and that it's going to take a while to deploy.

I'm going to make a point I made in an earlier response: The general
behavior of using BFD for BGP nexthops is covered in both proposals.  The
impact of permitting BFD on those nexthops to influence BGP route selection
is appropriately standardizable in IDR.  There's the related impact on BFD
for multiple sessions that will require some discussion in BFD that both
drafts will have to accommodate.

The RS-notification behavior, perhaps, can be made a separate issue.  It's
still valuable, but there's still room for discussion on the signaling.

I'd suggest this is a good discussion to have at IETF-93.

-- Jeff