Re: Service Redundancy using BFD

[Sami Boutros <[e-mail]>]

Hi Jeff,

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




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

>[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.  

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
>   to have a 1:1 mapping with a set of addresses.

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

>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. :-)

Sami: Sure we can 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.

Sami: Actually the revertive/non revertive behavior is a service behavior dictated by the administrator provisioning the service.
>
>[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.


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:
>- 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?

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
>
>
>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 <[e-mail]>
>> Date: Tuesday, November 28, 2017 at 6:20 PM
>> To: Ashesh Mishra <[e-mail]>
>> Cc: Sami Boutros <[e-mail]>, Ankur Dubey <[e-mail]>, "[e-mail]" <[e-mail]>, Reshad Rahman <[e-mail]>
>> 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 <[e-mail]<mailto:[e-mail]>> 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