Subject: Re: Service Redundancy using BFD

From: Jeffrey Haas <[email-masked]>
Date: Tue, 19 Dec 2017 11:22:24 -0500

[Speaking as an individual contributor.]

I'm going to pick this as my response point.  I'm not picking on you,
Ashesh. :-)

I have several concerns about the proposal in this document:

1. It's not very clear how services get mapped to BFD sessions.  As others
   are indirectly noting, p2p BFD sessions will have at most one session
   between any given address pair on IP.  This means that a service would have
   to have a 1:1 mapping with a set of addresses.
2. The bitmap which seems to be attempting to work around this restriction
   would have to have presence in the BFD payload.  As you're noting, Ashesh,
   it's not a natural fit in BFDv1.  A BFDv2 would likely have to be
   considered.  Is this the thing that finally makes us do it?  Let's keep
   talking. :-)
3. At a higher level, the "revertive" behavior isn't what I would consider a
   BFD-like behavior today.  This active/backup behavior is, however, very
   VRRP-like as others have already observed.  At a high level, VRRP feels like
   a slightly better fit for this proposal.

[And one point, speaking as a BFD chair:]

4. One thing I always impress upon people looking to change the BFD protocol
   to carry additional state is scale and responsiveness.  Is your information
   important enough to want to have to look for state or state changes every
   few milliseconds?  BFD is a *noisy* protocol and one that must run very
   fast.  

   The minute you look to start overloading that state with additional
   information, such as this prooposal, I suspect we start looking at slowing
   BFD down.

My recommendations are:
- Let's see further discussion about why BFD is a better fit than existing
  mechanisms.
- Does it really make sense to carry this centrally coordinated service
  mapping in BFD?
- Is this really the thing we want to choose as our motivation to start
  discussing BFDv2?

-- Jeff

On Tue, Nov 28, 2017 at 11:23:36PM +0000, Ashesh Mishra wrote:
> Damn straight! I’ve been broaching that subject for a while. But that’s a discussion for a separate (and much much longer and contentious) thread ☺
> 
> Ashesh
> 
> From: Greg Mirsky <[email-masked]>
> Date: Tuesday, November 28, 2017 at 6:20 PM
> To: Ashesh Mishra <[email-masked]>
> Cc: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>, "[email-masked]" <[email-masked]>, Reshad Rahman <[email-masked]>
> Subject: Re: Service Redundancy using BFD
> 
> Hi Ashesh,
> I agree that there are new scenarios and use cases to apply BFD-like mechanism. Is it then time for BFD v2.0?
> 
> Regards,
> Greg
> 
> On Tue, Nov 28, 2017 at 3:17 PM, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Greg,
> 
> I’m just trying to understand the use of BFD in this proposal.
> 
> I agree with you that 5880 was clear in its scope at the time, but that should not inform the entire scope of BFD in the future.
> 
> Ashesh

---

From: Sami Boutros <[email-masked]>
Date: Tue, 19 Dec 2017 18:32:44 +0000

Hi Jeff,

Thanks for your comments, please see my comments inline Sami:

On 12/19/17, 8:22 AM, "Jeffrey Haas" <[email-masked]> wrote:

>   between any given address pair on IP.  

Sami: The mapping of services to a BFD session can be statically provisioned at both endpoints by a controller. We can clarify that in the next rev.

>This means that a service would have

Sami: Not sure, how you came to that conclusion, we don’t need a 1:1 mapping.

>   considered.  Is this the thing that finally makes us do it?  Let's keep

Sami: Sure we can keep talking :-)

>   a slightly better fit for this proposal.

Sami: Actually the revertive/non revertive behavior is a service behavior dictated by the administrator provisioning the service.
>   information, such as this prooposal, I suspect we start looking at slowing

Sami: 2 points here, the proposal in the draft has 2 aspects, 1) the diag code via which one node inform the other node that it outlived it, and 2) the Bitmap presenting the services, we understand that BFD is a *noisy* protocol this is why the bitmap is only communicated on few packets that correspond to the session timeout.

>- Is this really the thing we want to choose as our motivation to start

Sami: Sure, this sounds like a plan. But please keep in mind that we are proposing 2 aspects here as mentioned above, and we feel the out-lived aspect in the diag field will be a very handy feature that can help redundancy.

Thanks,

Sami

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 Dec 2017 20:33:48 -0800

Hi Sami,
you've said:
Sami: 2 points here, the proposal in the draft has 2 aspects, 1) the diag
code via which one node inform the other node that it outlived it, and 2)
the Bitmap presenting the services, we understand that BFD is a *noisy*
protocol this is why the bitmap is only communicated on few packets that
correspond to the session timeout.

Do you think that RFC 7275 ICCP may be used or extended for these two goals?

Regards,
Greg

On Tue, Dec 19, 2017 at 10:32 AM, Sami Boutros <[email-masked]> wrote:

> Sami: The mapping of services to a BFD session can be statically
> provisioned at both endpoints by a controller. We can clarify that in the
> next rev.
>
> Sami: Actually the revertive/non revertive behavior is a service behavior
> dictated by the administrator provisioning the service.
> >
> Sami: 2 points here, the proposal in the draft has 2 aspects, 1) the diag
> code via which one node inform the other node that it outlived it, and 2)
> the Bitmap presenting the services, we understand that BFD is a *noisy*
> protocol this is why the bitmap is only communicated on few packets that
> correspond to the session timeout.
>
> >
> >My recommendations are:
> Sami: Sure, this sounds like a plan. But please keep in mind that we are
> proposing 2 aspects here as mentioned above, and we feel the out-lived
> aspect in the diag field will be a very handy feature that can help
> redundancy.
>
> Thanks,
>
> Sami
>
> >
> >-- Jeff
> >
> >
> >> Damn straight! I’ve been broaching that subject for a while. But that’s
> a discussion for a separate (and much much longer and contentious) thread ☺
> >>
> >> Ashesh
> >>
> >> Cc: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>,
> "[email-masked]" <[email-masked]>, Reshad Rahman <[email-masked]>
> >> On Tue, Nov 28, 2017 at 3:17 PM, Ashesh Mishra <
> [email-masked]<mailto:[email-masked]>> wrote:
> >> Hi Greg,
> >>
> >> I agree with you that 5880 was clear in its scope at the time, but that
> should not inform the entire scope of BFD in the future.
> >>
> >> Ashesh
>