Hi Jeff, Thanks for your comments, please see my comments inline Sami:
On 12/19/17, 8:22 AM, "Jeffrey Haas" <jh...@pfrc.org> 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 <gregimir...@gmail.com> >> Date: Tuesday, November 28, 2017 at 6:20 PM >> To: Ashesh Mishra <mishra.ash...@outlook.com> >> Cc: Sami Boutros <sbout...@vmware.com>, Ankur Dubey <adu...@vmware.com>, >> "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrah...@cisco.com> >> 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 >> <mishra.ash...@outlook.com<mailto:mishra.ash...@outlook.com>> 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
