Subject: implementation of BFD in passive mode?

From: "Das, Bevan N (Bevan)" <[email-masked]>
Date: Wed, 14 Sep 2011 15:22:52 -0500

Hi,

I am a software tester in Alcatel-Lucent, and part of my current work is verifying BFD interoperability of one of our products with routers.

In reading through RFC 5880 and in searching through web guides for BFD, I have seen two modes possible for BFD:  "active" and "passive".  However, all the routers that I have worked with up until now only implement "active" mode.  Are there any implementations of BFD that actually use "passive" mode?  In other words, am I safe in just verifying interoperability with routers in "active" mode?

Thank you for your time,

Bevan Das
[email-masked]

---

From: binny jeshan <[email-masked]>
Date: Thu, 15 Sep 2011 08:55:52 +0530

Hi Bevan,

As per my understanding about BFD in passive mode, its should be implemented
in all routes supporting 5880, except when explicitly passive mode is said
to be not supported. I believe the Spirent Test Center BFD base package has
already implemented this and you can test your SUT using it. You can test
the negative scenario passive-passive too.

The same applies for Poll-final sequence also. Some routers may implement
this, whereas some may not. They require to bring down the session and edit
the BFD session parameters.

Hope this helps you.

Thanks,
Binny Jeshan.

On 15 September 2011 01:52, Das, Bevan N (Bevan) <
[email-masked]> wrote:

> Hi,
>
> I am a software tester in Alcatel-Lucent, and part of my current work is
> verifying BFD interoperability of one of our products with routers.
>
> In reading through RFC 5880 and in searching through web guides for BFD, I
> have seen two modes possible for BFD:  "active" and "passive".  However, all
> the routers that I have worked with up until now only implement "active"
> mode.  Are there any implementations of BFD that actually use "passive"
> mode?  In other words, am I safe in just verifying interoperability with
> routers in "active" mode?
>
> Thank you for your time,
>
> Bevan Das

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Sep 2011 06:40:25 +0200

Binny,
You say that some routers may not implement the poll-final sequence for BFD and require bringing down their BFD sessions in order to change the session parameters.

I wonder how this is supposed to be compatible with the following in RFC 5880:

>From Section 6.2 "BFD State Machine":
<quote>

                             +--+
                             |  | UP, ADMIN DOWN, TIMER
                             |  V
                     DOWN  +------+  INIT
              +------------|      |------------+
              |            | DOWN |            |
              |  +-------->|      |<--------+  |
              |  |         +------+         |  |
              |  |                          |  |
              |  |               ADMIN DOWN,|  |
              |  |ADMIN DOWN,          DOWN,|  |
              |  |TIMER                TIMER|  |
              V  |                          |  V
            +------+                      +------+
       +----|      |                      |      |----+
   DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
       +--->|      | INIT, UP             |      |<---+
            +------+                      +------+

<end quote>

>From Section 6.8.3 "Timer Manipulation":
<quote>

   When bfd.SessionState is not Up, the system MUST set
   bfd.DesiredMinTxInterval to a value of not less than one second
   (1,000,000 microseconds).  This is intended to ensure that the
   bandwidth consumed by BFD sessions that are not Up is negligible,
   particularly in the case where a neighbor may not be running BFD.

<end quote>

To me these two fragments mean that BFD sessions are always started as "slow" (i.e., not faster than 1 packet/second), revert to "slow" every time they go down, and can only progress to the desired rate via the Final/Poll negotiation.

Did I miss something substantial?

Regards,
     Sasha
________________________________
From: [email-masked] [[email-masked]] On Behalf Of binny jeshan [[email-masked]]
Sent: Thursday, September 15, 2011 5:25 AM
To: Das, Bevan N (Bevan)
Cc: [email-masked]
Subject: Re: implementation of BFD in passive mode?

Hi Bevan,

As per my understanding about BFD in passive mode, its should be implemented in all routes supporting 5880, except when explicitly passive mode is said to be not supported. I believe the Spirent Test Center BFD base package has already implemented this and you can test your SUT using it. You can test the negative scenario passive-passive too.

The same applies for Poll-final sequence also. Some routers may implement this, whereas some may not. They require to bring down the session and edit the BFD session parameters.

Hope this helps you.

Thanks,
Binny Jeshan.

On 15 September 2011 01:52, Das, Bevan N (Bevan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thank you for your time,

Bevan Das
[email-masked]<mailto:[email-masked]>

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: binny jeshan <[email-masked]>
Date: Thu, 15 Sep 2011 11:01:14 +0530

Hi Sasha,

Your points are correct. In the same section, i find the below aspects also.
*
*
<quote>

*The time values used to determine BFD packet transmission intervals
   and the session Detection Time may be modified at any time without
   affecting the state of the session.  When the timer parameters are
   changed for any reason, the requirements of this section apply.*

*<end>*

*
*

<quote>

*If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,
   the actual transmission interval used MUST NOT change until the Poll
   Sequence described above has terminated.  This is to ensure that the
   remote system updates its Detection Time before the transmission
   interval increases.*

*<end>*

*
*

Changing timers can be done in two ways as per my understanding.

1. Router A operator can initiate the timing change through poll request and
at the end of the poll sequence the new timer values are applied.
2. Route A and B can bring the session Admin Down, Change its timers and
start-off again..

Slow interval can be used in below cases as per my understanding.
1. When session starts up in Down state
2. When session goes down due to any defects

When you start a session, you need not do a polling, since the timer
negotiation section 6.8.2, will be used, and not the polling.
Polling will be used only when timer is 'modified'.

Why some routers may not implement Polling?
One reason could be that in cases if BFD is accelerated in a Fast Path ASIC
(for sub-second interval configurations), it becomes hard to change
parameters in run-time using polling without affecting the running session.
This is due to implementation limitations at hardware level. In such case,
these routers allow polling for sessions running at software.

Thanks for the question..

Regards,
Binny Jeshan

On 15 September 2011 10:10, Alexander Vainshtein <
[email-masked]> wrote:

>  Binny,
> You say that some routers may not implement the poll-final sequence for BFD
> and require bringing down their BFD sessions in order to change the session
> parameters.
>
> To me these two fragments mean that BFD sessions are always started as
> "slow" (i.e., not faster than 1 packet/second), revert to "slow" every time
> they go down, and can only progress to the desired rate via the Final/Pollnegotiation.
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of
> binny jeshan [[email-masked]]
> *Sent:* Thursday, September 15, 2011 5:25 AM
> *To:* Das, Bevan N (Bevan)
> *Cc:* [email-masked]
> *Subject:* Re: implementation of BFD in passive mode?
>
>  Hi Bevan,
>
>  As per my understanding about BFD in passive mode, its should be
> implemented in all routes supporting 5880, except when explicitly passive
> mode is said to be not supported. I believe the Spirent Test Center BFD base
> package has already implemented this and you can test your SUT using it. You
> can test the negative scenario passive-passive too.
>
>   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: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Sep 2011 09:59:07 +0200

Jinny,
Lots of thanks for a prompt response.

I am not sure that changing the parameters in AdminDown state of the session is compliant with 5880.
Please note that the fragment I've quoted refers to the situation when the BFD session is not Up,  which clearly includes AdminDown.
Note also that the session may go Down for natural reasons (if they were not, why should we bother to set them up anyway?), and should resume their original fast operation once they come up back.

Last but not least, I am aware of at least two implementations that use BFD HW accelerators (what you call the fast path ASICs) to support intervals and timers in the millisecond range combined with 5880-compliant Final/Poll processing in SW. The protocol has been specifically designed to facilitate this kind of HW/SW interaction IMO.

Regards,
     Sasha

From: binny jeshan [mailto:[email-masked]]
Sent: Thursday, September 15, 2011 8:31 AM
To: Alexander Vainshtein
Cc: [email-masked]; Robert Rennison
Subject: Re: implementation of BFD in passive mode?

Hi Sasha,

<quote>

The time values used to determine BFD packet transmission intervals

   changed for any reason, the requirements of this section apply.

<end>

<quote>

If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,

   interval increases.

<end>

1. Router A operator can initiate the timing change through poll request and at the end of the poll sequence the new timer values are applied.
2. Route A and B can bring the session Admin Down, Change its timers and start-off again..

When you start a session, you need not do a polling, since the timer negotiation section 6.8.2, will be used, and not the polling.
Polling will be used only when timer is 'modified'.

Why some routers may not implement Polling?
One reason could be that in cases if BFD is accelerated in a Fast Path ASIC (for sub-second interval configurations), it becomes hard to change parameters in run-time using polling without affecting the running session. This is due to implementation limitations at hardware level. In such case, these routers allow polling for sessions running at software.

Regards,
Binny Jeshan

On 15 September 2011 10:10, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Binny,
You say that some routers may not implement the poll-final sequence for BFD and require bringing down their BFD sessions in order to change the session parameters.

<quote>

                             +--+

                             |  V

                     DOWN  +------+  INIT

              |            | DOWN |            |

              |  |         +------+         |  |

              |  |                          |  |

              |  |               ADMIN DOWN,|  |

              |  |ADMIN DOWN,          DOWN,|  |

              |  |TIMER                TIMER|  |

              V  |                          |  V

            +------+                      +------+

       +----|      |                      |      |----+

            +------+                      +------+
<end quote>

<quote>

Regards,
     Sasha
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of binny jeshan [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, September 15, 2011 5:25 AM
To: Das, Bevan N (Bevan)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: implementation of BFD in passive mode?
Hi Bevan,

Hope this helps you.

Thanks,
Binny Jeshan.
On 15 September 2011 01<tel:2011%2001>:52, Das, Bevan N (Bevan) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thank you for your time,

Bevan Das

---

From: binny jeshan <[email-masked]>
Date: Thu, 15 Sep 2011 14:34:19 +0530

Hi Sasha,

True. It is required to have poll/final to complete the 5880 compliance. May
be it could take some more time for those devices who aren't  doing it now
:)

Also for Bevan's original Q, i hope passive mode is available in all
routers.

Some more thoughts:
If a session goes down for natural reasons like packet loss, session will
continue at "Slow rate". If the session comes up naturally again, there need
not be a poll-final since there was no change made to it.
Similarly, when the session is in Down due to natural reasons, and operator
wishes to change the interval, poll sequence will be initiated, completed
and upon complete transmission will start at newer time interval, after
which a session may come up or may not. (Example case:.. typically could be
used if there is partial traffic loss and toggling BFD states)

Going in Admin Down case, my understanding is that at one point we stop
sending BFD packets in Admin Down state and resume sending only on Admin Up.
There is no clear definition of what happens in between. But, its clearly
mentioned that in AdminDown State do not receive packets(that includes
poll/final/other).. And, IMO changing BFD parameters is operator's decision
and could be allowed Only issue could be that timer change should be done at
both ends before waking the sessions up.. Else, there could be a LOC.

What is your thought on Admin Down otherwise? What is allowed to be done
after Admin Down?

Regards,
Binny

On 15 September 2011 13:29, Alexander Vainshtein <
[email-masked]> wrote:

> Jinny,****
>
> Lots of thanks for a prompt response.****
>
> ** **
>
> I am not sure that changing the parameters in AdminDown state of the
> session is compliant with 5880.****
>
> Please note that the fragment I’ve quoted refers to the situation when the
> BFD session is not Up,  which clearly includes AdminDown.****
>
> Note also that the session may go Down for natural reasons (if they were
> not, why should we bother to set them up anyway?), and should resume their
> original fast operation once they come up back.****
>
> ** **
>
> Last but not least, I am aware of at least two implementations that use BFD
> HW accelerators (what you call the fast path ASICs) to support intervals and
> timers in the millisecond range combined with 5880-compliant Final/Poll
> processing in SW. The protocol has been specifically designed to facilitate
> this kind of HW/SW interaction IMO. ****
>
> ** **
>
> Regards,****
>
>      Sasha****
>
> ** **
>
> *From:* binny jeshan [mailto:[email-masked]]
> *Sent:* Thursday, September 15, 2011 8:31 AM
> *To:* Alexander Vainshtein
> *Cc:* [email-masked]; Robert Rennison
>
> *Subject:* Re: implementation of BFD in passive mode?****
>
> ** **
>
> Hi Sasha,****
>
> ** **
>
> Your points are correct. In the same section, i find the below aspects
> also.****
>
> ** **
>
> <quote>****
>
> ** **
>
> *The time values used to determine BFD packet transmission intervals*
>
> *   and the session Detection Time may be modified at any time without*
>
> *   affecting the state of the session**.  When the timer parameters are*
>
> *   changed for any reason**, the requirements of this section apply.*****
>
> *<end>*****
>
> *
> *
>
> ** **
>
> <quote>****
>
> *If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,*
>
> *   the actual transmission interval used MUST NOT change until the Poll*
>
> *   Sequence described above has terminated.  This is to ensure that the*
>
> *   remote system updates its Detection Time before the transmission*
>
> *   interval increases.*****
>
> *<end>*****
>
> *
> *
>
> Changing timers can be done in two ways as per my understanding. ****
>
> ** **
>
> 1. Router A operator can initiate the timing change through poll request
> and at the end of the poll sequence the new timer values are applied.
> start-off again..****
> ** **
> Slow interval can be used in below cases as per my understanding.****
>
> 1. When session starts up in Down state****
>
> 2. When session goes down due to any defects****
>
> ** **
>
> negotiation section *6.8.2,* will be used, and not the polling.****
>
> Polling will be used only when timer is 'modified'. ****
>
> ** **
>
> Why some routers may not implement Polling? ****
>
> these routers allow polling for sessions running at software.****
>
> ** **
>
> Thanks for the question..****
>
> ** **
>
> Regards,****
>
> Binny Jeshan****
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> Binny,****
>
> parameters.****
>  ****
> I wonder how this is supposed to be compatible with the following in RFC
> 5880:****
>
>  ****
>
> From Section 6.2 "BFD State Machine":****
>
> <quote>****
>
>                              +--+****
>
>                              |  | UP, ADMIN DOWN, TIMER****
>
>                              |  V****
>
>                      DOWN  +------+  INIT****
>
>               +------------|      |------------+****
>
>               |            | DOWN |            |****
>
>               |  +-------->|      |<--------+  |****
>
>               |  |         +------+         |  |****
>
>               |  |                          |  |****
>
>               |  |               ADMIN DOWN,|  |****
>
>               |  |ADMIN DOWN,          DOWN,|  |****
>
>               |  |TIMER                TIMER|  |****
>
>               V  |                          |  V****
>
>             +------+                      +------+****
>
>        +----|      |                      |      |----+****
>
>    DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP****
>
>        +--->|      | INIT, UP             |      |<---+****
>
>             +------+                      +------+****
>
> <end quote>****
>
>  ****
>
> From Section 6.8.3 "Timer Manipulation":****
>
> <quote>****
>
>    When bfd.SessionState is not Up, the system MUST set****
>
>    bfd.DesiredMinTxInterval to a value of not less than one second****
>
>    (1,000,000 microseconds).  This is intended to ensure that the****
>
>    bandwidth consumed by BFD sessions that are not Up is negligible,****
>
>    particularly in the case where a neighbor may not be running BFD.****
>
> <end quote>****
>
>  ****
>
> they go down, and can only progress to the desired rate via the Final/Poll
> negotiation.****
>
>  ****
>
> Did I miss something substantial?****
>
>  ****
>
> Regards,****
>
>      Sasha****
> *Subject:* Re: implementation of BFD in passive mode?****
>
> Hi Bevan, ****
>
> ** **
>
> can test the negative scenario passive-passive too.****
>
> ** **
>
> the BFD session parameters.****
>
> ** **
>
> Hope this helps you.****
>
> ** **
>
> Thanks,****
>
> Binny Jeshan.****
>
> [email-masked]> wrote:****
>
> Hi,
>
> [email-masked]****
>
> ** **
>
> thereof. ****
> ** **

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2011 10:15:14 -0700

Dear Sasha,
I believe that changing timers through taking session into Admin Down
is compliant with RFC 5880. It is mentioned in parameter update method
in MPLS-TP CC-CV-RDI. Section 3.7.1:
   In the rare circumstance where an operator has a reason to further
   change session parameters, beyond the initial migration from default
   values; poll/final discipline can be used with the caveat that a peer
   implementation may consider a session change unacceptable and/or
   bring the BFD session down via the use of the ADMIN DOWN state.

Regards,
Greg

On Thu, Sep 15, 2011 at 12:59 AM, Alexander Vainshtein
<[email-masked]> wrote:
> BFD session is not Up,  which clearly includes AdminDown.
>
> original fast operation once they come up back.
>
>
>
> this kind of HW/SW interaction IMO.
>
>
>
> Regards,
>
>      Sasha
>
>
>
> On 15 September 2011 10:10, Alexander Vainshtein
> <[email-masked]> wrote:
>
> Binny,
>
> 5880:
> negotiation.
> On 15 September 2011 01:52, Das, Bevan N (Bevan)
> <[email-masked]> wrote:
>
> Hi,
>