Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt

From: Marc Binderberger <[email-masked]>
Date: Tue, 27 Nov 2012 23:47:54 +0100

Hello BFD experts,

Nobo and me are interested in your feedback for a new proposal we make to enhance the redundancy characteristics of BFD.

With requirements (*) to run BFD practically without interruption at short timer intervals we think it's worthwhile to think about and discuss it.

(*: I'm sure you either have similar requests from your customers or you are one of these customers asking for it ;-)

Best regards,
Marc

Begin forwarded message:

> From: [email-masked]
> Date: November 27, 2012 23:32:18 GMT+01:00
> To: [email-masked]
> Subject: I-D Action: draft-mbind-bfd-redundancy-00.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Redundant BFD sessions
> 	Author(s)       : Marc Binderberger
>                          Nobo Akiya
> 	Filename        : draft-mbind-bfd-redundancy-00.txt
> 	Pages           : 7
> 	Date            : 2012-11-27
> 
> Abstract:
>   This document defines a second or "shadow" BFD session to an existing
>   "primary" BFD session, providing resilience against BFD failures that
>   are not legitimate.
> 
>   Scenarios will be discussed on how presence of a shadow BFD session
>   will be beneficial in the context of high availability.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-mbind-bfd-redundancy
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-mbind-bfd-redundancy-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 28 Nov 2012 02:35:09 +0000

Hi Marc,
in section 2 you list four possible causes for positive negatives due to BFD monitoring interruption, not path failure. But I believe that detecting cases 2 and 4 is actually what is expected of BFD as FPGA and LC failures directly affect data path. Which of remaining scenarios 1 and 3, in your opinion, will be excluded by shadow BFD session to justify new version of BFD?

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Tuesday, November 27, 2012 2:48 PM
To: [email-masked]
Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hello BFD experts,

Best regards,
Marc

Begin forwarded message:

> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 28 Nov 2012 05:42:41 +0000

Hi,

In failure scenarios that you have mentioned, there are ways for NMS to inform the remote nodes of the failure. 

Also as you mentioned, the worst case is that protection is triggered and nothing bad happens. So I am not convinced we need a backup BFD session.

Even if a backup BFD is needed, then why not us a different "my Discriminator" and "your discriminator" to distinguish them?

Regards,
Shahram

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Nov 2012 05:48:30 +0000

Hi all,
I've read the draft, and I concur with Greg's comment: at least some of the scenarios described as possible causes for false detection of the session failure look like legitimate path failures to me.

I also assume (even if the draft does not spell this out) that the problem is false detection of the BFD session failure by the peers of the router that experiences one of the scenarios described in the draft.
IMHO and FWIW handling of "local" problems with the BFD session does not require any modifications to the BFD standards, it is an implementation issue. As a consequence, I wonder why the shadow session would be really helpful in differentiating between "true" and "false" path failures. 

E.g., consider crash of the BFD-handling process in a SW-based BFD scenario: does the draft suggest that "main" and ""shadow" BFD sessions would be handled by two different BFD processes? (This probably would not help n the case of CPU starvation.) Or does the draft assume that the crashed process could be restarted fast enough to maintain at least one of the two paired sessions intact for the peers? If this is what the draft proposes, would not the same result be achieved by simply increasing the session failure detection time?

Failure of the routing processor card in the centralized BFD scheme looks like another valid use case of false path failures. But how would the "shadow session" help in this scenario? Does the draft assume that the "shadow" session would be handled by the backup routing processor (assuming there is one)? This is possible, but is it sufficiently different from implementing "hot standby" for the BFD sessions in the  backup rouging processor?

Yet another side of the problem is a (pretty obvious IMHO) requirement for the mechanism differentiating between "true" and "false" data path failures not to increase the time it takes to detect the "true"/"legitimate" failure. The draft does nt explicitly describe how the "shadow" session is used in he case of "true" failures, so it is not clear to me if the proposed mechanism really meets this requirement.
If this requirement is not met, simply increasing the session failure detection time looks like a trivial answer for most (if not all) of the scenarios mentioned in the draft.

My 2c.
     Sasha

________________________________________
From: [email-masked] [[email-masked]] on behalf of Gregory Mirsky [[email-masked]]
Sent: Wednesday, November 28, 2012 3:35 AM
To: Marc Binderberger; [email-masked]
Subject: RE: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hi Marc,

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Binderberger
Sent: Tuesday, November 27, 2012 2:48 PM
To: [email-masked]
Subject: Fwd: I-D Action: draft-mbind-bfd-redundancy-00.txt

Hello BFD experts,

Best regards,
Marc

> ftp://ftp.ietf.org/internet-drafts/

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 28 Nov 2012 06:00:47 +0000

I concur with Greg's comments.

Regards,
Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 28 Nov 2012 10:00:07 +0100

Hello Gregory,

thanks for your feedback. 

> in section 2 you list four possible causes for positive negatives due to BFD monitoring interruption, not path failure. But I believe that detecting cases 2 and 4 is actually what is expected of BFD as FPGA and LC failures directly affect data path.

you are right, depending on the hardware design these may be true failures that should be detected with BFD. What we should have mentioned for (2) is that depending on the design you have FPGAs that are "extra" chips to handle the rapid packet generation/detection needed for OAM. In some architectures the forwarding may be distributed but the OAM may be centralized (for cost reasons, one FPGA can produce large volumes of BFD, no need to distribute).

The case (4) is similar in the sense that the linecard (*) where you produce the BFD packets is not or not always the linecard with the physical path. An example is BFD over a logical bundle, i.e. the single BFD session into the "big pipe" LAG. If the LAG member links are spread across linecards L1 and L2 then a failure of L1 may be still "okay" for the LAG if L2 carries enough member links. But when the BFD packet generation happens on L1 then a BFD failure would be detected on the peer, without a need.

(*: i.e. the card with the physical ports; you may use a different term for it)

You can extend this to other "virtual" interfaces, GRE tunnels, MPLS-TE/-TP and so on.

> Which of remaining scenarios 1 and 3, in your opinion, will be excluded by shadow BFD session to justify new version of BFD?

both, assuming that you have a 2nd Route processor (RP) in case (3) as you could run the shadow session on the "standby RP". And for (1) the crash could be handled with a 2nd BFD process, if possible on another CPU.

Again, very helpful comment, looks like we need to explain more the possible scenarios.

Thanks & Regards,
Marc

--
Marc Binderberger           <[email-masked]>

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 28 Nov 2012 14:42:51 +0000

Hello Sasha,

Thanx for comments. Please see inline.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Vainshtein
> Sent: Wednesday, November 28, 2012 12:49 AM
> To: Gregory Mirsky; Marc Binderberger
> Cc: [email-masked]
> I've read the draft, and I concur with Greg's comment: at least some of
> the scenarios described as possible causes for false detection of the
> session failure look like legitimate path failures to me.

Hopefully explanations that Marc provided on another thread have cleared this up. It's clear that we need to better write this section.

> 
> I also assume (even if the draft does not spell this out) that the problem
> is false detection of the BFD session failure by the peers of the router
> that experiences one of the scenarios described in the draft.
> IMHO and FWIW handling of "local" problems with the BFD session does not
> require any modifications to the BFD standards, it is an implementation
> issue. As a consequence, I wonder why the shadow session would be really
> helpful in differentiating between "true" and "false" path failures.

Yes this is where we started as well. Based on my experience, that trying to address some "local" problems w/o flapping BFD sessions can be (1) very difficult ex: not enough time to detect & react, or (2) can result in very complex & potentially timing sensitive design. Thus we wanted to see if something simpler can be done, which is this draft.

> 
> E.g., consider crash of the BFD-handling process in a SW-based BFD
> scenario: does the draft suggest that "main" and ""shadow" BFD sessions
> would be handled by two different BFD processes? (This probably would
> not help n the case of CPU starvation.) 

[snip]
   A logic
   SHOULD be applied to identify where in the system to host the two
   sessions.  The logic should maximize the failure detection validity
   by minimizing the chances of both sessions being impacted by a single
   local failure.  
[snip]

We kept this a bit vague on purpose, allowing implementations to choose the placement logic. However, if there are multiple CPU instances on your system, it may be more desirable to run primary and shadow BFD sessions on separate CPU to avoid one CPU starvation instance impacting both primary and shadow sessions.

> Or does the draft assume that
> the crashed process could be restarted fast enough to maintain at least
> one of the two paired sessions intact for the peers? If this is what the
> draft proposes, would not the same result be achieved by simply increasing
> the session failure detection time?

Operators often push for faster detection time, I'm sure all vendors have felt that "heat". So we wanted to avoid a solution requiring longer failure detection time.

> 
> Failure of the routing processor card in the centralized BFD scheme looks
> like another valid use case of false path failures. But how would the
> "shadow session" help in this scenario? Does the draft assume that the
> "shadow" session would be handled by the backup routing processor
> (assuming there is one)? This is possible, but is it sufficiently
> different from implementing "hot standby" for the BFD sessions in the
> backup rouging processor?

Difference is that this draft allows "fully hot" instead of "hot standby", and eliminates any potential synchronizations between "primary" and "hot standby".

> 
> Yet another side of the problem is a (pretty obvious IMHO) requirement
> for the mechanism differentiating between "true" and "false" data path
> failures not to increase the time it takes to detect the
> "true"/"legitimate" failure. The draft does nt explicitly describe how
> the "shadow" session is used in he case of "true" failures, so it is not
> clear to me if the proposed mechanism really meets this requirement.

This is a great feedback. We described this a bit in section 6, but it's clear that we need to be clear-er on this topic. Noted.

Again, thanx for great feedback.

Regards,
Nobo

> If this requirement is not met, simply increasing the session failure
> detection time looks like a trivial answer for most (if not all) of the
> scenarios mentioned in the draft.
> 
> My 2c.
>      Sasha
> 
> 
> 
> 
> 
> 
> 
> 
> From: [email-masked] [[email-masked]] on behalf of
> Gregory Mirsky [[email-masked]]
> in section 2 you list four possible causes for positive negatives due
> to BFD monitoring interruption, not path failure. But I believe that
> detecting cases 2 and 4 is actually what is expected of BFD as FPGA and
> LC failures directly affect data path. Which of remaining scenarios 1
> and 3, in your opinion, will be excluded by shadow BFD session to justify
> new version of BFD?
> 
>         Regards,
>                 Greg
> 
> Nobo and me are interested in your feedback for a new proposal we make
> to enhance the redundancy characteristics of BFD.
> 
> With requirements (*) to run BFD practically without interruption at short
> timer intervals we think it's worthwhile to think about and discuss it.
> 
> (*: I'm sure you either have similar requests from your customers or you
> are one of these customers asking for it ;-)
> 
> 
> Best regards,
> Marc
> 
> 
> 
> Begin forwarded message:
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.